The risk register¶
Duration: 60 minutes
Materials: all previous cards and materials, a shared document or spreadsheet
The exercise¶
Consolidate the work from previous exercises into a risk register. The register is a structured record of what the group agreed about: the risks, the assessments, the treatment decisions, and the ownership.
The register is not the output of risk management. It is the memory of decisions made. The decisions are the output. Without decisions that are owned and acted upon, the register is a description of risks that the organisation has documented but not managed.
Building the register¶
Create a structure with the following fields. Simple is better: a register that is too elaborate to maintain will not be maintained.
Risk ID, asset, vulnerability, likelihood, impact, risk level, treatment approach, specific actions, owner, target completion date, current status, and a review date.
Add fields that are genuinely useful for your context: compliance references if you are working toward a standard, cost estimates if budget decisions depend on them, links to related risks if dependencies need to be visible.
Step 1: Transfer risks systematically (30 minutes)
Start with critical and high risks. For each, capture a clear description that specifies the asset, the vulnerability, and the potential impact in terms specific enough that someone who was not in the workshop understands what is at stake.
Document the reasoning behind the likelihood and impact ratings. The rating is less valuable than the reasoning: the reasoning is what allows the rating to be challenged, updated, or defended when circumstances change.
Document the treatment decision, the specific actions that follow from it, a realistic owner, and a realistic target date. An owner who does not know they own the risk is not an owner. A target date set without reference to the owner’s actual capacity is not a plan.
Step 2: Add metadata (10 minutes)
For each risk, note any compliance obligations it connects to, flag any risks that are linked to previous incidents or near-misses, and add references to related risks where dependencies affect treatment sequencing.
Step 3: Set the review schedule (10 minutes)
Risks change at different rates. Critical risks warrant monthly review. High risks warrant quarterly review. Medium risks can be reviewed semi-annually. Low risks annually or as needed.
Assign review owners and put it in calendars. A review schedule that exists in a document but not in anyone’s calendar is a review schedule that will not happen.
What makes a register live rather than static¶
A register that is only updated at the scheduled review dates is a register that is wrong most of the time. Build in triggers: when a new system goes live, when an incident occurs, when a treatment is implemented and the residual risk needs reassessing, when the threat landscape changes in a way that affects a rated risk.
The register is most useful when it reflects what is actually happening, not what the organisation intended when the exercises were run. That requires someone who is responsible for its currency, with access to the information needed to keep it current, and the authority to update ratings when the underlying situation changes.
Keeping it proportionate¶
The register works best when as simple as it can be while remaining useful. A thirty-field register that requires two hours to update a single entry will not be updated. A five-field register that captures the essential information and takes fifteen minutes to update will be.
The temptation to add sophistication before the basic practice is established is a common failure mode. Start with what is genuinely useful, add complexity only when you can demonstrate that simpler is no longer sufficient.