How to Build a Risk Register People Actually Use

Illustration for: How to Build a Risk Register People Actually Use

A lot of risk registers are write-only. Risks go in during the annual review, nobody reads them again, and the document’s real function is to exist when an auditor asks for it. A register that people actually use looks different, it is short, owned, argued over, and it shows up in budget and project conversations. This post covers how to get from the first kind to the second.

Recognise the failure modes first

You cannot fix a register without being honest about how they die. These are the common patterns.

• The hundred-row spreadsheet. Every workshop output ever captured, no archive discipline, no way to tell live concerns from historical sediment. Nobody can review 100 rows, so nobody reviews any.
• The orphaned register. Risks “owned” by departments, committees, or people who left in 2023. A risk without a named, current, accountable individual is a note, not a risk.
• The audit-driven register. Updated in the fortnight before the ISO 27001 surveillance visit, untouched otherwise. The update is cosmetic, because review dates change and nothing else does.
• The compliance mirror. Rows that restate control gaps (“no MFA on VPN”) rather than risks. Useful information, wrong document.
• The static score. Every risk rated once at creation and never re-rated, so the register cannot show whether anything is getting better or worse.

If two or more of these describe your register, do not renovate it. Rebuild it small.

Keep it small enough to argue about

A register earns attention by being scarce. My working rule is that an organisation-level register should hold 10 to 20 risks, and a system or project register perhaps 8 to 15. Beyond that, attention collapses.

This means most candidate risks do not make the cut, and that is fine. Handle the overflow deliberately.

• Aggregate. Fifteen rows about individual legacy applications become one risk about the legacy estate, with the detail held underneath.
• Delegate. Operational risks live in team-level registers with a defined escalation trigger, not on the executive register.
• Close. If a risk has been green for two years and nobody would notice its removal, archive it with a date and reason. Archiving is not deleting, so you can bring it back.

Funnel diagram showing candidate risks being aggregated, delegated or closed, leaving an executive register of 10 to 20 risks

Handling the overflow deliberately so the executive register stays small.

The test of the right size is whether your risk committee could discuss every entry, even briefly, in a single meeting. If not, it is too long.

Write risk statements that say something

Register quality is mostly statement quality. “Cyber attack” is not a risk, and neither is “GDPR”. A usable statement carries a cause, an event and a consequence, which reads like this. “Because finance staff can approve payments they initiated, a compromised finance account could be used to send fraudulent payments, leading to direct loss of up to £500,000 and FCA reporting obligations.”

That statement tells the reader what to fix (segregation of duties), what to monitor (payment approvals), and what is at stake (money, regulator). A one-word risk tells them nothing. I cover statement structure in depth elsewhere, and for the register itself the rule is simple. If the mitigation is not implied by the statement, rewrite the statement.

Make ownership real

Ownership fails when it is assigned rather than accepted. The owner must be the person who controls the resources that treat the risk, which usually means a budget holder, not the security team. The CISO can own “we might mis-advise the business”, but the operations director owns the ransomware risk to the warehouse systems, because only they can fund and prioritise the fix.

Three practical tests show whether ownership is real.

• The owner can describe the risk without reading the register.
• The owner has done something, however small, since the last review, whether chasing an action, accepting a residual position in writing, or escalating for funds.
• When the risk fires, nobody debates whose incident it is.

If an executive refuses to own a risk, that refusal is itself information for the risk committee. Escalate it as such rather than quietly parking the row with the security manager, which is where unowned risks go to be forgotten.

Set a review cadence that matches volatility

Annual review is how registers rot. Different risks move at different speeds, so give each entry its own cadence.

• Red or high risks, and anything with open treatment actions, get reviewed monthly, in an existing management meeting rather than a special one.
• Amber or medium risks get reviewed quarterly.
• Green, accepted or slow-moving risks get reviewed every six or twelve months.

A review is not “confirm score unchanged”. Ask three questions. Has the exposure changed, have the actions moved, and would we still accept this if it were new today? Record the answer in one line with a date. A register whose last-touched dates are all the same day is telling you the reviews are theatre.

Trigger-based review matters as much as calendar-based review. A relevant incident, whether yours or a peer’s, a major change programme, a new supplier, or a pentest report should each prompt a look at the affected entries within days, not at the next quarterly.

Table of review cadences by risk state with a strip of trigger events that prompt review within days

Review cadence matched to volatility, with triggers that bypass the calendar.

Connect the register to decisions and money

This is the difference between a compliance artefact and a management tool. A used register leaves fingerprints on decisions.

• Budget lines reference risk IDs. The business case for the identity programme cites R-04 and the expected movement in its rating, and next year’s review checks whether the movement happened.
• Project boards inherit relevant register entries at initiation and hand new ones back at closure, instead of inventing a parallel RAID log that never reconciles.
• Risk acceptance is a signed decision with a date and an expiry, made by the owner at the level your scheme requires, not a quiet downgrade in the spreadsheet.
• Board reporting shows movement rather than a static heat map, meaning which risks changed, why, and which decisions are needed from the board this quarter.

When someone asks for money or a policy exception, the first question should be “which risk does this relate to?”. Once that question becomes normal, the register maintains itself, because people need their risks on it to get things funded.

Hub and spoke diagram connecting one register entry to budget, projects, risk acceptance and board reporting

One register entry leaving fingerprints on budgets, projects, acceptances and board packs.

Where to start

Take your current register and run a brutal triage, archive everything nobody has touched in a year, merge duplicates, and rewrite the survivors as cause-event-consequence statements. Aim to walk out with 15 rows or fewer, each with a named owner who has agreed in conversation, not by email default. Then put the top five on the agenda of the next management meeting that already exists and ask each owner to speak to theirs for two minutes. That single meeting will do more for the register’s credibility than any tooling change, and it establishes the habit everything else builds on.

Risk register dashboard with scored and owned risks in RaptorGRC

A risk register dashboard in RaptorGRC.