FCA and PRA Scenario Testing in the UK

Under the UK regime, scenario testing means rehearsing a severe but plausible disruption against an important business service and judging whether the service would remain within its impact tolerance. The scenario is chosen to stress the service, not to confirm that normal operations work well. It might involve loss of a key system, corruption of data, failure of a supplier, unavailability of specialist staff, or a combination of failures that together create a harder test than any single failure alone. The firm observes where recovery stalls, which workarounds function under pressure, and whether communications to users can be maintained while the service itself is disrupted.

Testing of this kind is distinct from routine system testing. Routine testing often checks whether a component behaves as designed under expected conditions. Scenario testing checks whether a whole service, with its people, processes, technology and third parties, can survive conditions that are severe enough to matter. A scenario that is too mild will produce reassurance without evidence. A scenario that is implausible will produce lessons that do not transfer to real disruption. The skill lies in choosing scenarios that are demanding, credible and tied to the vulnerabilities shown on the service map.

Severe means the scenario is serious enough to threaten the tolerance for the service. If the scenario leaves the service comfortably within tolerance without any strain, it has not tested the boundary the regime cares about. Plausible means the scenario could credibly occur, given the service, its dependencies and its operating environment. A scenario need not have happened before to be plausible, but it should be grounded in known failure modes, supplier risks, incident history in the sector, or vulnerabilities visible on the map. The combination matters: severity without plausibility wastes effort on fantasy, while plausibility without severity wastes effort on routine.

A good scenario starts from the service map and the tolerance. The designer asks which dependency, if lost or corrupted, would most threaten the tolerance, and builds the scenario around that dependency. For a pension payment service, that might be corruption of payment data shortly before a payment run. For a customer access service, it might be failure of an authentication supplier during a period of high demand. Starting from the map ensures the scenario tests a real vulnerability, rather than a generic incident type chosen for convenience.

During the test, participants work through the disruption as if it were real, following recovery procedures, invoking workarounds, escalating decisions and communicating with users and, where relevant, suppliers. Observers record where procedures were unclear, where a workaround could not handle realistic volumes, where a decision stalled for lack of authority or information, and where the map proved inaccurate. Those observations are the output of the test, and they matter more than whether the fictional service was recovered, because recovery in an exercise can be assisted by knowledge that would not be available during a real incident.

After testing, findings should be recorded against the service, not merely in a general programme report. Each finding needs an owner and a planned action, whether that action is to fix a procedure, to build or test a workaround, to change a dependency, or to revise the tolerance or the map in light of what was learned. Findings that are recorded without ownership tend to recur in the next test, which is itself evidence that learning has not taken place. A self-assessment that claims progress without showing how past test findings were closed is therefore open to challenge.

One recurring mistake is to test the scenario that the firm already knows it can pass, rather than the scenario that threatens the service. Another is to run a tabletop discussion and describe it as a full test of recovery, when no workaround was actually operated and no volume was actually handled. A further mistake is to test in isolation from suppliers, even where a supplier provides a critical step, so that the most fragile link in the chain is never exercised. Each mistake produces a test record that looks complete while leaving the service untested where it matters.

Copying scenarios from another regime is a related error. A scenario designed for a different framework may test different concepts, different entities or different obligations, and may not address the UK question of whether a named service remains within its tolerance. Scenarios should be designed for the UK service, its map and its tolerance, even where general incident types, such as cyber attack or supplier failure, are familiar across regimes. Familiarity of incident type does not make a scenario transferable without redesign for the service in question.