A Risk Register That Earns Its Place: A Checklist for This Week
Open most project risk registers and you find a tidy spreadsheet that no one has touched in weeks. Rows of vaguely worded threats, a column of red-amber-green ratings nobody trusts, and an owner field full of the same two names. It looks like risk management. It is mostly archaeology. A register only earns its place if it changes a decision, prompts an action, or warns someone in time to do something about it.
The good news is that fixing a stale register is fast. You do not need a new tool or a new framework. You need a working session this week and a short checklist to run your register against. Here it is.
The checklist
Each risk is written as cause, event, effect. Replace one-word entries like "resourcing" with a sentence: because a key role is unfilled (cause), the design phase may slip (event), pushing the milestone past the funding deadline (effect). If you cannot write the chain, you do not yet understand the risk.
Every risk has one named owner. Not a team, not a department, a person who has agreed to watch it and act. A risk owned by everyone is owned by no one. If two risks share an owner who already has ten, that is a finding in itself.
Probability and impact are rated, and the rating means something. Agree on what high, medium and low actually mean before you score, even roughly. Otherwise the colours are decoration. Sort by the combined exposure so the top of the list is genuinely the top.
Every meaningful risk has a response, with a date. Decide whether you will avoid, reduce, transfer or accept it, then name the specific action and when it is due. "Monitor" is not a response; it is a way of doing nothing on purpose.
Triggers are defined for the ones that matter. For your top risks, write down the early signal that says this is now happening, and what you will do when you see it. A trigger turns a risk into a plan instead of a surprise.
Closed and changed risks are dated and kept. When a risk passes or is retired, note when and why rather than deleting it. The history is how you defend a decision later and how you get better at estimating next time.
Two columns most registers forget
Add a date-last-reviewed column and a current-status column. The review date tells you at a glance which risks have gone stale, and a register with rows untouched for a month is sending you a message. The status column, distinct from the rating, captures whether the risk is rising, steady, or fading. Together they turn a static list into something a project board can actually read in two minutes.
One more habit worth building, especially with hybrid and distributed teams: capture risks where the work is discussed, not in a document people open once a quarter. If new risks only surface in the formal review, you are learning about them too late. The register should be a live reflection of what the team already worries about in the hallway, or these days, in the chat thread.
Run it as a conversation
A register maintained alone at a desk drifts toward fiction. Bring the top ten risks to a short, regular session and ask three plain questions: has anything changed, is the owner still the right person, and is the response still the right move. That cadence does more for risk management than any template. The artifact matters less than the recurring conversation it forces, because the point was never the spreadsheet. The point is that the team sees what is coming and acts in time.
If your registers have quietly become record-keeping rather than risk management, XNM's program & project delivery advisory can help you make risk a working part of how the project is run.