Designing Severe but Plausible Scenarios

A severe but plausible scenario describes a disruption that would breach the tolerance of one named service, through a chain of causes that readers who know the service find credible. Severity without plausibility produces a story that participants dismiss, while plausibility without severity produces a rehearsal of an ordinary bad day. The design test is therefore practical: would the people who run the service recognise the causes, the dependencies and the customer harm, and would the disruption force them to make choices they would rather avoid? If the answer to either part is no, the scenario needs revision before it is rehearsed. Regime labels matter here too, since DORA and the UK regime describe testing expectations in their own terms, and this guide keeps those labels separate.

Difficulty alone does not make a scenario severe. A busy period, a single system fault that is quickly worked around, or a supplier delay that customers barely notice may be worth managing, but none of them tests the point at which harm becomes intolerable. Severity appears when the service cannot meet its tolerance, when a workaround runs out, or when harm spreads to customers who cannot easily wait or find an alternative. Consider a mortgage servicing operation that cannot process payments or answer urgent borrower queries. Severity grows as the backlog grows, as vulnerable customers are affected, and as staff must choose between competing urgent tasks. The scenario writer should name that harm plainly, so participants cannot soften it during the exercise.

Plausibility is judged against the service as it actually operates, not against general news about technology risk. The writer starts with the service map: channels, systems, data stores, people and third parties that the service depends on. A cause is plausible when it connects to one of those dependencies through a credible mechanism, such as a supplier outage, a corrupted data feed, a failed change, or a malicious attack on a known weakness. Past incidents, internal near misses, supplier disclosures and industry lessons can all inform that judgement, provided they are adapted to this service rather than copied wholesale. A scenario that requires several independent failures at once needs a reason why those failures would coincide, such as a shared dependency or a common change, otherwise participants will rightly treat it as contrived.

Good material usually already exists inside the firm, scattered across incident records, risk discussions, supplier reports and audit findings. The writer gathers those fragments and turns them into a coherent story with a beginning, a complication and a decision point. External sources can broaden the picture, including guidance from ENISA on incident practice and standards material from NIST, but those sources describe patterns, not this service. The writer must therefore translate a pattern into local detail: which system, which supplier, which customer group, and which manual workaround. Detail is what makes a scenario believable. A story that names a real channel, a real dependency and a real constraint will hold attention in a way that a generic story about disruption never will.

A finished scenario contains more than a narrative. It states the service, the tolerance at stake, the trigger and the way the disruption unfolds, the information participants will and will not have at each stage, and the decisions the exercise is meant to force. It also states what is out of scope, so participants do not waste the session debating an unrelated crisis. The facilitator notes should identify the intended pressure points, such as a missing contact, a conflicting instruction, or a choice between speed and accuracy. Those notes are not a script for success. They are a reminder of where the exercise should become difficult, so that difficulty is not smoothed away when participants struggle.

Before a scenario is used, someone who did not write it should challenge it. That reviewer can ask whether the harm is severe enough, whether the causes are credible, whether any assumption quietly rescues the firm, and whether the scenario still fits a service that may have changed since the last review. Assumptions deserve special attention. A scenario that assumes a backup works, a supplier answers, or a manual process scales may be testing optimism rather than resilience. Where an assumption is genuinely uncertain, the exercise can test both branches: what happens if the assumption holds, and what happens if it fails. A scenario that survives that kind of challenge will feel harder to write, and will teach more when it is rehearsed.