Risk Register Template: Scoring, Responses and Residual Risk

What belongs in a project risk register — probability and impact scoring, the four response strategies, residual risk — and the mistakes that make registers useless.

Almost every project has a risk register. Far fewer have one that changes a decision. The difference is rarely the format — it is whether the register is scored consistently, owned by named people, and reviewed often enough that entries are still true.

What belongs in the register

Per risk:

• ID — a stable reference you can quote in a meeting
• Description — written as cause, event and consequence: "Because the vendor has not confirmed the interface spec, build may start late, which would push the September release." A two-word label tells a reader nothing in three months.
• Category — technical, resource, vendor, regulatory, financial. Categories are what let you notice that eleven of your fourteen risks are vendor risks.
• Owner — one named person. Never a team.
• Probability and Impact — each on a 1–5 scale
• Score — probability × impact, used for sorting and nothing else
• Response strategy — avoid, reduce, transfer or accept
• Mitigating actions — what is actually being done, with dates and owners
• Residual probability and impact — the position after those actions
• Status and last reviewed — open, mitigated or closed, and when it was last genuinely looked at

Scoring without fooling yourself

A 1–5 scale multiplied out gives a score from 1 to 25. The arithmetic is trivial; the definitions are what matter.

Write down what each level means for this project, in money, time or reputation. "High impact" means nothing on its own. "Impact 4 = delays go-live by more than one month, or costs more than €50,000" means something, and it means the same thing to everyone scoring.

Do the same for probability, in plain language: 1 is rare, 3 is roughly even, 5 is expected unless something changes. Without these definitions every assessor uses a private yardstick, and the register becomes a collection of opinions that cannot be compared.

Plot the results on a probability/impact heatmap. The point of the heatmap is not decoration — it is that a steering committee can see in two seconds which four risks sit in the red corner, which is a question they can actually answer.

The four response strategies

Avoid — change the plan so the risk cannot occur. Dropping a component, changing sequence, choosing a different supplier. The only strategy that removes a risk rather than shrinking it.

Reduce — lower the probability, the impact, or both. Most mitigations are here. Be specific about which of the two you are reducing, because they call for different actions: a rehearsal reduces impact, an earlier confirmation reduces probability.

Transfer — move the financial consequence elsewhere, through insurance or a contractual penalty. Note that transfer moves the money, not the disruption. A penalty clause does not make your release happen on time.

Accept — decide consciously to carry it. Legitimate for low-scoring risks, and legitimate for high-scoring ones where every alternative is worse. What makes acceptance defensible is writing down the trigger: the observable event that turns this into an issue and starts the contingency.

Residual risk, and why it is usually missing

Most registers score the risk once, list mitigating actions, and stop. That shows the plan, not the position.

Residual risk is the score after the actions have actually been completed. Two columns, re-scored at review. It matters for three reasons: it tells you whether the mitigation was worth its cost, it stops teams claiming credit for actions that changed nothing, and it gives a steering committee an honest view of exposure rather than an aspirational one.

If residual risk equals initial risk after four weeks of mitigation, that is a finding, not an embarrassment.

What makes a register go stale

Reviewing everything every time. A full read-through of forty risks takes an hour, so it gets skipped. Filter to risks scoring above your threshold plus anything due in the next fortnight, and review only those — ten minutes, every week, without fail.

Mitigating actions without dates. "Engage vendor" is not an action. "Confirm interface spec in writing with the vendor's delivery lead by 12 September — owner: Anna" is.

Closing risks silently. Keep closed entries with the date and the reason. In month nine somebody will ask why a decision was made, and the register is the only place that remembers.

Confusing the register with the RAID log. A RAID log tracks risks, assumptions, issues and dependencies at a summary level and is the right tool for weekly governance. A risk register goes deeper on risks alone, with scoring and residual positions. Small projects need only the first; programmes with a real risk profile need both, and the RAID log then references the register rather than duplicating it.

Building one

One sheet for the register, one for the dropdown lists that keep categories and statuses consistent, one for the heatmap. Conditional formatting on the score column so the red corner is visible without reading numbers. That is the whole thing — it should take an afternoon to build and five years to outgrow.