Risk tolerance is the acceptable variation around the level of risk an organization has said it wants to carry. Appetite is the target. Tolerance is how far from it the organization will drift before someone has to act.
Appetite is what the organization wants to accept.
Tolerance is the range around that it will live with.
Capacity is the maximum it could absorb before serious harm, whether it wants to or not.
Most statements conflate the first two, which produces a target with no defined edges. Nobody can then say whether a given reading requires action, and the discussion defaults to whoever argues most persuasively in the room.
Tolerance should be a range in the units of a metric, not an adjective.
“Low tolerance for unpatched internet-facing systems” cannot be tested. “No internet-facing system carrying a known exploited vulnerability for more than seven days, with a review triggered at five” can be.
That translation is most of the work in connecting governance language to operational measurement, and it is usually left undone.
An organization can hold a wide tolerance for one exposure and almost none for another, and should.
Tolerance for disruption in an internal reporting system is not tolerance for disruption in customer payments. A single organization-wide tolerance statement forces both into the same band and gets one of them wrong.
Set tolerance per risk in the register, tied to the appetite statement it derives from.
Stated tolerance and revealed tolerance diverge. An organization that routinely accepts exceptions beyond its written range has a revealed tolerance wider than its stated one.
Tracking exceptions granted against each tolerance band makes that divergence visible. It is often the most uncomfortable metric in a governance pack, and the most useful.
From the blog