Risk escalation decision tree template
A risk escalation decision tree covering tolerance, impact threshold, authority and urgency, with named outcomes from manage locally to raise as an incident.
How it works
Rename the lanes to your real decision rights
Replace Risk owner, Project manager, Project board and Executive risk committee with the bodies that actually hold authority in your organisation. Keep the lanes to who answers each question. If a risk committee does not exist, merge that lane into the board and say so, rather than leaving a body in the chart that never meets.
Write the escalation threshold as a figure and a duration
'Impact above the escalation threshold?' is inert until you attach numbers. Most organisations set a cost figure tied to the delegated spend limit and a schedule figure tied to float or a contractual milestone, then treat whichever is breached first as the trigger. Put both on the node so anyone can apply the test without asking.
Define tolerance separately for each owner
'Within the owner's risk tolerance?' assumes tolerance has been delegated and recorded. Set it per owner or per risk category, not once for the whole project, and state it in the same units you score risks in. If nothing is written down for an owner, the honest answer is No, and the risk goes up.
Split budget from authority
'Mitigation within budget and authority?' is deliberately two tests. A fix can be affordable and still require a decision the owner is not authorised to take, such as changing a contract, standing down a supplier or accepting a delay. Name both limits so the Beyond branch fires for the right reason.
Set the incident trigger and who can pull it
Decide what makes 'Is harm or breach imminent?' a Yes, and name who may declare it without waiting for anyone. This is the only branch that skips governance, so its criteria should be objective enough to apply out of hours, and it should hand straight to your existing incident procedure rather than describing a new one.
Agree the out-of-cycle route, then walk it and publish a version
'Decision needed before the next board?' only works if there is a real out-of-cycle route: a named chair, a response time and a way to record the decision. Test the finished tree against three or four risks from your register, correct the branches that send them somewhere obviously wrong, then publish it as a signed-off version so people know which revision applies.
Frequently asked questions
What is the difference between a risk escalation decision tree and a risk escalation process?
A decision tree answers a routing question — given this risk, which of the available options is correct and who has the right to choose it. Its shape is a chain of tests ending in several different outcomes. An escalation process answers what happens once the route is chosen: who is notified, what pack is prepared, what the receiving body does, how the decision comes back and how it is recorded. Its shape is a chain of steps converging on completion. You need both, and they are easier to maintain as separate diagrams. Use this tree to decide the route, and the incident management process flowchart for the end-to-end flow that follows.
When should a risk be escalated rather than managed locally?
This tree escalates on four independent triggers, any one of which is sufficient. The exposure sits outside the owner's recorded tolerance. The mitigation costs more than the delegated budget or requires a decision beyond the owner's authority. The impact exceeds the agreed financial or schedule threshold. Or the risk carries a safety, legal or regulatory dimension, in which case it leaves the local route regardless of value, because tolerance for that class of exposure is effectively nil. Everything else can be managed locally with monitoring, or accepted and recorded if no mitigation is worth doing.
What is the difference between risk appetite and risk tolerance here?
Appetite is the amount and type of risk the organisation is willing to pursue in the first place; tolerance is the boundary a specific owner may work within before someone else has to be involved. The tree tests tolerance, because that is the operational question a risk owner can actually answer on a Tuesday afternoon. ISO 31000 does not prescribe thresholds for either — it expects the organisation to define its own risk criteria and keep them consistent with its objectives — so the figures on these nodes have to come from your risk management plan rather than from a standard.
What happens if the risk has already occurred?
It stops being a risk. A risk is a possible future event with an owner and a mitigation; once it has materialised, it is an issue and, if harm or breach is imminent, an incident. That is why 'Has the risk already materialised?' is the first question in the tree: a Yes leaves the risk route entirely, triggers the incident procedure and ends at 'Escalate now as an incident' without waiting for a scoring exercise or the next board meeting. PRINCE2 draws the same line, treating a risk that has occurred as an issue rather than continuing to manage it in the risk register.
Does every escalation have to wait for a scheduled board meeting?
No, and the tree makes that an explicit test rather than an improvisation. 'Decision needed before the next board?' takes a risk that is below the impact threshold but time-critical and routes it out of cycle to the risk committee chair, instead of holding it until the cycle catches up. The value of writing the test down is that it also legitimises the other answer: if the decision can genuinely wait, the escalation summary is prepared and the risk goes to the next scheduled board, and nobody has to argue about whether that was reasonable.