A risk register that gets read: mitigate it, accept it, or it blocks

Most project risk registers are written in the first week, admired once, and opened again when something on the list has already happened. The format is rarely the fault. The register fails because nothing depends on it: a risk can sit at "high" for three months and the project carries on exactly as before.

A register gets read when its entries can stop something. That takes fewer columns than most templates have, and one rule most of them lack.

Five things per risk, and no more

Probability scores, impact matrices and colour grids are left out on purpose. A five-by-five grid produces a number that looks like analysis and settles nothing: two people will score the same risk 6 and 15 and both be defensible. Severity in four words, tied to a consequence, is enough to sort a list.

Write the risk as an event

"Integration" is a topic. "Security" is a department. A risk is something that could happen on a day: a named thing arriving late, a named assumption turning out false, a named person being unavailable. The test is whether someone could later say, without argument, that it did or did not happen.

• Weak: "Data quality."
• Strong: "The legacy export has duplicate customer IDs. If more than a few hundred need manual merging, migration takes two extra weeks."

The rule most registers lack: only three ways out

A risk leaves the list of live risks in one of three ways.

• Mitigated. Something was done and the risk is smaller or gone. The entry says what.
• Accepted. Somebody with the authority looked at it and decided to carry it. This is a decision with a name on it, not a shrug.
• Closed. It can no longer happen: the date passed, the dependency shipped, the scope it belonged to was cut.

"Being watched" is not on that list, and this is where registers go soft. Moving a risk from open to monitoring changes nobody's week and should not change what the register says about the project. If a serious risk is only being watched, it is still unresolved.

Make severity cost something

The register starts being read on the day a high or critical risk blocks a commitment. The rule is short: work with an unresolved serious risk is not ready to be promised. The ways forward are the three above, or a commitment exception in which a named person accepts committing anyway and says why.

That one rule fixes severity inflation and deflation at once. Nobody marks everything critical when critical stops the plan, and nobody quietly downgrades a real risk when the downgrade has to be explained.

Two signals worth more than a score

• No mitigation. A serious risk with an empty mitigation column is a decision nobody has made yet. Say so on the page instead of filling the cell with "monitor closely".
• Age. A risk that has been open for two months is telling you something a fresh one is not. Sort by age now and then, and ask of the oldest ones whether they are being carried or ignored.

When to read it

Not in a risk review meeting. At two moments that already exist: when the work is about to be committed, and at each check-in while it is being delivered. A register that has its own meeting gets its own audience, which is usually nobody who can act.

And when there is nothing to list, write that down as an answer. "No known risks" is different from "nobody looked", and only the first is a finding. Dependencies on other teams follow their own rules and are better kept apart, as in the dependency you do not own; a combined log of risks, assumptions, issues and dependencies is covered in a RAID log without the theatre.

If you use DeliverySheet

Risks are recorded on each demand in Plan with a title, a severity (low, medium, high or critical), a mitigation and a status: open, monitoring, mitigated, accepted or closed. The product counts open and monitoring as unresolved, everywhere it shows a risk number. An unresolved high or critical risk keeps a demand from reading "Ready to commit"; the ways past it are to mitigate it, accept it, or commit with the four-field exception.

The Reports page has a Risk register across all demands: each unresolved risk with its severity, its demand and that demand's owner, the mitigation (or "No mitigation" where there is none) and its age. It has no probability score and no matrix, and it does not remind anyone. Reading it at the commitment and at the check-in is the part that stays with you.