Bank of England Stress Testing Your Technology Resilience: A Reading for Boards

“A tolerance statement that has not been tested is not evidence of resilience. It is a documented aspiration.” That distinction, now being drawn explicitly by supervisors, is the whole story of where operational resilience regulation has moved since the March 2025 transition deadline passed.

UK operational resilience policy from the FCA, PRA, and Bank of England came fully into force in March 2025, requiring firms to set impact tolerances — the maximum disruption a firm can withstand for each important business service — and demonstrate they can remain within them during severe but plausible scenarios. That deadline marked the end of the build phase. What’s happening now is active supervisory examination of whether the evidence behind those tolerances actually holds up, and the standard being applied is considerably higher than most boards initially assumed.

Who this is for

• The board member at a UK-regulated financial firm reviewing whether the firm’s impact tolerances have actually been tested, or just documented.
• The CTO preparing scenario testing evidence for supervisory examination.

The tests behind the policy, briefly

Beyond firm-level scenario testing, the Bank of England runs sector-wide exercises that inform its own systemic view. SIMEX, a sector simulation exercise, brings together around 40 of the most systemically important firms and financial market infrastructures to work through a realistic, complex scenario collectively. CORST — the Cyber and Operational Resilience Stress Test, formerly the Cyber Stress Test — is the Financial Policy Committee’s sponsored test of how severe operational disruption might affect UK financial stability. Both run periodically and their thematic findings, along with CBEST assessment outcomes shared in coordination with the National Cyber Security Centre, are meant to inform how individual firms calibrate their own scenario testing. A firm’s testing programme should demonstrably reflect these thematic findings, not run in isolation from what the sector-wide exercises have already surfaced.

What the evidencing standard actually requires

PRA Supervisory Statement SS1/21, Chapter 7, sets out a specific evidencing standard for scenario testing: the scenario rationale, the methodology, the test execution record, the findings in full, the impact tolerance outcome — met or not met, per important business service — the lessons learned, and remediation actions with named owners and completion dates. A written description of the testing process, however substantive the underlying exercise, doesn’t meet this standard without the complete evidence trail behind it. Supervisors are explicitly distinguishing between firms with the most extensive documentation libraries and firms whose evidence is current, tested, and traceable — the first doesn’t automatically produce the second.

Testing is about recovery, not prevention

SS1/21 Chapter 6 is explicit on a point worth internalising directly: impact tolerance testing assumes a disruption has already occurred, so the testing itself should not focus on preventing incidents from happening. The question being tested is whether the firm can recover and restore the important business service within its stated tolerance once disruption is underway — a different exercise from the security control testing most technology functions are more practised at. A scenario test that spends most of its effort validating preventative controls, rather than genuinely exercising the recovery path under pressure, is testing the wrong thing relative to what SS1/21 asks for.

The calibration problem most firms actually have

A specific, recurring failure pattern in scenario design: scenarios calibrated either too mild to be genuinely useful, or so extreme they’re no longer plausible for the specific firm. “Severe but plausible” is a standard that has to be set against the firm’s own actual risk profile and operating model, not against a generic worst-case template borrowed from an industry framework. SS1/21 itself points to a workable source of realistic scenarios — previous incidents or near misses within the organisation, across the financial sector, and in other sectors and jurisdictions — rather than requiring firms to invent hypothetical scenarios from scratch.

The shorter tolerance often does the real work

SS1/21’s own worked example is worth internalising directly: a firm might judge that six hours of disruption to a service creates consumer harm risk through an inability to settle transactions, while eight hours creates a separate reputational risk threatening safety and soundness. Investing to meet the shorter, six-hour tolerance automatically satisfies the longer one — which means the practical investment decision should be driven by identifying the shortest genuinely binding tolerance across a service’s full impact profile, not by picking a single headline tolerance figure and testing against that alone.

ERM and BCM tools solve a different problem than SS1/21 evidencing

Enterprise risk management and business continuity platforms are built around risks and controls; FCA and PRA operational resilience evidencing is built around services and tolerances. An ERM system can describe what risks affect operations — it generally cannot produce, on demand, which specific important business services are currently breaching their impact tolerances, or the service-centred evidence trail a supervisor actually expects. Firms relying on a general-purpose ERM or BCM platform to produce SS1/21-grade evidence are frequently discovering the gap only when a supervisory review asks for something the platform was never built to generate.

What a board should be able to see

1. Confirmation that every impact tolerance has been tested, not just documented — with the full SS1/21 Chapter 7 evidence trail behind each test.
2. Scenario tests genuinely exercising the recovery path, not primarily re-validating preventative controls.
3. Scenarios calibrated against the firm’s own actual incidents and near misses, checked for genuine plausibility rather than generic severity.
4. The shortest binding tolerance identified per important business service, with investment prioritised against it specifically.
5. Confirmation that the evidence platform in use is built for service-and-tolerance evidencing, not adapted from a generic ERM or BCM tool.

How we engage with this

We read scenario testing programmes against SS1/21’s specific evidencing standard — not a general resilience maturity assessment — as a Technology Control Review. The output is a written assessment identifying where documented tolerances haven’t actually been tested to the standard supervisors now expect.

We don’t run scenario tests ourselves. We don’t sell operational resilience software. We don’t represent firms to the PRA or FCA. We read what’s there, identify what’s missing, and write it down for the people who have to decide what to do about it.

Pricing is published at /pricing/. If your impact tolerances haven’t been tested to SS1/21’s specific evidencing standard, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.