How Do You Keep a Risk Register 'Alive' Instead of a Compliance Document?

A delegate said something on a Tuesday afternoon course that has stuck with me longer than most feedback does. She'd been maintaining a risk register for three years across two different employers, and she said the honest truth was that nobody opened it except her, and only then the week before an audit. Between audits it sat in a shared drive, untouched, technically current because nothing had been deleted from it, but not actually reflecting anything true about the project. It existed. It just wasn't doing anything.

That distinction matters more than it sounds. A document can be perfectly compliant and completely useless at the same moment. Every field populated, every risk scored, every owner named, and still nobody in the room making a decision because of it. The register had become something you produce for governance rather than something governance actually runs on.

Most training on risk management spends its time on the mechanics: probability and impact scoring, heat maps, escalation thresholds. Useful, and worth knowing properly. But mechanics don't explain why one project's register drives real conversation in a steering group and another's gets glanced at, nodded through, and closed again inside ninety seconds, with the same template, the same scoring method, and often the same trainer having taught both project teams how to fill it in.

It's tempting to blame the tool. Organisations switch from spreadsheets to dedicated risk software, add colour coding, introduce a dashboard, and the underlying pattern barely shifts. The new system gets populated with the same care as the old one did, reviewed with the same reluctance, and treated by most of the room as something to be seen updating rather than something to actually use. A better register template has never, on its own, produced a better conversation about risk. If it did, this would have been solved by procurement years ago.

What I've noticed, watching this play out across very different organisations and very different frameworks, is that the register's condition has almost nothing to do with the document and almost everything to do with what happens to it between the moments someone is forced to look at it.

A register stays alive when it changes what somebody does before the risk lands, not just what gets recorded after it has. That sounds obvious stated plainly, and it is largely why nobody says it plainly in most training courses. It's easier to teach the scoring matrix.

Consider what actually keeps a document in that condition. It has to be current in a way that costs something to maintain, reviewed often enough that stale entries get noticed and challenged rather than quietly rolling over week to week. It has to carry ownership that means something, where the named person can actually explain, unprompted, what they've done about their risk since the last time anyone asked. And it has to be discussed somewhere with enough authority that a genuine change of direction can follow from that discussion, not just a status update logged and forgotten.

None of that requires more fields on the template. If anything, most registers I've seen would improve by carrying fewer risks, tracked properly, rather than more risks tracked in name only.

I worked with a delivery team a few years ago where the pattern was familiar enough that I suspect most practitioners reading this will recognise it without needing the specifics. The register ran to over forty lines by the midpoint of the project. Most of those forty had been sitting untouched since the kickoff workshop where they were first raised, still scored exactly as they'd been scored on day one, still assigned to owners who had since moved onto other work entirely. Three risks, out of the forty, had actually shifted anyone's plan. One of those three had, six weeks earlier, driven a genuinely uncomfortable conversation between the project manager and the sponsor, resulting in a sequencing change nobody had wanted to make but that the project needed. That conversation, not the document itself, is what the register is for. The other thirty-seven lines were paperwork wearing the same font.

What separated those three from the rest wasn't better analysis at the point of entry. It was that somebody kept asking about them out loud, in a forum where the answer had consequences. A risk that only ever gets discussed in a report nobody reads stays theoretical indefinitely, however accurately it was scored the day it was written down.

This is where governance training and Agile training tend to talk past each other slightly, and it's worth naming directly rather than smoothing over. The structured, plan-driven tradition is good at making sure the register exists, is complete, and is reviewed on schedule. The Agile tradition is good at making sure whatever surfaces gets acted on quickly, inside a short cycle, before it can quietly age into irrelevance. Neither habit alone produces a living register. The completeness without the cadence produces exactly the compliance document the delegate described. The cadence without the discipline of actually recording and owning risks properly just produces a series of urgent conversations with nothing joining them up afterwards.

A register worth keeping does both at once. It's reviewed with enough regularity that entries can't quietly go stale, and it's discussed somewhere the answer changes what happens next, not just what gets minuted. Everything else, the scoring method, the colour coding, the escalation matrix, is scaffolding around that one requirement. Useful scaffolding. Not the point of the exercise.

The delegate who raised this on that Tuesday afternoon wasn't wrong to feel like her register was theatre. Most are, for exactly the reason she described: they get attention on a schedule set by audit, not by risk. The fix isn't a better spreadsheet. It's deciding, deliberately, who has to answer for each live entry, and building a forum where that answer is expected to cost someone something if it's wrong. Everything else follows from that one decision, and almost nothing else does.

If you'd like to talk through what that looks like on your own projects, you're welcome to get in touch about training that changes how registers actually get used.

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.