Risk Register Explained: Identification, Scoring, Ownership and Review

A risk register is a list of things that might happen, what they would cost, how likely they are, who owns each, and what is being done about them. It is one of the oldest project management artefacts and one of the least useful in practice — not because the idea is wrong, but because most registers are written once, scored optimistically, reviewed as an agenda item, and never change a decision.

A register that never changes a decision is a document. This guide is about the other kind.

What a risk actually is#

A risk is a future event that might happen and would have an impact. Three conditions, all necessary.

If it has already happened, it is an issue, and it belongs in a different list with a different response. Mixing the two is the most common structural error — issues crowd out risks, the register becomes a status report on problems, and forward-looking thinking stops.

Write each risk in a form that separates cause, event and effect:

Weak: Resourcing.

Usable: Because the integration work depends on two developers who are also supporting the current platform, there is a risk that their availability drops below plan during a production incident, resulting in a two- to four-week delay to the integration milestone.

That structure forces you to name the cause — which is the only part you can usually act on — and the effect, which is what determines whether it matters.

Scoring without inventing precision#

The standard approach multiplies likelihood by impact on a five-point scale. It is useful for sorting and it is not arithmetic; a score of 12 is not meaningfully worse than a score of 10.

Two habits keep it honest:

Define the scales in your own terms. "High impact" should mean something specific — a delay over a month, a cost over a stated figure, a regulatory breach, a customer-visible outage. Undefined scales produce scores that vary by author and cannot be compared.

Score the effect, not the anxiety. The risks people feel strongly about are not always the ones that would hurt most. The register is where that distinction gets tested.

Be alert to the two failure directions. Everything scored high produces a register nobody can act on. Everything scored medium — the most common outcome — produces a register that says nothing at all.

Ownership is the load-bearing column#

Every risk needs a named individual who can actually influence it. Not a team, not "the project", not the project manager by default for all thirty of them.

A risk owned by the person who can act on it gets acted on. A risk owned by whoever wrote it down gets reported on. This single column separates registers that work from registers that are maintained.

Responses: the four options, and the one that gets skipped#

Avoid — change the plan so the risk cannot occur. Usually the cheapest response and the least considered, because it requires changing something already agreed.

Reduce — lower the likelihood or the impact. The most common, and it must have a specific action with an owner and a date, or it is an intention.

Transfer — insurance, a contract term, a supplier taking the obligation. Note that transferring financial consequence does not transfer operational consequence: if the supplier is late, you still have a late project.

Accept — decide to live with it, deliberately and on the record, with a trigger that says when you would reconsider. Accepting a risk explicitly is a legitimate and underused decision.

Every response needs a date. A mitigation with no date is a hope with a project code.

Making the review change something#

The register earns its keep in the review, and most reviews are a read-through of the same twenty rows.

Better structure, and it takes fifteen minutes:

1. What changed? Any risk whose likelihood or impact moved, and why.
2. What is new? Since the last review — new dependencies, new information, new commitments.
3. What has passed? Risks that can no longer occur. Close them. A register that only grows is ignored within a quarter.
4. What is overdue? Mitigations past their date. This is the list that matters most and the one usually absent.
5. What became an issue? Move it, and note what the register said about it beforehand — that feedback is how the team's risk judgement improves.

Why registers fail#

Written at initiation and frozen. The risks of month one are not the risks of month six.

Everything is medium. Nobody wants to be the person who scored something high, so the register loses its ability to prioritise.

Mitigations without owners or dates. "Monitor closely" appears in a majority of registers and commits nobody to anything.

Risks nobody can act on. "Risk that the market changes" is a condition, not a project risk. Include it only if there is a response.

Closed risks left open. A register cluttered with things that can no longer happen stops being read.

Kept for governance, not for the team. If the register exists because a gate requires it, it will be updated the day before the gate and at no other time.

A realistic starting point#

Ten to fifteen risks, each written in cause-event-effect form, each with a named owner, a scored likelihood and impact using scales you have defined, a specific response with a date, and a review every fortnight that follows the five questions above.

Ten risks that are genuinely managed beat sixty that are catalogued. The register's purpose is to change what you do, and thirty rows nobody has read is not a plan.

FAQ#

What is the difference between a risk and an issue?#

A risk might happen; an issue has happened. They need different lists, different responses and different reviews. Combining them lets today's problems crowd out tomorrow's — which is exactly the failure the register exists to prevent.

How many risks should a register hold?#

However many are real and actionable — typically ten to twenty on a mid-sized project. Beyond about thirty, nobody reviews them properly and the important ones are lost among the routine.

Who owns the register?#

The project manager owns the process; individual risks are owned by whoever can influence them. Assigning every risk to the project manager is the most common way ownership becomes nominal.

How often should it be reviewed?#

Fortnightly on an active project, and immediately whenever something material changes — a dependency shifts, a supplier misses a date, a key person leaves. A monthly cycle is often slow enough that risks become issues between reviews.

Should we quantify risk in money?#

Where you can, it sharpens the conversation considerably — an expected cost makes the case for mitigation spend far better than a colour. Where the numbers would be invented, a defined qualitative scale is more honest. Invented precision is worse than an admitted estimate.

What about opportunities?#

The same discipline applies to positive uncertainty, and some frameworks include them in the same register. It works if the team treats them seriously; in practice opportunities tend to be listed and never acted on, so consider whether a separate short list would get more attention.

Our sponsor does not want to see high risks. What now?#

That is itself a serious project risk, and it usually stems from high risks being treated as criticism rather than information. It helps to present each with its response and a decision required, so the conversation is about choices rather than about blame. A register that is politically edited is worse than none, because it creates false assurance.

Related Articles#

Set the boundary in the Project Charter, govern scope movement with Change Management, and feed what actually happened into Lessons Learned.

What else is coming for Risk Register