Risk identification in QMS processes looks for uncertainties that could affect intended results. It begins with understanding the work, requirements and dependencies. A generic list of business concerns is less useful when nobody can explain the event, consequence or process decision involved.
The risk-based thinking guide explains how identification leads to evaluation, action and review. This article focuses on finding and describing issues before assigning scores or selecting responses.
Start with the process result and boundary
Identify what the process should deliver and who uses the output. Determine which requirements or objectives could be affected. Without that reference, almost any concern can become a vaguely related risk entry.
Review the process from trigger to completion, including relevant interfaces. A problem can arise before the visible activity begins if an input is incomplete or an external dependency is unavailable.
The process management guide explains inputs, outputs and ownership. Identification should use that understanding rather than operate as a separate brainstorming exercise disconnected from work.
Trace decisions and dependencies
Ask what information, authority, people, equipment and external supply the process relies on. Consider what happens if those conditions differ from the normal assumption.
For a fictional service plan, the relevant uncertainty might be unavailable specialist capability when an unusual request arrives. The useful description connects that condition to the accepted service result rather than merely list staffing risk.
Examine handovers. A receiving process may assume that an upstream review resolved a requirement when the supplying team believes it only forwarded the request.
Use several evidence sources
Actual cases, complaints, audit findings, process measures and change information can reveal useful issues. People performing and receiving the work can explain exceptions that a procedure does not show.
Do not limit identification to past failures. A new technology, supplier or service can create uncertainty without an established history. State assumptions where evidence is limited.
| Evidence source | Identification question |
|---|---|
| Rework | What input or decision repeatedly needs correction? |
| Complaints | Which intended result was not achieved? |
| Changes | Which assumptions or controls may no longer apply? |
| Exceptions | Where does the normal route depend on an uncertain decision? |
| External dependencies | What result relies on another party’s capability or information? |
These are original prompts, not a complete mandatory assessment checklist.
Separate event, cause and effect
A cause can explain why an event might occur. The event or condition affects the process. The consequence explains what could happen to the intended result or recipient. Clear distinctions help later evaluation and action.
For example, obsolete information at the workstation can lead to use of an inapplicable criterion, affecting acceptance of output. A register entry saying document control does not communicate that relationship.
Avoid writing the proposed solution as the risk itself. Need new software states a preference, not the uncertainty that justifies the decision.
Examine credible variation and change
Consider relevant differences in location, workload, service type, shifts and exceptional cases. A control that works during ordinary operation may be weaker when the usual approver is absent or a system is unavailable.
Keep the enquiry proportionate and evidence-based. Inventing remote scenarios without a credible relationship to the process can distract attention from consequential issues already supported by information.
Where specialist interpretation is needed, identify that need rather than fill the gap with an arbitrary score. Uncertainty about the assessment itself should be visible.
Validate the description with affected people
Discuss the issue with the process owner and relevant recipients. Confirm the intended result, current control and factual basis. Different perspectives can reveal a hidden interface or an assumption that needs testing.
Avoid settling the description solely through seniority or workshop consensus. A plausible shared account still needs relevant evidence where the decision depends on it.
The risk register article explains how to preserve a useful description and connect it with ownership. The record should help a person who did not attend understand the issue.
Hand the issue into evaluation
Identification does not establish priority or prove that a control is inadequate. Provide enough information for the next decision, including important assumptions and known limitations.
Retain significant relationships without duplicating the same issue under many generic labels. One underlying dependency can affect several processes and may need coordinated evaluation.
Good identification turns broad concern into a clear question about intended results and actual conditions. It supports proportionate evaluation by explaining what could happen, why it matters and what evidence is available, rather than producing a long list that nobody can use.
Record significant exclusions from the identification exercise. A workshop focused on one location or product family should not later be represented as complete coverage of every activity without evaluating the relevant differences.
Include the people who receive the output as well as those who produce it. A handover can appear successful to the sending team while leaving the recipient to resolve uncertainty informally. Ask recipients which missing details force them to make assumptions. Their experience often reveals concerns that an input-focused workshop overlooks, particularly where information passes between organisations or specialist functions.