Risk identification means finding what could affect your objectives and describing how it could happen. Workshops, interviews, checklists and reviews of past incidents can help your team uncover risks that a single person might miss.
There is no single best technique for every project. Combine approaches that draw on evidence, day-to-day experience and different viewpoints. Then assess the risks you identify using a suitable risk assessment method.
1. Review historical data and incidents
Start with what your organisation already knows: incident reports, complaints, near misses, audit findings and previous project reviews. Look for recurring causes, unresolved actions and problems that appear across teams.
For example, repeated late deliveries may point to dependence on a supplier rather than a series of unrelated purchasing problems. Record the underlying issue and the service or project it could affect.
Past records are a starting point. A new activity, supplier or working arrangement may introduce risks that have never appeared in your data.
2. Explore scenarios
Ask a focused “what if?” question about an objective: what if a key supplier stops trading, a system becomes unavailable, or demand exceeds capacity?
Work through the sequence of events, the people affected and any dependencies. For a project launch, ask what would happen if a critical approval arrived two weeks late. This can reveal knock-on effects on staffing, costs and delivery.
Keep scenarios plausible and distinguish assumptions from evidence. The output is a set of risks to investigate, rather than a forecast that a particular event will happen.
3. Use SWOT analysis to prompt discussion
SWOT considers strengths, weaknesses, opportunities and threats. It can help a team look beyond its immediate tasks to changes in the organisation and its wider environment.
Turn broad observations into specific risk statements. “Limited capacity” is a weakness; “dependence on one trained employee could delay customer support during absence” describes an event and consequence that someone can assess.
SWOT helps surface issues. It does not, by itself, establish their likelihood, impact or priority.
4. Gather expert views with the Delphi technique
Delphi uses structured rounds of questions, feedback and revised responses to gather expert judgement. Participants typically respond independently and anonymously, which can reduce the influence of seniority or dominant voices.
It may help when specialists disagree about an emerging issue or cannot meet together. Ask them which events could affect the objective and what evidence supports their view.
The RAND guidance on Delphi panels explains that the process can identify agreement and disagreement. Agreement is not proof that a risk estimate is correct, and consensus is not guaranteed.
5. Brainstorm with the people doing the work
Give participants a clear scope, such as completing a service handover or implementing a new system. Ask each person to note risks independently before discussing them as a group. This gives quieter contributors time to develop their ideas.
Useful prompts include:
- What could stop us reaching the objective?
- Where are we relying on a single person, supplier or system?
- What has nearly gone wrong before?
- Which assumptions have we not checked?
Capture ideas first, then clarify duplicates and separate existing problems from uncertain future events. Do not discard an uncomfortable issue simply because it is difficult to assess.
6. Use checklists and questionnaires
Checklists provide prompts for familiar activities, while questionnaires gather observations from a wider group. Both are useful for collecting information consistently across sites or departments.
For example, a service review might ask about staffing cover, supplier dependencies, access to records and unresolved complaints. Include an open question so respondents can raise concerns outside the checklist.
Review the prompts when circumstances change. A completed checklist does not show that every relevant risk has been found.
7. Interview staff and specialists
Interviews allow you to explore issues in more depth than a survey. Speak with people who understand different parts of the activity: frontline staff, service managers, finance, IT and external partners where relevant.
Ask for concrete examples: “Which handover is most likely to fail?” usually produces more useful information than “Are there any risks?” Follow up by asking about causes, existing controls and who else has relevant knowledge.
Record areas of uncertainty and disagreement as well as conclusions. An interview captures a perspective that may need checking against other evidence.
8. Review information held in your systems
Use operational records to spot patterns that deserve investigation. Overdue actions, recurring incidents, rising complaints or repeated exceptions may indicate an underlying risk.
Bring related information together and ask what it means in context. An increase in reports might reflect easier reporting rather than a sudden deterioration in performance.
Software can help organise this information, but interpretation still needs people who understand the activity. RiskMate brings risk records, incidents and action reporting together; the team remains responsible for identifying and assessing the risks.
9. Run a structured risk workshop
A workshop brings several techniques into one facilitated session. It is particularly useful when risks cross departments or depend on handovers between teams.
To run a risk identification workshop:
- Define the objective, scope and decisions the session will inform.
- Invite people with different responsibilities and direct experience.
- Share relevant incidents, process information and assumptions beforehand.
- Use prompts, scenarios or brainstorming to surface risks.
- Describe the causes, possible events and consequences clearly.
- Agree who will check missing information and take each risk forward for assessment.
Keep identification and scoring as distinct tasks, even if both happen in the same meeting. Otherwise the group may spend its time debating the first risk rating and leave important areas unexplored.
Turn the findings into a usable risk register
For each risk, record the objective affected, causes, possible event, consequences and existing controls. Add an owner and note any information that needs checking. Our risk assessment example shows the sort of fields a register can contain.
For example: “Because support knowledge sits with one employee, an unplanned absence could delay responses and interrupt service.” This is more useful than a register entry labelled only “staffing”.
Once the risks are clear, analyse and prioritise them through your risk management process. Return to identification when projects, services or external conditions change.
Common questions about identifying risks
What is the difference between identification and assessment?
Identification describes what could happen and why. Assessment examines likelihood, consequences and the controls already in place so that you can decide what action is needed.
Which identification method should a small team start with?
Start with a focused discussion of objectives, recent incidents and dependencies. Use a short checklist to prompt missing areas, and involve someone with a different perspective. Add specialist techniques when the decision calls for them.
Can a workshop identify every risk?
No. Its value depends on the scope, information and participants. Follow up unanswered questions and review the findings as circumstances change. Our guide to challenges in risk assessment covers common gaps and practical responses.