Impact Tolerances Have Teeth Now: Evidencing You Can Stay Within Them

The transitional period ended on 31 March 2025. From that date the question a UK supervisor asks is no longer “have you set impact tolerances” but “show me you can stay inside them” — and a policy document that asserts you can proves nothing.

The FCA’s operational resilience rules came into force on 31 March 2022. They gave firms a three-year window to do the substantive work: identify important business services, set an impact tolerance for each, map the resources that deliver them, and test whether the service can be kept within tolerance under disruption. That window closed on 31 March 2025. Firms in scope of SYSC 15A, and their PRA-regulated counterparts under SS1/21, must now be able to remain within their impact tolerances for each important business service. The obligation shifted from planning to demonstrable capability, and that shift changes what the technology function has to build.

A tolerance is a number, not a paragraph

An impact tolerance is the maximum tolerable disruption to an important business service before it causes intolerable harm to consumers or the wider market. Expressed properly it is a measurable quantity: a service is unavailable for no longer than N hours, or degrades below a stated throughput for no longer than a stated period. The moment a tolerance is written as a number with a unit, it becomes something you can test a system against. The moment it is written as “we aim to restore service promptly”, it becomes something you can only argue about.

That distinction is the whole game. A recovery time objective the infrastructure team happens to hold in a runbook is not an impact tolerance, and the two frequently disagree. The tolerance is set from the outside in — the point at which harm becomes intolerable — and the technology has to be shown to meet it, not the other way round. Where the RTO the platform can actually achieve is longer than the tolerance the harm analysis demands, you have a vulnerability, and the regime expects you to have found it and to be remediating it. This is the same discipline I have written about in the context of operational resilience testing and impact tolerances: the tolerance is the assertion, and the test is what makes it true or false.

Severe but plausible, and the temptation to test soft

The rules require testing against severe-but-plausible scenarios. “Severe” is the load-bearing word and it is where firms cheat themselves without meaning to. A scenario that assumes a single availability zone fails while the failover works exactly as designed is neither severe nor a test — it is a rehearsal of the happy path. Severe means the primary data centre and the documented failover degrade together; means the third party that hosts your core ledger is unreachable for most of a working day; means the incident starts at the worst possible hour and the person who knows the recovery procedure is unreachable.

The FCA has already been explicit on this. In its observations after the deadline it flagged firms that assert they can recover from any disruption while not being able to show that sufficiently severe scenarios were actually tested. Reporting few or no outstanding vulnerabilities alongside thin testing evidence does not read as strength; it reads as a firm that has not looked hard enough. A harness that only ever produces green is not evidence of resilience — it is evidence that the scenarios are too kind.

The build task: a scenario that fails loudly

Treat the scenario as code. A severe-but-plausible disruption is a declarative object: the service under test, the tolerance expressed as a time, the disruption injected, and — the part firms skip — an explicit assertion that the measured recovery came in under the tolerance. If it did not, the run fails, and the failure is the finding you are obliged to act on. Written this way, the scenario is version-controlled, re-runnable after every material change, and produces a timestamped record without anyone writing prose. Here is the shape of one.

# scenario: primary + documented failover degrade together
# important business service: retail payment initiation
# impact tolerance: service unavailable no longer than 4 hours

service: retail-payment-initiation
impact_tolerance_minutes: 240        # set from harm analysis, not from the RTO

disruption:
  type: dependency_outage
  inject:
    - target: primary-ledger-db      # primary fails
      mode: unreachable
    - target: failover-ledger-db      # and failover degrades, not clean cutover
      mode: latency
      added_ms: 8000
  start_at: "02:00"                   # worst hour, on-call handover
  duration_minutes: 300

measure:
  signal: service_available           # end-to-end, customer-observable
  from: disruption.start

assert:
  # the run FAILS if recovery did not beat the tolerance
  - metric: minutes_to_recovery
    op: less_than
    value: 240
  - metric: data_loss_transactions
    op: equals
    value: 0

evidence:
  record: [start_ts, recovery_ts, minutes_to_recovery, assertions_passed]
  retain_months: 36                   # keep for the supervisory horizon

The specifics belong to your estate, but the structure is the point. The tolerance is stated as a number the harm analysis produced. The disruption degrades the failover rather than assuming a clean cutover. The assertion is written so a slow recovery turns the run red. And the run emits an evidence record on its own, because the artefact a supervisor asks for is not the intention to test — it is the dated result of having tested.

What the year of evidence has to show

The self-assessment document remains the centre of gravity. Under SYSC 15A it has to be approved by the governing body and kept current, and through 2026 it needs to carry a year of operating history, not a snapshot. That means each important business service with its tolerance and the rationale for it; the scenarios run, including the ones that failed; the recovery times measured against tolerance; the vulnerabilities those runs exposed; and for each vulnerability an owner, an action and a target date. The FCA has singled out unclear remediation ownership — findings with no owner and no completion date — as a recurring weakness. A vulnerability you recorded but did not assign is worse than one you missed, because it shows you saw the risk and left it.

Firms that also operate under the PRA carry the same logic through SS1/21 and what the technology function must be able to show, and anyone running a group across jurisdictions will recognise the pattern from Australia’s CPS 230 critical operations and tolerance levels: the regulator does not want the assertion, it wants the test that stands behind it.

Build the harness so that its default output is proof. A board attestation that the firm stays within tolerance is a sentence anyone can write. A scenario that goes red when the recovery is too slow is the only version of that sentence a supervisor will believe.