Scenario-Based Testing

Scenario-based testing rehearses a severe but plausible disruption against a critical function, from the first failure to the recovery of the service. Unlike a scan, which searches for a known flaw, a scenario asks what happens when several things go wrong together: a key system fails, a supplier is unavailable, and customers begin to contact the firm at the same time. The exercise tests technology, but it also tests decisions. Who declares the incident, who speaks to customers, who decides to switch to a workaround, and who owns the recovery sequence. Under DORA, scenario testing is a central method for checking whether a firm could keep a critical function going, or restore it, under stress that resembles reality.

A good scenario starts from the function, not from a generic disaster. For a custody and settlement service, a relevant scenario might combine the loss of a primary processing platform with the unavailability of a settlement counterpart's interface, during a period of high transaction volumes. The scenario should be severe enough to strain the plan, but plausible enough that the lessons transfer to real incidents. A scenario so extreme that staff dismiss it teaches little. A scenario so mild that existing procedures handle it without thought teaches even less. The choice should be documented, with the reasons it was judged severe and plausible for that particular service.

During the exercise, participants work through the disruption in sequence, using the plans, contacts, and systems they would use in reality, as far as safety allows. Injects arrive over time: a backup restores incomplete data, a supplier gives an uncertain recovery estimate, a news report raises customer anxiety. Observers record decisions, delays, and moments of confusion, rather than only whether the service eventually recovered. The most valuable record is often the point at which the plan ran out. A plan that assumes a single failure, a single decision maker, and a single supplier response will reveal its limits quickly when a scenario removes each of those assumptions in turn.

Technology failures are only part of a disruption. In many incidents, the service is lost not because recovery was impossible, but because nobody decided, or because two teams decided differently. Scenario testing exposes that. It shows whether escalation routes work when the usual manager is unavailable, whether customer communications are ready or must be drafted from scratch, and whether a decision to invoke a workaround has a named owner. An exercise in which participants simply read out a plan, without making choices under time pressure and incomplete information, is a briefing, not a test. The difference matters, because real disruptions do not pause for a briefing.

The laboratory pitfall appears here as a scripted exercise in which everyone knows the outcome in advance, the supplier always recovers, and no customer is affected. Such an exercise reassures without informing. Realism can be increased safely: withhold some information from participants, include a supplier who cannot give a firm recovery time, and introduce a second failure after the first recovery begins. The aim is not to embarrass participants. It is to find the gaps while they can still be fixed calmly. A scenario that finds nothing, in a complex service with several dependencies, should prompt a review of the scenario, not a celebration of the result.

After the exercise, findings should be sorted into what worked, what failed, and what was never tested because the plan did not cover it. Each failure needs an owner and a change: a revised procedure, a new contact route, a different recovery sequence, or further testing of a specific system. The next scenario should then check whether that change worked, rather than starting from scratch with an unrelated disruption. Over successive exercises, a firm builds a record of its own weaknesses and its own improvements. That record, more than any single exercise, is the evidence that scenario testing is strengthening the critical function.