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.
What the risk escalation decision tree process is
Escalation goes wrong in two directions. Risks that should have gone up sit in a register for a month because nobody felt entitled to raise them, and risks that could have been handled by the owner arrive at a board meeting because raising them felt safer than deciding. Both failures come from the same gap: the criteria exist in people's heads rather than on a page. A risk escalation decision tree closes that gap by making each test explicit and answerable from evidence, so the same risk gets the same route regardless of who is holding it.
This page is a decision tree, not a process map. It answers which option is correct and who holds the decision right, so the questions run down the middle and the branches end in different places. A process map answers what happens next and who does it, so its steps run left to right and converge on one completion. If you want the end-to-end flow that follows an escalation once it has been raised, use the incident management process flowchart at /templates/incident-management-process, which covers logging, prioritisation, major incident declaration, SLA breach and closure. This chart stops at the routing decision; that one picks up after it.
The template uses light swimlanes that name who answers each question rather than mapping departments: Risk owner, Project manager, Project board and Executive risk committee, across five stages from Capture to Escalation route. Eight decisions sit on the spine, and criteria are written into comments on the four that carry real thresholds: the safety, legal or regulatory screen, the tolerance test, the budget-and-authority test and the impact threshold. Five named endpoints replace the single happy path a process map would use.
What this flowchart covers
In this template
- Four decision-rights lanes rather than a department map (Risk owner, Project manager, Project board, Executive risk committee) laid across five stages: Capture, Screening, Tolerance test, Threshold and timing, Escalation route.
- Two screening questions that bypass scoring entirely: 'Has the risk already materialised?' and 'Safety, legal or regulatory exposure?'. A Yes on either can reach 'Is harm or breach imminent?', whose Yes runs 'Trigger the incident procedure' and terminates at 'Escalate now as an incident'.
- The local branch: 'Within the owner's risk tolerance?' leads to 'Is active mitigation worthwhile?', where No ends at 'Accept and record the risk' and Yes runs 'Mitigation within budget and authority?': Within ends at 'Manage locally with monitoring', Beyond sends the risk up even though the exposure was tolerable.
- The routing split on 'Impact above the escalation threshold?': Above goes straight to 'Brief the risk committee chair', Below drops to the timing test rather than escalating on value alone.
- The timing test that separates the two escalation routes: 'Decision needed before the next board?' sends Yes out of cycle to the committee chair, and No through 'Prepare the escalation summary' to 'Escalate to the project board'.
- Five distinct endpoints instead of one funnel: manage locally with monitoring, accept and record, escalate to the project board, escalate to the executive risk committee, and escalate now as an incident.
When to use this template
- Writing the escalation section of a risk management plan, where the criteria have to be stated rather than implied.
- Onboarding new project or risk managers so escalation is driven by written tests rather than individual temperament.
- Settling an argument about decision rights: the lanes say who answers each question, which is usually the real dispute.
- Providing assurance or audit evidence that escalation criteria exist, are agreed and were applied to a specific risk.
- Running a post-incident review where a risk was escalated too late, tracing which test should have fired and did not.
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.