If your register shows two risk ratings but no explanation for the change, record the assumptions and evidence behind each assessment. Separate the risk you estimate today from the risk you expect after a treatment, then check the result once it is implemented.
Why pre and post mitigation risk have to be separate fields
A risk register that overwrites the original rating once treatment is applied has destroyed its own evidence. If your only record is the current rating, you cannot show a regulator, an auditor or your own board that the risk was ever higher, or that the treatment you funded made a measurable difference. You are left asserting improvement rather than demonstrating it.
Record the current risk with existing controls, the forecast risk after a proposed treatment, and the reassessed risk after implementation. Define these states explicitly. Inherent risk commonly means a hypothetical assessment without controls; it should not be used interchangeably with the current, already-controlled baseline. This is not a cosmetic distinction. It is the difference between a register that supports governance and one that merely documents activity.
What actually has to change between the two ratings
A common failure is recording a lower "after" rating without changing anything that would justify it. If likelihood and consequence both stay conceptually the same, the rating should not move. A genuine reduction has to trace back to something specific: a control implemented, a process changed, an exposure removed, a dependency eliminated. If you cannot point to that specific change, the "after" figure is optimism, not analysis.
This is where a bow-tie style approach to identifying causes and consequences earns its keep, because it forces you to be precise about which pathway a control actually interrupts, rather than asserting a general improvement across an entire risk.
A worked example: Coastal Logistics
Coastal Logistics is a fictional three-site freight operator. One risk on its register: unauthorised access to the warehouse management system leading to inventory fraud.
| Field | Current risk before the new treatment | Reassessed risk after implementation |
|---|---|---|
| Likelihood | Likely — shared login credentials, no access logging | Possible — individual logins issued, access logging enabled |
| Consequence | Major — undetected fraud could run for months | Major — consequence unchanged; detection is faster, not the impact ceiling |
| Rating | High | Medium |
| Justification for the change | — | Individual credentials plus logging reduces likelihood of undetected misuse; does not reduce the maximum possible loss if fraud occurs before detection |
| Assessment date | 14 March | 9 June, after control implementation confirmed |
| Assessed by | Risk and Compliance Manager | Risk and Compliance Manager, verified by IT |
Notice what did not move: consequence stayed at Major, because the treatment addressed likelihood of undetected access, not the scale of harm if it occurred anyway. A register that let both likelihood and consequence drop without separate justification for each would be recording hope, not analysis.
The ratings in this example are illustrative judgements using an assumed organisational matrix. Logging supports detection only if records are reviewed and acted on. A change from High to Medium does not establish a numerical percentage reduction or prove the treatment caused the change.
Why the assessment date field matters more than people think
Pre- and post-mitigation ratings without dates invite a specific kind of drift: someone updates the "after" rating the moment a treatment is approved, not once it is actually implemented and verified. A treatment that is scheduled is not a treatment that is working. Recording the date of each assessment, and ideally who performed it, makes it possible to check whether the "after" state was recorded before or after the control was actually in place — a distinction that matters enormously the first time an incident happens against a risk your register says was already treated.
Residual risk still has to be compared against something
A residual rating of Medium means nothing on its own. The question that matters is whether Medium sits inside or outside the level of risk your organisation has decided it is willing to accept. Too many registers stop at recording the drop from High to Medium and treat that improvement as the end of the conversation, when the real governance question is whether Medium is actually tolerable for this particular risk, in this particular part of the business.
This is where a register that only records numbers, without reference to an agreed risk appetite or tolerance statement, quietly loses its usefulness. Two risks can both carry a residual rating of Medium and warrant completely different responses — one because it sits comfortably within appetite, the other because it sits just outside it and needs further treatment or explicit executive acceptance. Recording the residual rating is the easy part. Deciding, and documenting, whether that residual level is acceptable is the part that actually requires judgement, and it should be a distinct field or sign-off in its own right rather than an assumption baked into the number.
Common mistakes
- Overwriting the baseline assessment instead of retaining it. Once it is gone, you have lost the ability to demonstrate the risk was ever higher, and lost your baseline for measuring any future treatment.
- Moving consequence and likelihood together without separate justification. Most treatments affect one more than the other. If both move, be able to explain both.
- Recording the post-mitigation rating before the treatment is actually implemented. This is the single most common way registers drift from reality — approval gets recorded as if it were completion.
- No verification step distinct from the person who implemented the control. Self-assessed effectiveness is a starting point, not a conclusion, particularly for higher-rated risks.
- Treating the residual rating as permanent. Controls degrade, environments change, and a residual rating from eighteen months ago deserves the same scepticism as an unreviewed baseline assessment.
Where this fits in your broader assessment process
Getting pre- and post-mitigation ratings right depends on scoping the original assessment properly in the first place — if the boundaries of the risk were unclear at the start, neither rating will mean much. How to Scope a Security Risk Assessment (Free Template) covers that groundwork. And because boards are increasingly expected to understand what "residual" actually means rather than accept the word at face value, Five Cybersecurity Questions Every Board Should Be Asking is a useful companion piece for the governance side of this conversation.
None of this requires an elaborate system. ISO 31000:2018 treats monitoring and review as a continuous part of the risk management process, not a one-off event at treatment sign-off, and a register that properly separates before and after states is simply that principle made operational.
Get the template
The SRMBOK Template 13.2 Risk Register is built around exactly this discipline: assessment dates, risk identification and reference numbers, categorisation, treatment options and monitoring, with risk recorded both before and after mitigation as separate, dated fields rather than a single rating that quietly gets overwritten. Download the SRMBOK Template 13.2 Risk Register and start recording treatment claims you can actually check.