Operational resilience scenario testing, timed from evidence

Operational resilience scenario testing is how a bank checks whether each important business service can recover within its impact tolerance when something severe but plausible goes wrong: a supplier hit by ransomware, a site lost, data corrupted, a key system down. Under the FCA's SYSC 15A and the PRA's SS1/21, a bank must keep a testing plan, run the tests, learn from them and fix what fails, and the results go into the self-assessment its board approves. The weakness of many programmes is not the choice of scenario but the timing: recovery durations agreed in a workshop look identical, on paper, to durations measured in a failover test. Botminds' Operational Resilience Management is an agentic solution in which a Scenario agent times each recovery step from a test report, an incident timeline, a runbook or a contract clause, cites the source, and labels any step without recent evidence as an estimate; an analyst runs the test and a different person signs it.

The worked example is one test at the solution's fictional sample bank, Corvane Bank UK: ransomware at the supplier running its primary Faster Payments gateway. The rules and regulators' findings are quoted and linked.

What is operational resilience scenario testing?

It is testing whether a service stays within its tolerance once a disruption has happened, not whether the disruption can be prevented. The FCA's rule: "A firm must carry out scenario testing, to assess its ability to remain within its impact tolerance for each of its important business services in the event of a severe but plausible disruption of its operations" (SYSC 15A.5.3R). The PRA makes the focus explicit: tolerances "assume a disruption has occurred, and so testing the ability to remain within impact tolerances should not focus on preventing incidents from occurring. The PRA expects firms to focus on recovery and response arrangements" (SS1/21, 6.1).

A test therefore has three parts: a scenario, a service map to run it on, and a clock. The map says which people, processes, technology, facilities, information and suppliers the scenario takes out; the clock says how long each recovery step takes and where the tolerance falls. The firm must also keep "a testing plan that appropriately details how it will gain assurance that it can remain within the impact tolerances", run tests after material changes and after fixes, and "in any event, on a regular basis" (SYSC 15A.5.1R and 15A.5.7R).

What are severe but plausible scenarios?

They are disruptions bad enough to stress a service to its limit but realistic enough to happen, chosen across "an appropriate range of adverse circumstances of varying nature, severity and duration relevant to its business and risk profile" (SYSC 15A.5.4R). The FCA lists five a firm should consider: "corruption, deletion or manipulation of data critical to the delivery of its important business services"; "unavailability of facilities or key people"; "unavailability of third party services, which are critical to the delivery of its important business services"; "disruption to other market participants, where applicable"; and "loss or reduced provision of technology underpinning the delivery of important business services" (SYSC 15A.5.6G).

Severity can be raised two ways, the PRA says: "increasing the number or type of resources unavailable for delivering the important business service, or extending the period for which a particular resource is unavailable" (SS1/21, 6.9), and good sources are "previous incidents or near misses within the organisation, across the financial sector, and in other sectors and jurisdictions" (6.2). There is a ceiling: the PRA does not expect firms to stay within tolerance "in circumstances which are beyond severe or implausible", such as a loss of power, transport or telecommunications (6.10). The sample bank's library has eight scenario types: the FCA's five, plus ransomware, a shared supplier failing, and payday and month-end peaks.

Industry groups also work on shared approaches. The Cross Market Operational Resilience Group, which the FCA describes as "co-chaired by the Bank of England and UK Finance, with FCA as a member", produces guidance "created by industry participants" (FCA, operational resilience). Any shared scenario is a useful starting point; it still has to be run on the bank's own map and timed with the bank's own evidence.

What is the difference between a tabletop and a test?

A tabletop is a discussion of what people would do; a test produces measured times. Both are allowed: the FCA's guidance on testing plans names "the type of scenario testing undertaken. For example, whether it is paper based, simulations or through the use of live-systems" (SYSC 15A.5.2G). But the FCA has asked firms to move on. In 2024 it said "Scenario testing should be evolving from judgment, desk-based scenario tests, to a wider range of testing that provides empirical data", including "disaster recovery/fail over tests", simulations and "lessons learned from real scenarios" (FCA, May 2024).

Live testing carries a risk of its own, which is one reason firms rely on desk-based work. The PRA says scenario testing "should not pose a material risk of creating a disruption", and firms choosing live-systems tests should assess that risk (SS1/21, 6.7). The practical answer is to time scenarios from the evidence the bank already generates, failover tests, exercises and real incidents, and run new live tests where a step has none.

How do you time recovery in a scenario test?

Break the recovery into the steps that happen in sequence, find the most recent evidence for the duration of each, and add them up against the tolerance. The figure at the top shows the result for the sample scenario. Payments stop routing and the queue alert fires after 18 minutes, as in the February 2026 incident; the major incident is declared 34 minutes later, matching that incident and the supplier's 30-minute notice clause; the decision to fail over takes 43 minutes, as timed at the March 2026 crisis exercise; and the three steps of the failover itself come from the May 2026 failover test.

A severe but plausible scenario run step by step on the service map

The sum matters less than its shape. Three steps from one failover test account for 4 h 35 m of the 6 h 10 m, and the test's own lessons say why: the alternate gateway holds no live certificates, so keys are exchanged by hand. A scenario timed this way does not just say "outside tolerance"; it says which step to fix.

What evidence should a scenario test use, and how old can it be?

The best evidence is a measured duration for the same step on the same system: a failover test, a recovery exercise, or a real incident's timeline. Below that come runbooks timed in exercises, and contract clauses that fix a supplier's notice or recovery time. A workshop estimate is the weakest evidence, and should say so. The FCA's 2026 review of self-assessments praised "Clear documentation of methodology, assumptions, and rationale for scenario selection and recovery times" and self-assessments that state how confident the firm is in each test result (FCA, March 2026; what agents do, and never sign quotes that line).

The rules set no maximum age for test evidence, but they tie testing to change: a firm must re-test after a material change and after improvements (SYSC 15A.5.7R), and the PRA expects testing frequency to reflect whether "the operational resources supporting an important business service have materially changed" (SS1/21, 6.6). An age limit turns that into a rule a system can apply. The sample bank's is 12 months: a step whose newest evidence is older, or which has none, is labelled an estimate with a confidence below 0.80, so the board sees the proven minutes and the guessed ones separately.

Every recovery step with its source and confidence

How many scenarios should be tested each year?

Enough to cover every important business service across a range of scenario types, with more for services that change often or sit close to their tolerance; the rules set no number. The PRA expects that "firms that have identified more important business services should undertake more scenario testing" and that firms changing their operations more often should test more often (SS1/21, 6.6). The FCA expects testing plans to "incrementally increase the severity of disruption" until the firm finds "the severity at which you're no longer able to remain within impact tolerance" (FCA, May 2024).

The sample bank's 2026 plan has 22 scenarios across 11 services, covering data, facility, technology and third-party types; on October 22, 18 were signed and 4 scheduled between November 3 and December 9, with one service still untested. Two results were outside tolerance, and both went onto the remediation plan.

The year's scenario test plan, with every result against its tolerance

What happens when a scenario shows a breach?

The breach becomes a vulnerability with a fix, an owner, a date and funding, and the fix is proven by re-running the same scenario. The PRA wants breaches found: firms "should test a range of scenarios, including those in which they anticipate exceeding their impact tolerance", and the board must decide whether each such breach is acceptable (SS1/21, 6.12). The FCA expects remediation plans to be approved, funded and governed, and closed only when a repeated test proves the fix (FCA, May 2024; what agents do, and never sign quotes the passage), and the rule requires a re-test "following improvements made by the firm in response to a previous test" (SYSC 15A.5.7R).

For the gateway breach, the head of operational resilience signed the result as checker, since the analyst who ran it could not. Three fixes were re-tested on the same clock: a warm standby gateway with keys pre-exchanged and hosting away from the shared cloud (3 h 5 m, inside by 55 minutes), a faster recovery commitment from the supplier (still outside by 45 minutes), and a priority queue for time-critical payments as an interim. The SMF24 accepted the first, with a live failover re-test booked for March 2027. Who signs each step and why the backup was not independent follow the same breach from other angles.

Testing scenarios that run through a supplier

Supplier steps need supplier evidence, and the bank remains answerable for it. The FCA expects a firm relying on a third party "to work with the third party to ensure the validity of the firm's scenario testing", and where the supplier tests its own services, to "ensure the suitability of the methodologies, scenarios and considerations adopted" (SYSC 15A.5.5G). In 2024 it added that firms need to be satisfied that a third party's "methodology and tested scenarios are appropriate and sufficient for your requirements" (FCA, May 2024).

The sample scenario used two kinds of supplier evidence: a contract clause that fixed the supplier's notice time, and a joint failover test with the alternate gateway. When the agents found that both gateways host in one cloud region, a new scenario, an outage of that region, was proposed for December 2 and sent for checking like any other change to the plan. The Basel Committee's principle is the same in fewer words: banks should test "their ability to deliver critical operations through disruption" under "a range of severe but plausible scenarios" (BCBS, Principles for operational resilience, 2021). To see a scenario timed on your own evidence, start from Operational Resilience Management.

Questions people ask

What is a severe but plausible scenario example for a bank?

Ransomware at the supplier that runs a payments gateway; the loss of an operations centre; corruption of a payments file; a cloud region outage affecting several suppliers at once. SYSC 15A.5.6G lists five types to consider, and the PRA suggests drawing on past incidents and near misses across the sector.

Is a tabletop exercise enough for operational resilience testing?

It is allowed, but the FCA has asked firms to move beyond "judgment, desk-based scenario tests" to testing that provides empirical data. A tabletop is useful for decisions and communications; recovery times should come from failover tests, simulations or real incidents wherever they exist.

How often must operational resilience scenario testing be done?

On a regular basis, after any material change to the business, services or tolerances, and after improvements made in response to a previous test (SYSC 15A.5.7R). The PRA expects more frequent testing for firms whose operations change often.

Who should sign off a scenario test result?

Someone other than the person who ran it, usually the head of operational resilience, with the results reported to the board through the self-assessment. In the sample bank, the analyst is the maker and the head the checker for every result.

What is the difference between scenario testing and stress testing?

Financial stress testing measures capital or liquidity under adverse economic conditions. Operational resilience scenario testing assumes an operational disruption has happened and measures whether a service recovers within its impact tolerance, focused on recovery and response, as the PRA's SS1/21 puts it.