A quality risk register records selected uncertainties that can affect intended QMS results and the decisions made about them. It can make ownership, controls, actions and review visible. Its value depends on useful reasoning and current information, not the number of rows or the appearance of a completed spreadsheet.
The risk-based thinking guide explains the wider system. A register is one possible implementation tool, not a universal requirement to use a particular form or software product.
Define what belongs in the register
Start with the scope and decisions the record supports. A system-level view can identify consequential cross-process issues, while a local process view may need different detail. Link levels where useful rather than duplicate every item without ownership.
Use a credible event or condition and its effect on an intended result. Supplier risk is too broad to guide action. Uncertain availability of a specified component affecting an accepted delivery commitment is more informative.
Separate causes, consequences and controls. Mixing them into one label can lead to inconsistent evaluation and actions that do not address the actual mechanism.
Choose fields that support action
A useful register can identify the result affected, risk description, existing controls, evaluation basis, decision, owner, action and review evidence. The structure should match the organisation’s needs.
| Field | Fictional example |
|---|---|
| Intended result | Complete an accepted service under agreed conditions |
| Uncertainty | Required access information may be incomplete at scheduling |
| Existing control | Booking review with a defined clarification route |
| Evidence or assumption | Recent cases show unresolved access conditions |
| Decision | Strengthen entry criteria and review exceptions |
| Owner | Relevant process owner |
| Review | Later relevant bookings show usable information at planning |
This example is not a mandatory record or a universal diagnosis. A real entry needs actual evidence and applicable criteria.
Explain evaluation and residual uncertainty
If scores are used, define the scales and what evidence supports them. Record important assumptions and limitations. A score without that context can conceal uncertainty rather than communicate it.
Distinguish the situation before and after existing or proposed controls where the chosen method uses those views. Do not lower the score merely because an action was assigned. Implementation and effectiveness need relevant evidence.
The risk evaluation article explains the difference between judging significance and selecting a response. A register should preserve the connection without treating the rating as the decision itself.
Connect the owner with authority
Assign someone who can coordinate the issue or obtain the necessary decision. A name in a cell is insufficient if the action crosses functions and nobody can resolve the interface.
Distinguish the owner of the risk record from the person performing an action or accepting a remaining uncertainty. These roles can coincide, but their meaning should be clear.
Where a requirement cannot be waived internally, an acceptable label does not remove the obligation. Ensure decisions use suitable authority and relevant advice.
Keep actions connected to real processes
Identify where a selected response changes work, information, resources or controls. A register can say training complete while the process continues to provide the same incomplete input.
Use references to controlled action records where that avoids duplication. The register should allow users to understand status without becoming a competing history of the same decision.
If interim measures are needed, define their purpose and review arrangements. Temporary actions should not remain indefinitely without ownership or evidence.
Review changes and results
Use relevant triggers such as process changes, adverse trends, incidents or altered dependencies. A periodic review can help, but a consequential change should not wait solely for the annual calendar.
The monitoring article explains why review should examine conditions and effectiveness rather than only overdue dates. Record what changed and the basis for retaining or revising the decision.
Keep history sufficient to explain important changes in assessment. A clean current view can be useful while preserving the reasoning behind earlier decisions where needed.
Preserve the distinction from opportunities
Beneficial possibilities can need different information, such as expected benefit, feasibility and investment of resources. Do not force them into an adverse-risk template that obscures their purpose.
A combined system can still make the distinction clear. The choice of one workbook or several does not by itself demonstrate suitable management.
A useful register supports accountable decisions about actual uncertainty. It remains proportionate, current and connected to evidence, with entries that help people act rather than provide a static list prepared only to satisfy an inspection.
A status field should distinguish proposed action, implemented action and reviewed effectiveness where those stages matter. Otherwise a completed label can conceal that the process has not yet encountered a relevant test of the new control. Define the meaning and authority for each consequential status.
Give each entry a stable identifier when several actions or meeting decisions refer to it. Changing the wording should not break those references. A closed entry can remain searchable without appearing on the active action list. Retaining this distinction helps new staff understand previous choices and prevents an old issue from being reintroduced under a different name without recognising the evidence already available.