What a Risk Table Still Needs Beyond the Basics
Even a risk table with every core field correctly filled in can still miss a risk that has simply gone quiet, or one that is about to compound with another entry sitting two rows away, because neither of those things has a field of its own.
A risk table with every core field correctly filled in, severity, trajectory, ownership, mitigation status, evidence-based closure, is a genuine improvement over most registers in use today. It is still not complete. There are two failures a table like this can walk straight into, and neither one has a field built to catch it.
The difference between old and forgotten
Days open is a useful number, but it cannot tell the difference between two very different situations. A risk open for one hundred and twenty days that has been actively reviewed every fortnight, its trajectory checked, its owner engaged, is in a fundamentally different state than a risk open for the same one hundred and twenty days that nobody has looked at since the week it was raised. Days open alone shows the same number for both.
The fix is a separate field, a last reviewed date, distinct from the date the risk was first raised. Read together, these two dates tell a genuinely different story than either one alone. A large gap between today and the last reviewed date, even on a risk that has not been open very long in total, is the actual signal that an entry has gone quiet. A long time open with a recent, genuine review is not the same problem at all, and a table that only tracks days open will treat them identically.
The trigger that should already be written down
Every risk should carry a specific answer to one question, decided in advance, not worked out in the moment of crisis. What is the exact, observable condition that, if it occurs, means this risk stops being something to monitor and becomes something requiring immediate escalation. This needs to be concrete enough that anyone, not just the risk’s owner, could check whether it has happened. A trigger like the client raises further concerns is not concrete. A trigger like the vendor confirms delivery will slip past a named date is.
Deciding this in advance matters because escalation decided under pressure, in the moment a risk is clearly worsening, is far more likely to be delayed, softened, or argued away than a trigger that was written down calmly, before anyone had a reason to want to avoid raising it.
The risk that hides between two rows
A flat table, even a well built one, has a structural blind spot. Each row is examined on its own. Nothing in that structure ever asks whether two separate, individually moderate entries might interact with each other in a way that produces something considerably worse than either alone. This is exactly the kind of compounding failure that turns a manageable situation into a serious one without any single entry’s rating ever changing.
The fix is a field that names the connection directly, referencing the other risk or risks a given entry might interact with. This does not need to be exhaustive or theoretical for every possible pairing. It needs to exist for the cases someone has actually noticed, so that a real connection, once spotted, does not simply live in one person’s memory until it is too late to matter.
Why none of this replaces judgement
A table built with every one of these fields, severity, trajectory, ownership, evidence-based closure, review currency, a named trigger, flagged connections, is a considerably stronger instrument than the version most organisations actually use. It still requires someone to read it, ask whether what it shows still makes sense, and decide what to do next. The fields exist to make that judgement better informed. They were never going to replace the person doing the judging, and a table mistaken for a substitute for that person is no safer than one with half the fields missing.