A risk register people update
The problem with risk registers is never the template. It is that nothing in the week forces anyone to open one.
A risk register survives when the process around it is designed, not when the spreadsheet is well formatted. That means a hard cap on rows, one named owner per risk, review triggered by events rather than by calendar, a rule for closing risks, and a visible link between a risk and a decision someone made. Registers with forty rows and no owners are abandoned within a month, every time.
Why registers die
A risk register is normally created during project setup, populated with twenty to forty entries in one sitting, presented at kickoff, and then never opened again. Nobody decides to abandon it. It simply never becomes the answer to a question anyone is asking.
Three mechanics cause this. The register is too long to read, so opening it costs ten minutes rather than one. The risks have no owner, so no individual feels the absence. And nothing in the operating rhythm requires it, so reviewing it is always the thing that gets cut when a meeting runs long.
Every fix below targets one of those three. None of them involve a better template, because the template was never the constraint.
Cap the register at ten rows
This is the change with the largest effect and the most resistance. Ten rows, hard limit. Adding an eleventh risk requires closing or merging one of the existing ten.
The objection is obvious: there are more than ten risks. There are. There are also more than ten risks you will not act on, and a register is not an inventory of everything that could go wrong. It is a working list of what you are actively managing. A list of forty is a list of zero, because attention does not scale.
The cap forces a genuinely useful conversation. To add a risk, someone must argue that it outranks an existing one, and that argument is where prioritisation actually happens. Without the cap, prioritisation is theatre performed through a probability-times-impact score that nobody has ever used to make a decision.
Keep a second, uncapped list if it helps people let go. Call it the watch list, review it quarterly, and be honest that nothing on it is being managed. The distinction between managed and merely noted is the point.
What each row must contain
| Field | Rule | Why |
|---|---|---|
| Risk statement | "If X happens, then Y, costing Z" | A risk written as a noun is a topic. A conditional is testable. |
| Owner | One named person, never a team | An unowned risk is a note, not a risk. |
| Trigger | The observable event that means it is happening | Without one, nobody knows when to act. |
| Response | Avoid, reduce, transfer or accept. Pick one. | "Monitor" is not a response, it is a refusal to choose. |
| Next check | A date or an event | Turns the row into something with a deadline. |
| Cost if it lands | A number, even a rough one | Ranking by adjective produces a register everything is High on. |
The conditional format is worth insisting on. "Data migration" is not a risk. "If the legacy export omits historical records, the reporting deliverable slips by two weeks and the launch milestone cannot be invoiced" is one, because it names the consequence and the money.
The cost column is where honesty enters. When every risk carries a dollar figure, the register self-sorts, and the entries that were only there for appearances get quietly deleted because nobody wants to write $0 next to them.
Review on triggers, not on a calendar
Weekly risk review is the standard advice and it is why registers die. After three weeks with no change, the review becomes a ritual of reading ten rows aloud, and the fourth week it gets skipped.
Trigger-based review works better. Open the register when one of five things happens: a milestone is reached, a new party joins the project, a date slips by more than a defined threshold, an assumption in the charter turns out to be wrong, or a risk owner changes.
These moments have something the calendar does not: a reason. Someone opening the register at a milestone is doing so because a boundary has been crossed and the risk profile genuinely changed. That review produces edits, and a document that gets edited stays trusted.
Keep one calendar review as a backstop, monthly rather than weekly, and treat a review with no changes as a signal to shrink the register rather than a sign that everything is fine.
Risk, issue and assumption are three different lists
Registers bloat because three different things get filed into one. A risk has not happened yet and is probabilistic. An issue has happened and needs resolving now. An assumption is something you have decided to treat as true without verifying it.
Mixing them wrecks the register. Issues are urgent, so they dominate attention and the actual risks scroll off the bottom. Assumptions are static, so they pad the list and make it feel long and stale.
Split them into three lists with different rhythms. Issues get worked daily and closed. Risks get the ten-row cap and trigger-based review. Assumptions get validated once and then become either a fact or a risk. This split is also what makes escalation legible, and the practical difference between an issue, a risk and a blocker is worth settling as vocabulary before the first status report goes out.
The assumption list is the underrated one. Most project surprises are invalidated assumptions rather than materialised risks, and an assumption list forces someone to actually check the thing everyone was confident about.
Where to find the risks worth listing
Brainstorming produces generic entries: key person leaves, requirements change, scope creeps. All true, none actionable. A structured technique produces better material because it forces you to look at specific mechanisms rather than general anxieties.
Failure mode analysis is the most transferable. You walk each component of the system, ask how it can fail, and record the effect of that failure downstream. Microsoft's Well-Architected guidance describes identifying failure points and their effects component by component, which produces concrete risks like "if the nightly export job fails silently, reporting shows stale data for a full day before anyone notices".
That is a risk you can write a trigger and a response for. "Data quality issues" is not.
For process rather than technical risk, structured frameworks help. Axelos publishes the PRINCE2 and ITIL bodies of guidance that some enterprise and public-sector clients require by name, and their risk vocabulary is a reasonable starting taxonomy even if you never adopt the full method.
Closing risks, and why nobody does it
Registers grow monotonically because closing a risk feels like tempting fate. Nobody wants to be the person who marked something closed the week before it happened. So the register accumulates entries that expired months ago, and the noise buries the live ones.
Write a closure rule and apply it mechanically. A risk closes when its trigger window has passed, when its response has been executed, when it has materialised and become an issue, or when the work it applied to has been descoped. Record which of the four it was.
Recording the reason is what makes closure socially safe. "Closed: trigger window passed, migration completed 14 March" is a fact rather than a prediction, and nobody is exposed by writing it.
Keep closed risks in the file rather than deleting them. When a project is reviewed afterwards, the closed list is frequently the most useful artifact anyone produces, because it shows what was foreseen and what was not.
Tracking risks where the work lives
A register in a spreadsheet is a register in a place nobody visits. If your delivery work lives in a tracker, the risks should live there too, as items of a distinct type with their own owner and due date.
The advantage is that the tool already does the nagging. Microsoft's Azure Boards documentation covers work item types as distinct records with their own fields and workflow, and a risk modelled that way appears in someone's queue with a date attached rather than sitting in a document waiting to be opened.
The disadvantage is visibility to a sponsor who does not use the tracker. Solve that at the reporting layer rather than by maintaining two registers. A status report that pulls the current top three risks from the tracker keeps one source of truth, which is the same principle behind reporting cycles that assemble themselves rather than being rebuilt monthly.
What a working register looks like in practice
On a transit BI migration involving 154 data sources moved without an unplanned outage, the register was short and specific. The entries that mattered were about source-system owners being unavailable during cutover windows and about validation cycles that could not be compressed. Those are the risks with owners, triggers and costs. "Migration complexity" would have been on a generic register and would have helped nobody.
The test for whether your register is real: pick a row at random and ask its owner what they did about it last month. If they can answer, the register is working. If they did not know they owned it, you have a formatting exercise.
Where registers are absent entirely, it is usually a symptom rather than an oversight. Nobody owns the sequence, so nobody owns the risks to it. That gap is the same one that shows up as scope disputes and missed dates, and closing it is the practical substance of treating delivery as an owned function rather than a shared responsibility.
Start with three rows, not thirty. Three risks with real owners and real triggers will do more for a project than a comprehensive register that nobody opens after week one.