What Should a Risk Register Actually Include, and What Should You Leave Out?

Ask a project manager whether their risk register is up to date, and most will say yes. Ask when it was last read by anyone other than the person maintaining it, and the answer gets quieter.

That gap is the actual problem. Not the format, not the tool, not whether it lives in a spreadsheet or a proper project management system with colour-coded heat maps. The problem is that most registers are built to be complete rather than built to be used, and those turn out to be different goals that pull against each other.

A risk register that's complete has an entry for everything anyone has ever worried about. Supplier delay. Key person leaving. Budget overrun. Scope creep. Weather. Each one sits there, scored on a five-point scale for likelihood and impact, coloured amber or red, and revisited every fortnight in a meeting where nobody has anything new to say about most of them. The register grows. Genuine review time doesn't. So the entries that actually need attention sit in the same long list as the ones that were true eighteen months ago and haven't moved since, and the reader's eye slides over both the same way.

A risk register that's used looks different, and smaller. Every entry passes a simple test: could someone who wasn't in the room when it was written act on it without asking a follow-up question. That means a proper risk statement, not a topic. Not "supplier risk" but something closer to "if the steel supplier's delivery slips past week six, the frame erection sequence loses its buffer and the programme end date moves." Cause, event, and consequence, written as one sentence, not three separate boxes that only make sense once you've read all of them together.

It means a named owner, not a team or a function. "Procurement" is not an owner. Someone specific who holds that risk, who would be the person a sponsor asks about it directly, is. If nobody can be named, that's usually a sign the risk hasn't been properly understood yet, not a gap to paper over with a department name.

It means a genuine response, not a decoration. Avoid, mitigate, transfer, or accept, chosen deliberately and stated as an action rather than a category. "Mitigate" on its own tells a reader nothing. "Bring forward the second supplier conversation to week two so there's a fallback in place before the critical path depends on the first one" tells them what's actually going to happen.

And it means a live review point. Not "ongoing," which is a way of saying nobody has thought about when this stops being relevant. A specific trigger or date, after which the entry gets closed, downgraded, or genuinely escalated.

What doesn't belong is often more instructive than what does. Issues wearing risk clothing are the most common offender. A risk is something that might happen. Once the supplier has actually slipped, that's an issue, and it belongs on an issues log with a different kind of tracking, not sitting in the risk register scored as though it's still theoretical. Keeping it there muddies both documents and usually means the issue gets managed with less urgency than it deserves.

Boilerplate entries are the second. Every sector has its stock risks, and a register copied from last year's template will have them: generic statements about resourcing, generic statements about stakeholder engagement, present because someone once saw them on another project's register and thought they looked thorough. If an entry hasn't been genuinely thought through for this specific project, it isn't adding rigour. It's adding volume, and volume is exactly what erodes attention.

A PMO manager reviewing a programme's live tracker recently found an entry that had sat unchanged for four review cycles: owner listed simply as "the team," impact and likelihood both scored amber, response column reading "monitor." Nobody could say, when asked directly, what monitoring had actually involved. The risk it described had, in fact, already partly materialised three weeks earlier and been dealt with informally in a corridor conversation that never made it back to the document. The register hadn't failed because it lacked an entry. It had failed because the entry it had wasn't written to be acted on by anyone, including the person who wrote it.

None of this is really about format. A risk register in a two-column spreadsheet, written properly, will outperform an elaborate dashboard full of entries nobody could explain if asked. The discipline sits in what you're willing to leave off the page as much as what you put on it, and in writing every remaining entry as though someone with no context will have to act on it alone, because eventually, that's exactly what happens.

If your organisation's registers have drifted toward the first kind rather than the second, it's worth revisiting how they're actually reviewed, not just how they're structured. If that's a conversation worth having, you're welcome to get in touch about your PMP training options.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.