What a Risk Table Should Actually Contain
Most risk tables collect status without ever forcing a decision. The fields a table chooses to include, or leaves out, determine whether it can actually catch a risk before it becomes a failure or only explain one after the fact.
The fields in a risk table are not administrative detail sitting alongside the real engineering work. They are the actual mechanism of management. What a table has a field for tends to get tracked, questioned, and acted on. What it has no field for tends to quietly go unmanaged, not because anyone decided it did not matter, but because nothing in the structure ever asked about it.
Planned but not enacted, not planned, planned and enacted
A single severity rating cannot tell a reader whether a mitigation actually happened. A risk table needs a status that separates planning from execution explicitly, whether a mitigation was planned but never actually carried out, never planned at all, or planned and genuinely enacted. This catches a specific and common failure that other fields miss entirely, a mitigation that exists convincingly on paper, referenced in every review, while nothing behind it has actually been done.
Severity alone is not enough
Low, medium, and high ratings are necessary, but a rating on its own only shows where a risk sits today. It says nothing about which direction the risk is currently moving. A table that captures severity without also capturing trajectory, whether the underlying condition is stabilising, worsening, or improving since the last review, hides exactly the kind of acceleration that turns a moderate risk into a sudden failure without warning.
A risk owner who can actually act
The owner field only has value if it names someone with real capability to influence the risk, not simply whoever is responsible for updating the table’s status each month. An owner assigned for administrative convenience will report faithfully on a risk that never actually moves, because the person recording its status and the person capable of changing its trajectory are not the same person.
Action taken and next action, kept separate
Collapsing what has already been done and what happens next into a single mitigation field loses something important. Action taken is a record of what has occurred. Next action is a commitment to what happens going forward, with its own timeline and its own owner. Keeping these as two distinct fields makes it immediately visible whether a risk has stalled, with an action taken field that has not changed in months and no next action ever specified.
Whether the action actually helped
Most tables record that an action was taken and stop there. A genuinely useful table asks a further, more honest question, did that action actually help resolve the risk. Recording an action without checking its effect creates a false sense of progress, activity that looks like management without any evidence the underlying exposure has actually changed.
Closure that states its evidence
A status of open or closed is necessary, but closed on its own is not enough. Closure needs to state what evidence justifies it, what specifically changed, and how that change was confirmed, not simply that the item has stopped appearing on someone’s list of open concerns. A closure with no evidence attached is not a resolution. It is often just a risk that has quietly been forgotten, recorded as if it had been solved.
These fields do the work of forcing better tracking. None of them, on their own, replace the judgement of someone actually reading the table and asking whether what it shows still makes sense.