Risk Register Template

Why most risk registers stop being updated after kickoff

A risk register only earns its place if someone still opens it in week eight. Most don't survive that long, because it's treated as a one-time planning artifact instead of something the project keeps checking against as the work actually progresses. It gets filled in once, feels complete, and then quietly stops being true.

It's built once, during planning, as a spreadsheet. Everyone lists risks at kickoff, feels thorough, and the sheet is already stale by the time the second sprint starts, because nothing prompts anyone to reopen it.

Risks get identified but nobody owns them. "The team" is listed as the owner, which means no specific person is responsible for doing anything about it. Nothing happens until the risk turns into a problem someone can no longer ignore.

It lives in a different file from the board. Mitigation is a sentence in a spreadsheet cell, not a task anyone is tracking, so it competes with nothing for attention on a normal day and usually loses to whatever's actually on the board.

Likelihood never gets revisited. A risk rated Low in week one stays rated Low forever, even after something happens that should have moved it to High, because updating the register isn't part of anyone's routine.

Closed risks get deleted instead of kept. Once a risk stops being a concern, the row disappears, and it takes with it the only record that the team saw it coming and did something about it. That's useful evidence the next time someone plans a similar project.

Impact is rated once and never checked against what actually happened. A risk marked Low impact that turns out to cost two weeks of rework never gets corrected in the register, so the next project's estimates repeat the same mistake with the same false confidence as the last one.

Keep this register on ShipSprint next to the board it describes and most of that erosion just doesn't happen: the delivery forecast recalculates from real sprint velocity, so a risk you rated Low can be flagged for review the moment a date actually starts slipping, instead of waiting for someone to remember the spreadsheet exists.

How to use it

1. 01List risks during planning, before the first one actually lands, not as a retrospective exercise put together after something's already gone wrong.
2. 02Rate likelihood and impact quickly. High, Medium or Low for each is enough; spending a meeting arguing over the exact score is time better spent elsewhere.
3. 03Assign exactly one owner per risk. If the honest answer is "nobody specific," that's worth noticing before it becomes a problem, not after it already has.
4. 04Turn the mitigation into a task on the board, so it's visible, trackable work rather than a line in a register that gets checked once a month at most.
5. 05Review the register against the forecast each sprint. A risk whose likelihood should move up is usually one where the forecast has already started drifting away from plan.
6. 06Close risks instead of deleting them. A closed entry with a note on how it was handled is worth more to the next project than a row that just disappears once it stops being urgent.
7. 07Check the register at the same time as the forecast, not on its own separate schedule. A risk review disconnected from the delivery numbers tends to drift into a general worry session instead of a specific one.
8. 08Keep the list short enough to actually read. A register with sixty entries gets skimmed, not reviewed. Most projects are better served by ten well-maintained risks than forty half-forgotten ones.
9. 09Retire risks that never materialised, honestly. Closing a risk as "did not occur" is a legitimate outcome. It doesn't need to have happened to be worth having tracked.

The register works best as a short, honest list rather than an exhaustive one. Ten specific risks with named owners beat forty vague ones nobody is actually watching, and a shorter list is one people will actually read before a review instead of skimming past.