Every organisation above a certain size has a risk register. Very few have one that works — meaning one that decision-makers read, that changes resource allocation, and that an auditor or regulator would recognise as a living instrument rather than an annually-dusted artefact. The difference is not the tool. It is the field structure, the writing discipline and the operating rhythm around it.
What a register is for
A risk register is the organisation's single, structured memory of what could prevent its objectives, what is being done about each item, and who answers for it. Three jobs follow: comparison (risks expressed consistently enough to prioritise against each other), accountability (every risk visibly owned), and decision support (each entry pointing at a choice — accept, treat more, escalate). An entry that supports none of the three is occupying space.
The fields that earn their place
| Field | Why it exists |
|---|---|
| ID & risk statement | Stable reference; the risk in cause–event–consequence form |
| Category & objective at stake | Aggregation, and the business anchor that justifies the entry |
| Inherent rating | Exposure before controls — the "why we bother" baseline |
| Existing controls & their effectiveness | What's already mitigating, and honestly, how well |
| Residual rating | Exposure now — the number that gets compared to appetite |
| Risk owner | The one accountable person (a name, never a department) |
| Response & treatment actions | Accept / mitigate / transfer / avoid, plus dated, owned actions |
| KRIs & thresholds | The early-warning wiring that makes the entry dynamic |
| Review date & status | The freshness contract |
Resist the urge to add more. Every additional field is a tax on every future update, and bloated templates are the leading cause of register death.
Writing risk statements that survive contact with readers
The single highest-leverage discipline is the three-part statement: cause → event → consequence. Not "cyber risk." Not "ransomware." Instead: "Because remote-access systems lack MFA (cause), an attacker may gain entry and deploy ransomware (event), resulting in multi-day outage of order processing and regulatory notification duties (consequence)."
The form forces three honesty checks. The cause must be something you could actually treat. The event must be specific enough to estimate likelihood. The consequence must connect to an objective — and if it can't, the entry may not belong on the register at all.
A register full of one-word risks is a list of topics. A register of cause–event–consequence statements is a list of decisions waiting to be made.
Two more writing rules. Don't register control failures as risks ("backups not tested" is a control gap feeding a risk, not the risk itself). And don't register issues — things that have already happened belong in incident and issue logs, with the register holding what they imply about the future.
Ownership and rhythm: where registers live or die
Every risk gets exactly one accountable owner — the manager of the area where the risk resides, with the authority to act. The risk function facilitates and challenges; it owns the process, never the risks. Ownerless entries and committee-owned entries are the same thing: unowned.
Then give the register a heartbeat. High-rated risks reviewed monthly or quarterly with their owners; full-register refresh on a defined cycle; KRI threshold breaches triggering off-cycle review automatically. Each review asks three questions only: has exposure changed, are actions on track, is residual still within appetite? Twenty minutes per risk, decisions minuted. A register that is only touched before the audit is evidence against your risk process, not for it.
The failure modes to design against
The graveyard register (hundreds of stale entries — fix with ruthless closure and aggregation). The wallpaper register (everything rated medium — fix with calibrated scales and forced-ranking the top ten). The shadow register (real risk discussions happen elsewhere — fix by making the register the agenda of the risk committee, not its appendix). And the precision-theatre register (two-decimal scores on guessed inputs — fix with honest ranges and rating definitions).
Exam angle, briefly
CRISC treats the register as the central artefact of Domain 3: expect questions on what it must contain (owner, response, residual risk), who owns entries (the business, never the risk function), and what triggers updates (KRI breaches, incidents, change). The exam's worldview and good practice coincide perfectly here — the register exists to put a named owner and a current decision against every significant uncertainty the organisation carries.
Build that, keep its heartbeat, and the register stops being compliance furniture and becomes what it was always meant to be: the place where the organisation argues with its future, on the record.