Building a risk register the business actually uses

Ask a risk manager how the register is doing and you will usually hear about completeness — how many risks, how many with treatment plans, how many overdue reviews. Ask an operations director when they last consulted it and the answer is often never. Both statements can be true simultaneously, and that gap is the actual problem.

1. Granularity determines whether a risk can be owned

"Cyber attack" is not a risk. It cannot be owned by anyone specific, scored meaningfully, or treated with any particular control. It generates a heat map entry and no action.

"Compromise of privileged administrator credentials permitting unauthorised change to production financial systems" is a risk. It has a natural owner, a scoring conversation grounded in something concrete, and an obvious set of candidate treatments.

The test is simple: if you cannot name the person who would be accountable if the risk materialised, the risk is written too broadly. Split it until you can.

2. Ownership requires acceptance, not assignment

Registers are commonly populated by the risk function, who then assign owners. Those owners frequently learn they own a risk when a reminder email arrives about an overdue treatment action they never agreed to.

Ownership has to be established in conversation. The owner should agree the scoring, agree the treatment plan, and agree the dates — because they are the person who will have to deliver against them. This is slower to set up and dramatically more effective afterwards. An owner who accepted the risk chases their own actions.

3. Scoring must be consistent to be comparable

The purpose of scoring is to allow risks to be compared so that finite resources go to the largest exposures. That only works if two people assessing similar risks arrive at similar scores.

• Define impact scales in concrete terms — financial ranges, regulatory consequence, service outage duration, number of data subjects affected
• Define likelihood against a stated time horizon; "likely" means nothing without a period attached
• Calibrate by scoring a handful of known risks as a group before rolling the methodology out
• Assess inherent and residual risk separately, or control effectiveness becomes invisible

Where scoring is inconsistent, the heat map reflects assessor temperament rather than exposure, and nobody senior will make a resourcing decision from it twice.

4. Intake determines what the register can contain

If the only way a risk enters the register is through a periodic workshop run by the risk function, the register contains the risks the risk function already suspected. The engineer who knows about an unsupported dependency, the finance analyst who spotted a control gap in a payment process — their knowledge never arrives.

A working intake route is low-friction, open to everyone, and triaged rather than published directly. Someone raises a concern in a short form; the risk function assesses whether it is a new risk, an aspect of an existing one, or an operational issue for elsewhere. Crucially, the person who raised it is told what happened. Nothing suppresses reporting faster than raising something into silence.

Signs it is working

• Risks are raised between review cycles, by people outside the risk function
• Treatment actions close on time more often than they are extended
• Risks above appetite are formally accepted by a named person, with a recorded rationale and review date
• The register is cited in project and investment decisions rather than only in committee packs
• Scores change because exposure changed, not because a different person assessed it