Why Risk Registers Fail: The Four Structural Problems
Most risk registers are not managing risk. They are documenting that risk was once discussed. The difference between the two is structural, not procedural.
Almost every engineering programme has a risk register. Almost none of them are doing what a risk register is supposed to do. The document exists, it gets updated before each review, and it produces a traffic-light summary that satisfies a governance checkpoint. But ask what has actually changed in the programme’s exposure over the last quarter and the register rarely has an answer. It has entries. It does not have a position.
The reason is not that engineers are careless. It is that most risk registers are built around four structural problems that no amount of diligence fixes, because the problems are in the format itself.
The first problem: risk and issue are treated as the same thing
A risk is something that has not happened yet and might not happen at all. An issue is something that has already happened and now has to be managed. These require entirely different responses. A risk needs a trajectory assessment - is it stable, is it worsening, what would make it worsen faster. An issue needs a remediation plan with a deadline.
Most registers hold both in the same table, using the same fields, scored on the same likelihood-and-consequence matrix. The result is that live issues sit under a “likelihood” column that no longer means anything - the likelihood is 100%, it already happened - while genuine forward-looking risks are scored using the same instinct that produced the issue entries, which is retrospective, not predictive. The register becomes a mixed record of what went wrong and what might go wrong, indistinguishable from each other, and the distinction that would tell a reader which entries need urgent remediation and which need ongoing monitoring is lost.
The second problem: point-in-time ratings hide trajectory
A risk rated MEDIUM this month and rated MEDIUM last month looks unchanged. But a risk that was HIGH last month and has come down to MEDIUM is a very different situation from a risk that was LOW last month and has climbed to MEDIUM. Both show the same number in the register today. Neither the direction of travel nor the rate of change is visible in a standard likelihood-and-consequence snapshot.
This matters because the direction a risk is moving tells you far more than its current position. A risk climbing steadily needs intervention before it reaches a threshold, not after. A register that only ever shows the current rating cannot show a reviewer that a risk is accelerating toward a threshold it has not yet crossed. By the time the rating itself changes to reflect that, the intervention window has often already closed.
The third problem: closure happens without evidence
Risk registers close entries constantly, and the closure is often recorded as a single word - CLOSED - with no accompanying evidence of why the underlying condition no longer applies. A risk gets marked closed because the phase of work it was associated with has finished, because no one has raised it in a review for several months, or because the person who owned it has moved to a different project. None of those are evidence that the risk itself has actually been resolved.
A properly closed risk should be able to answer a simple question: what changed, and how do we know it changed. If a register cannot answer that question for its closed entries, those entries were not closed. They were abandoned, and the register is recording an assurance that does not exist.
The fourth problem: ownership is nominal, not real
Every risk register has an owner column. In most registers, the name in that column identifies who is accountable for updating the entry, not who is accountable for managing the underlying exposure. Those are different responsibilities. A project manager listed as the owner of a technical risk they do not have the authority or expertise to mitigate is not a real owner. They will report on the risk faithfully every month, and the risk will remain exactly where it was, because the person recording its status and the person capable of changing its trajectory are not the same person.
Real ownership means the named individual has the authority to commission the mitigation, the technical understanding to judge whether the mitigation is working, and the accountability to answer for the outcome if it is not. A register with owners assigned by project role rather than by capability produces beautifully maintained entries attached to risks that never actually move.
What a working risk register requires
Fixing this is not about working harder within the existing format. It requires separating risks from issues into genuinely different tracking mechanisms rather than shared table rows. It requires recording trajectory, not just current state, so that acceleration is visible before a threshold is crossed. It requires closure statements that state what evidence supports the closure, not just the closure decision. And it requires ownership assigned by capability to act, not by administrative convenience.
None of this is complicated to implement. It requires almost no additional tooling - the discipline is in the fields the register captures and the standard applied before an entry is allowed to be marked closed. What it does require is treating the register as a decision-support instrument rather than a compliance artefact. A register built this way tells a reviewer where the programme’s exposure actually sits today, which direction it is moving, and what evidence justifies every entry that has left the active list. That is what a risk register is for. Most of them were never built to do it.