UK Regime and Testing Expectations

Testing expectations under the UK regime centre on whether scenario testing is severe enough, service specific enough, and followed through enough to demonstrate that an important business service would remain within its impact tolerance under severe but plausible disruption. Testing is not expected to be a single exercise, a single method, or a single report. It is expected to be a programme that covers the firm's important business services, uses scenarios drawn from service maps and vulnerabilities, involves the people who would actually respond during disruption, and produces findings with owned actions that are themselves checked. A testing programme that produces reassuring results without ever threatening a tolerance, or that produces findings without closing them, does not meet the expectation, however busy its calendar appears.

The expectation also covers variety of method. Different methods test different things: a walkthrough tests whether procedures and decisions are coherent, a simulation tests whether participants can act under pressure, and a live test of a workaround tests whether the workaround functions at realistic volumes. A programme that relies on only one method will leave some weaknesses unexamined. The choice of method should therefore follow the vulnerability being tested, rather than habit or convenience.

Testing should cover each important business service, with scenarios chosen for that service, rather than generic scenarios applied uniformly across the firm. A scenario for a claims service should reflect claims dependencies, while a scenario for a payment service should reflect payment dependencies, even where both scenarios involve a similar incident type such as supplier failure. Service specific scenarios ensure that testing examines the map and tolerance for the service in question, rather than rehearsing a general incident response that never touches the service details.

Walkthroughs, in which participants talk through a scenario step by step, test whether procedures, roles and decision routes are clear and complete. They are useful for new services, new procedures or complex recovery sequences, because they expose gaps in logic without the pressure of a live exercise. Their limit is that they do not test whether a workaround functions in practice, or whether participants can act under time pressure and incomplete information. A walkthrough that is presented as proof that a workaround works overstates what the method can show.

Testing should be severe enough to threaten the tolerance for the service, because testing that never approaches tolerance provides no evidence about what would happen under severe disruption. Severity should be grounded in plausibility, drawing on the service map, incident history and known vulnerabilities, rather than invented for dramatic effect. A scenario that combines failures, such as loss of a system together with loss of a key supplier step, may be appropriate where the map shows that combination to be plausible and threatening. A scenario that piles unrelated failures onto a service, without regard to plausibility, may produce lessons that do not transfer to real disruption.

Testing evidence should be recorded against the service, with the scenario, the participants, the findings and the actions arising, so that a later reader can see what was tested, what failed, and what changed. Findings should be owned, with a planned action and a means of checking whether the action worked, such as retesting the workaround or revising the procedure and walking it through again. Findings recorded only in a general programme report, without service linkage or ownership, tend to be lost, and the same finding recurs in the next test, which is evidence that follow-up failed.

Common mistakes include testing mild scenarios, testing only technology staff, testing in isolation from suppliers where suppliers are critical, describing a walkthrough as a live test, and recording findings without ownership. Another mistake is to borrow test programmes from another regime without redesigning them for UK services and tolerances, so that the tests answer a different regime question. A further mistake is to treat testing as an annual event rather than a programme that responds to change, incidents and previous findings. Each mistake produces a testing record that looks active while leaving service resilience unproven.

This guide describes UK testing expectations in general educational terms. It does not assess any particular firm's testing programme, and it does not replace FCA and PRA policy statements or supervisory guidance. The guides on scenario testing, mapping, tolerances and self-assessment in this cluster provide the service level detail that a testing programme should be built upon, and the governance guide addresses board oversight of testing.