Fourteen months ago someone on your team accepted a risk. They had a good reason: a compensating control was in place, the exposure was small, and there were bigger fires. The justification is still sitting in the register, word for word. Is any of it still true?
Most risk registers can't answer that, because they record an acceptance as a permanent fact rather than a decision with a shelf life. This is how we fixed that, and the one design decision in it that's worth stealing whatever tool you use.
Accepted risk goes stale quietly
An acceptance is a judgement about a moment: these controls, this exposure, this threat picture. Every part of that moves.
- The compensating control leaves. You accepted the risk because a WAF rule covered it. Eighteen months later the WAF was replaced and nobody re-checked which acceptances leaned on it.
- The system grows into it. The exposure was fine on an internal tool with nine users. It is a different risk now that the tool is customer-facing.
- The threat changes. Exploitation was theoretical when you accepted. Then it got a CVE, a Metasploit module, and a bad week.
- The person leaves. The rationale lived in someone's head. The register kept one sentence, and the context that made it reasonable walked out the door.
None of this is novel. It's why ISO 27001 puts risk treatment under a review clause rather than a one-time step, and why NIST's RMF ends in continuous monitoring instead of authorisation. Every serious framework says the same thing: an acceptance is a decision you owe a revisit. Very few tools give you anywhere to write down when.
Pick a shelf life when you accept
When you accept a risk, you now choose how long the acceptance stands: 3, 6 or 12 months, a date you pick, or never. It defaults to 12 months, which lines up with the annual review cycle most security programmes already run.
The decision, the justification and the review date are saved together, as one action. That matters more than it sounds: if the date were a separate step afterwards, there would be a gap where the risk is accepted with nothing scheduled — which is the silent-forever state the whole thing exists to remove.
Why “never” is a real option
Some accepted risks genuinely are permanent. A documented business decision about a legacy system that's being retired on a three-year plan does not need a reminder every quarter. So “never expires” sits in the same row as the periods, as a peer, not tucked underneath as an escape hatch.
This is a deliberate trade. A tool that forces a timer onto every acceptance trains people to dismiss the flag, and once they're dismissing flags they dismiss the ones that mattered too. Better to let someone say “this one is permanent, on purpose” and keep the flag meaningful everywhere else.
The status does not change
When the review date passes, the observation stays Risk Accepted. It picks up a Review due marker beside the status, shows up under a register filter, and gets counted on the dashboard. But the status itself is untouched.
The obvious alternative is worse. Sending the observation back to Awaiting Triage would claim the finding was never triaged, which isn't true, and it would merge two genuinely different things in every count and chart you have. An overdue review is not an untriaged finding. It is an accepted risk with a question mark over it.
Renewing means saying why, again
Re-affirming an acceptance requires a new justification. Not a confirmation dialog, not a checkbox: actual prose saying what you re-checked and why the risk is still acceptable.
A one-click renew would be a snooze button, and a snooze button turns a governance control into a nag. The forced re-articulation is the entire value of the cycle. If you can't write the sentence, that's the finding telling you something.
The previous statement isn't overwritten. It's archived, with its date, its author and the review date it carried. So the register can show you a decision that has been renewed four times and what the reasoning was each time, which is exactly the question an assessor asks and exactly the one most tools answer with a single text box that gets typed over.
Work it out, don't write it down
Whether an acceptance is overdue was never worth recording. It's a question you can answer at any moment from the review date you already hold and today's date. So nothing writes it down — the register works it out each time it shows you the page.
That removes a whole class of problems at once. There is no overnight job, so nothing can quietly fail to run. Nothing can fall out of step, because there is no second copy of the truth. Extend a review date and the marker clears itself immediately, with no “un-expire” step to build. And because the status itself never changes, every dashboard, report and integration carried on working untouched.
There is a cost, and it's worth being straight about it. Something worked out on the spot can't be looked up as quickly as something you filed away. In practice the review dates themselves are indexed and registers don't get large enough for the difference to show — and if that ever changes, we can start storing it without altering what any of it means.
The shape of it
- An acceptance is a decision about a moment. Controls, exposure and threats all move, so it needs a revisit date.
- Pick a cadence when you accept: 3, 6 or 12 months, a custom date, or never. Default is 12 months.
- "Never expires" is a real choice, not an escape hatch. Forcing a timer onto permanent decisions trains people to ignore the flag.
- When a review lapses the status stays Risk Accepted. An overdue review is not an untriaged finding, and merging the two loses that everywhere it's counted.
- Renewing requires a fresh justification. A one-click renew is a snooze button.
- Previous justifications are archived, not overwritten, so the register shows the whole chain of a decision that has been renewed.
- If a flag can be worked out from what you already hold plus today's date, work it out rather than storing it. Anything stored needs keeping current.