FCA and PRA Impact Tolerances in the UK

Under the UK regime, an impact tolerance states the maximum tolerable level of disruption to an important business service, beyond which harm to users or risk to market integrity would become intolerable. The tolerance is set for each named service, in terms that reflect how disruption is experienced, such as the duration of unavailability, the extent of users affected, or the integrity of data on which users rely. It is a statement about intolerable harm, not a target for normal performance, and it is not a promise that disruption will stay within the limit in every conceivable event. Its purpose is to give the firm, its board and its supervisors a clear line against which testing and recovery can be judged.

That distinction between tolerance and target matters in practice. A service may normally perform far better than its tolerance, and a breach of tolerance during a severe disruption is a serious matter precisely because the tolerance was set by reference to harm, not by reference to what systems usually achieve. If a tolerance is set simply by copying current performance, it describes capability rather than harm, and it will rarely be breached even when users suffer. A tolerance set honestly may be uncomfortable, because it exposes how much disruption the firm could not absorb without intolerable harm.

Starting from harm forces a conversation that a purely technical measure avoids. The firm has to ask which users would be harmed, in what way, and at what point that harm becomes intolerable rather than merely inconvenient. A short outage of a service used to check a balance may cause frustration, while a short outage of a service used to make a time critical payment may cause a missed obligation. Duration alone therefore does not capture harm, and a tolerance expressed only in duration may miss the dimension that matters most for a particular service. Extent, data integrity and the availability of workarounds all shape the harm picture.

A tolerance may be expressed through duration, through the proportion or number of users affected, through the volume of transactions affected, or through data integrity, depending on what captures harm for that service. For some services, duration dominates, because users need the service at a particular moment. For others, the number of users affected matters more, because a partial outage that affects a vulnerable group may cause intolerable harm even while most users remain unaffected. For services where accuracy matters, a tolerance may need to address incorrect or corrupted outputs, since a service that runs but produces wrong results may harm users more than a service that stops cleanly.

Setting a tolerance involves judgement informed by knowledge of users, past incidents, complaint patterns and the practical consequences of disruption. The board, or a body with equivalent authority, is expected to own the tolerance, because the tolerance embodies a judgement about harm that the firm is willing to treat as intolerable. That ownership cannot be delegated away to a programme team without board challenge, since the tolerance will later be used to judge whether the firm remained within its own stated limits during severe disruption.

A common mistake is to set a tolerance by reference to a service level agreement or a supplier commitment. Such documents may describe normal performance or commercial remedies, but they do not necessarily describe intolerable harm, and a supplier commitment does not bind the experience of the firm's users. Another mistake is to set a single tolerance for a bundle of services, so that a severe failure in one service is masked by continued performance in others. A further mistake is to set a tolerance so loosely that testing never approaches it, which produces reassuring test results without evidence that the service could survive a genuinely severe scenario.

A tolerance gains meaning only when it is tested. Scenario testing, covered in a separate guide, plays severe but plausible disruptions against the tolerance and records whether the service would remain within it, where recovery would stall, and what would need to change for the service to do better. Where testing shows that the service would breach tolerance, the self-assessment records that finding and the action planned to address it. A tolerance that is never tested is an assertion, and an assertion that is never challenged by a severe scenario is unlikely to survive a real disruption.