A risk register kept as a document filed once at kickoff and revisited only when someone remembers to is not a risk-management discipline; it is a compliance artifact. Run properly, it is a living tool with four required fields per risk, updated as often as the program's own status: a probability (how likely is this to materialize, over what horizon), an impact (what it costs if it does, translated into the program's own units wherever possible, currency, schedule days, or a defined severity score when a currency translation would be false precision), an expected-value exposure (probability × impact, the single number that lets you prioritize risks that differ wildly in both likelihood and size on the same scale), and a named owner (a specific person, never "the team," accountable for watching it and triggering the response). The discipline that keeps this from becoming theater is a pre-agreed RAG threshold rule, stated once and applied consistently rather than assigned by whoever is presenting on the day, illustratively, Red when expected-value exposure exceeds a stated materiality threshold or probability alone exceeds a stated ceiling (either condition alone is enough), Amber in a defined band beneath that, Green below the band. Without a stated rule, "amber" or "red" becomes a matter of who is in the room, and a program with every risk mysteriously rated green right before a SteerCo meeting has not derisked anything, it has simply stopped measuring honestly.
Advertisement
How do you respond to a scored risk?
Once a risk is scored, exactly one of three response types applies, and confusing them is a second common failure: mitigation reduces the probability that the risk occurs at all (training, redundancy, a retention bonus for a flight-risk specialist); contingency reduces the impact if the risk lands anyway, without touching how likely it is (a pre-negotiated bridge financing path, a backup vendor on stand-by); and acceptance is the honest decision to do neither, because the expected-value exposure is small relative to the upside, but acceptance still requires a named owner and a stated trigger, a defined threshold that, if crossed, forces a re-evaluation, so that "we accepted this risk" never quietly becomes "we forgot about this risk." Worked Example 3 builds a four-risk register in full, scores it against a stated rule, and then shows exactly how the portfolio's total exposure changes once mitigation and contingency actions are actually applied, a register that moves, not one that sits.
What is an escalation trigger?
An escalation trigger does the same job at the governance level that a RAG threshold does at the individual-risk level: a pre-agreed rule (illustratively, any risk whose expected-value exposure exceeds a stated percentage of its initiative's target value) that automatically routes a risk to the steering committee, rather than leaving the judgment call of "is this bad enough to bother the SteerCo with" to whichever workstream lead is closest to it and most tempted to believe it will resolve itself. Practice P7 and the Program Governance Drill both drill this exact rule in isolation, because "should I escalate this" is one of the most common judgment calls a program leader is asked to make under pressure, and it should never be a judgment call at all, it should be arithmetic against a rule the SteerCo agreed to in advance.