Risk Appetite vs Risk Tolerance vs Threshold, Defined
Risk appetite sets how much risk you want; risk tolerance sets the deviation you accept; a threshold turns that into a number that escalates itself.
Three words: appetite, tolerance, threshold. Most risk policies use them interchangeably, which is exactly why escalation triggers on those projects never fire. According to PMI's 2025 Pulse of the Profession, 62 percent of respondents said business acumen, financial and risk literacy included, improves how well a team manages and mitigates project risk. Knowing these three words apart is that literacy, applied to one specific, common gap.
The direct answer: risk appetite is the organization's broad statement of how much risk it wants to carry to reach an objective. Risk tolerance is the operational boundary underneath it, the specific deviation allowed on a given dimension. A risk threshold is that tolerance written as a number a rule can check without a human judgment call. Appetite is intent, tolerance is the boundary, threshold is the number that fires.
Appetite says "we accept meaningful schedule risk on strategic projects." Tolerance says "schedule variance up to 10% is acceptable before it needs review." Threshold says "10%," the exact figure an escalation rule compares against every week. Three layers, each narrower than the last, and a policy that only writes the first layer down produces reviews that never trigger, because nobody wrote the number the second and third layers depend on.
Risk Appetite: The Organization's Intent
Risk appetite is set above any single project, usually by the sponsor, the PMO, or a governance body, and it states the organization's general posture toward risk in pursuit of an objective. "We accept significant technical risk to be first to market" and "we accept almost no risk on anything touching patient safety" are both risk appetite statements: broad, directional, and not something you can check a number against.
Appetite's job is to set the direction the more specific tolerances below it should point. A project team that doesn't know the organization's appetite ends up guessing, and guesses tend to default to whichever is politically safer in the moment, usually more caution than the organization actually wanted, which quietly kills initiatives that were supposed to take the risk in the first place.
Risk Tolerance: The Operational Boundary
Risk tolerance translates appetite into a boundary on a specific dimension: cost, schedule, scope, or quality. Where appetite is a sentence, tolerance is closer to a rule: "schedule variance up to 10% is acceptable without escalation" or "we will absorb up to two weeks of vendor delay before triggering a recovery plan."
The distinction that matters operationally: appetite is aggregate and can't be checked against a single week's data, while tolerance is granular enough to compare against an actual project metric. A PM who only knows the appetite ("we're risk-tolerant on this one") has no way to decide whether this week's schedule slip is fine or a problem. A PM who knows the tolerance ("up to 10% variance") can check the number and know immediately.
Risk Threshold: The Number That Triggers Action
A threshold is a tolerance with the ambiguity removed: the exact figure, in the exact unit, that a person or a system checks without interpretation. "Ten percent" is a threshold. "Significant variance" is not, because two people can disagree about whether 8% counts.
This is the layer most risk policies skip, and it's the one an escalation framework actually depends on. An escalation rule needs something to compare against; "the PM feels this is getting risky" doesn't compile into a rule, and "cost variance exceeds 10% of remaining contingency" does. Every automatic trigger in a PMO, a status flip to red, a mandatory review, a change-control referral, is a threshold doing the work that an appetite statement alone can't.
The diagram below shows the three layers narrowing from a broad statement down to a specific, checkable number.
Risk Appetite vs Risk Tolerance: A Worked Example
Take a single project risk, schedule slip from a vendor integration, and see how it reads at each layer.
| Layer | Statement | Checkable? |
|---|---|---|
| Appetite | "We accept meaningful schedule risk on strategic projects to protect scope." | No; a sentence about intent |
| Tolerance | "Schedule variance up to 10% is acceptable without a formal review." | Partially; still needs a unit and a trigger point |
| Threshold | "If schedule variance exceeds 10% (or the critical path moves more than 3 working days), the issue escalates to the steering committee within 3 calendar days." | Yes; a number, a unit, and a fixed response |
Only the bottom row can be checked by an automated status report or an escalation rule without a human deciding, case by case, whether this week counts. That's the entire value of doing the work to write a threshold: it moves the decision from "does this feel risky" to "does this number exceed that number," which is faster, more consistent, and harder to quietly ignore under deadline pressure.
Why Teams Conflate Them, and What Breaks
Most risk policies stop at appetite, because appetite is the sentence that's easiest to write and get approved: it sounds thoughtful, it doesn't commit anyone to a specific number, and nobody can be wrong about it later. Writing a tolerance means committing to a figure that might turn out to be too loose or too tight, which is a harder conversation to have with a sponsor.
The failure this produces is specific and recurring: a PMO with a well-written appetite statement and poor risk visibility in practice, because visibility mechanisms like variance thresholds need an actual number to trigger against, and appetite alone never supplies one. Teams then fall back to escalating on gut feel, which reintroduces exactly the inconsistency, some PMs escalate at the first sign of trouble, others wait until the date has already slipped, that a written threshold exists to remove.
Turning Appetite Into an Escalation Trigger
The fix is mechanical, not cultural: for each of the two or three dimensions that actually drive decisions on a given project, usually cost, schedule, and scope, write the appetite in one sentence, then force a follow-up conversation that produces a specific number and unit for the tolerance, then write the threshold as a comparison an escalation rule can run without a person in the loop. Skipping straight from appetite to "we'll know it when we see it" is how a well-intentioned risk policy produces zero real escalations in a year.
The project risk management guide covers how these thresholds should calibrate against the risk register itself, and once a risk's cost impact is quantified, expected monetary value gives the tolerance conversation a real number to negotiate around instead of a feeling. Run the free PMO Maturity Assessment to see whether your organization's governance actually operationalizes appetite into checkable thresholds, or stops at the sentence. The rest of the Onplana blog covers the wider PMO governance practice these three layers sit inside.
Run the free PMO Maturity Assessment Twenty questions about how your PMO turns risk policy, governance, and escalation into practices that actually run, not just documents that exist. Get a structured capability profile in about ten minutes. No signup required. → Open the assessment
Frequently asked questions
What is the difference between risk appetite and risk tolerance?
Risk appetite is the organization's stated intent: how much risk it is willing to accept in pursuit of an objective, usually written as a broad statement like 'we accept moderate schedule risk to protect scope on strategic projects.' Risk tolerance is the operational boundary underneath it: the specific, measurable deviation allowed on one dimension, like 'schedule variance up to 10% before a review is triggered.'
What is a risk threshold?
A risk threshold is a risk tolerance expressed as a number that a system, or a person, can check without judgment: a specific percentage, a dollar figure, a number of days. Tolerance sets the boundary in principle; the threshold is the boundary written down as a comparison an escalation rule can run automatically.
Why do teams confuse risk appetite and risk tolerance?
Both describe how much risk is acceptable, and most risk policies never write the two down as separate statements, so they collapse into one vague sentence used for both. The tell is that nobody can point to the number: a real tolerance produces a threshold you can name; a policy with no number is an appetite statement wearing a tolerance's job.
How do you write a risk tolerance statement?
Name the dimension (cost, schedule, scope, quality), the measurable unit (percent, days, dollars), and the specific number that triggers a defined response. 'Cost variance beyond 10% of the approved budget triggers a change control board review' is a tolerance statement with a threshold built in; 'we don't like cost overruns' is not.
Does every risk need its own tolerance and threshold?
No. Set tolerances on the two or three dimensions that actually drive project decisions, usually cost, schedule, and scope, rather than writing one for every line on the risk register. A threshold that never gets checked because nobody remembers it exists is worse than no threshold, because it creates a false sense that the boundary is enforced.
Who sets risk appetite versus risk tolerance?
Risk appetite is set above the project, by the sponsor, PMO, or governance body, because it's a statement about organizational intent. Risk tolerance and its thresholds are usually negotiated between the sponsor and the PM at project start, since they translate that intent into the specific numbers the project will actually operate against.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.