Setting Impact Tolerances

An impact tolerance is a limit, not an ambition. For one important business service, it states how much disruption can be tolerated before the harm caused by that disruption is judged intolerable, and it states that limit in terms a disruption actually produces: how long the service is unavailable, how broadly users are affected, and what happens to data. A firm that can state those points clearly has a line against which a real incident can be judged. A firm that cannot state them has only a general intention to recover quickly, and that intention gives decision makers nothing firm to act on when pressure rises.

The distinction matters because a tolerance is meant to be tested and, at times, breached in a rehearsal so the firm learns where recovery falls short. If the line is drawn as a hopeful target, a breach reads as a disappointment rather than a signal that harm has reached an intolerable level. The work therefore starts with harm, not with recovery speed. Decision makers ask what users would lose, what obligations would fail, and what confidence would be damaged, and only then express those answers as a limit for the service in question.

Starting with harm changes the questions a firm asks. Instead of asking how fast a system can be restored in ideal conditions, the firm asks what a stop means for the people who rely on the service and for the wider system around it. A retail payment service offers a useful illustration. When that service stops, customers cannot pay for essentials, merchants cannot complete sales, and unsettled payments can accumulate in ways that create confusion long after the service returns. Those effects, rather than the effort of the technology team, define where intolerable harm begins.

A well drawn tolerance names the service, names the users, and describes the disruption in concrete terms. It avoids vague language about severe disruption and instead describes the shape of the event: an interruption of a certain length, affecting a certain breadth of users, with a certain effect on data. The wording does not need to be long. It needs to be specific enough that, during an incident, a manager can compare what is happening with what was written and say whether the limit has been reached, without needing to reinterpret the document under stress.

Testing turns a written limit into evidence. A severe but plausible scenario is rehearsed against the tolerance, and the firm observes whether recovery, workarounds, and communication bring the service back inside the limit before intolerable harm occurs. The rehearsal is not a pass or fail exercise for its own sake. Its value lies in what it reveals: a dependency that was missed, a workaround that depends on a single person, a communication step that arrives too late, or a recovery sequence that works for one channel but not for another.

The most common failure is the one named in the theme of this cluster: a tolerance written as a target the firm hopes to meet rather than a limit beyond which harm is judged intolerable. Under that wording, every breach looks like a near miss, because the firm can describe the outcome as close to the target even when users suffered real harm. The language softens the signal, and softened signals rarely trigger the searching review that a breach should prompt. A second failure is copying a tolerance from a similar service without examining whether the users and timing match. A third is leaving the tolerance unowned, so that no one is responsible for reviewing it when the service changes.

A reader checking a tolerance can start with a small set of questions. Does the tolerance name one service and its users, or does it describe the firm in general? Does it state intolerable harm in duration, breadth, and data terms, or does it state effort and intention? Can a manager during an incident tell from the wording whether the limit has been crossed? Is there a test record for that service that challenged the tolerance, and did the record lead to a change? If any answer is unclear, the unclear point is the work to do next, and it should be owned and dated rather than left as a general improvement theme.