Scenario Testing and Exercises

A scenario is a story about a disruption that is severe but plausible for one particular service, and an exercise is the rehearsal of that story. The story on its own changes nothing. Its value lies in the decisions it forces during the rehearsal: who acts, in what order, with what information, and what changes afterwards. A useful exercise therefore ends with a short list of named changes, each with an owner, rather than a general feeling that the team coped well. Where a regime is mentioned in this guide, it is labelled, so expectations under DORA in the EU and expectations under FCA and PRA policy in the UK are not merged into a single rule.

A useful scenario is anchored in a named service and in the harm that service would cause if it stopped. Consider a retail payments service that customers rely on to pay for everyday purchases. A vague story about systems going down tells the team very little. A specific story about the payment channel failing while a settlement partner is also unavailable forces choices about queuing payments, telling customers what is happening, and deciding which payments are handled first when service returns. Severity is judged by effect on the service, not by drama in the story. Plausibility is judged by whether the chain of causes could credibly happen for that service, given its dependencies, rather than by whether it has happened before in exactly that form.

An exercise tests decision making under incomplete information, not technical knowledge in the abstract. Participants need to show that they can find the right information, recognise when a decision belongs to someone else, and record what was decided and why. A tabletop discussion tests judgement and communication. A live exercise tests whether systems, people and workarounds behave as the plan assumes. In both forms, the weakest point is often not a missing tool but a missing handover: the person who knows the workaround is absent, the contact list is out of date, or two teams each assume the other will tell customers. Exercises that surface those gaps in a rehearsal room are doing their job, even if the session feels uncomfortable.

Scenario testing gains meaning when it is tied to the tolerance set for the service. Tolerance describes the point beyond which disruption becomes intolerable for customers or for the wider market, in terms a disruption itself would produce. A scenario that stays comfortably inside tolerance may still be worth rehearsing, but it does not test the hardest choices. A scenario that breaches tolerance tests whether recovery is sequenced sensibly, whether the most harmful effects are reduced first, and whether the firm knows when it can say service has returned. Recovery is not simply restarting systems. It includes checking data, restoring customer access in a controlled way, and watching for problems that only appear once normal volumes return.

The central pitfall in this cluster is an exercise designed to succeed, so everyone leaves reassured and nothing changes. That outcome can arise innocently. A facilitator may soften an inject when participants struggle, a scenario may assume that a key supplier responds promptly, or success may be defined as finishing on schedule rather than as learning something. Reassurance then becomes the product, and the plan keeps its flaws. A healthier test is one where difficulty is expected and where a poor result is treated as useful evidence. If an exercise ends with no change to a plan, a contact, a workaround or a decision rule, the firm should ask whether the scenario was hard enough, whether participants were free to disagree, and whether observers were asked to look for failure.

The guides that follow this pillar each take one part of the work and examine it in detail. Some deal with designing scenarios for particular causes, such as cyber outages, supplier failure and data loss. Others deal with forms of exercise, from tabletops to live rehearsals, and with exercises for the board and for incident teams. Later guides deal with learning, with keeping a library of scenarios current, and with risks that are only emerging. A reader who works through the cluster in that order will see the same discipline repeated: name the service, make the story specific, rehearse the decisions, and record the changes. The discipline matters more than any single scenario, because services, suppliers and threats keep changing while the need to decide under pressure remains.