Severe but Plausible Scenarios Explained

A severe but plausible scenario is a demanding disruption that a firm can reasonably imagine happening, used to test whether an important service can still recover within its tolerance. Severe means the scenario genuinely stresses the service, rather than rehearsing an easy failure. Plausible means it stays within the bounds of what could happen, rather than imagining a catastrophe so extreme that no plan could answer it.

A card payment service at a peak shopping period, hit by a settlement partner outage while its own backup channel is also degraded, is an example of the kind of compound difficulty such scenarios explore. The point is not to predict that exact combination, but to learn whether the service, its people, and its suppliers can still restore payments in the right order when more than one thing goes wrong.

A mild scenario flatters a firm. It tests the plan against a failure the firm already handles well, and it leaves the harder questions unasked, such as what happens when the usual workaround is unavailable, when key people are absent, or when users flood the remaining channel. A severe scenario forces those questions into the open while there is still time to act on the answers.

Severity also reveals hidden dependencies. A scenario that removes a supplier, a data feed, and a communication channel together may show that the recovery plan assumed all three would survive, even though they share an underlying provider or location. That discovery is valuable precisely because it is uncomfortable.

Plausibility keeps testing honest and useful. A scenario so extreme that it assumes every control fails at once, and every supplier fails with it, may produce a dramatic exercise but little learning, because the firm concludes that nothing could have helped. A plausible scenario, by contrast, leaves room for decisions that matter: which users to prioritise, which channel to switch to, and which recovery step to attempt first.

Plausibility is a judgement, not a statistical claim, and it should be argued from the service context: its dependencies, its peak periods, its supplier concentration, and its history of near misses. A scenario that cannot be argued for in those terms is unlikely to teach the service owner anything transferable.

Building a scenario starts from the service map, not from a generic disaster list. The firm looks at what the service depends on, which of those dependencies are fragile or concentrated, and what combination of failures would stress the service most, then shapes a narrative around that combination with a clear timeline of decisions.

The narrative should include the user experience as it unfolds, not only the technical failure. When do users first notice, what do they try next, what does the firm tell them, and at what point does harm approach the tolerance? A scenario that never mentions users is a systems exercise wearing a resilience label.

Results should be judged against the service tolerance and should produce owned changes, such as a revised recovery order, a new alternative channel, a clarified decision maker, or a supplier arrangement that removes a single point of failure. A scenario that ends with a general sense of reassurance, but no named change, has probably been too easy or too vague.

Results should also be kept with the service record, so that the next test builds on the last one rather than starting afresh. Over time, a series of scenarios should show a service becoming harder to break in the places that matter most to users, even if new weaknesses continue to appear as the service changes.

Ask, for one service, whether its scenarios are both severe and plausible in the senses described here, and whether they follow from its own map and dependencies. Then ask what changed after the last scenario, and who owns that change.

This guide is educational and does not prescribe scenarios for any firm. Its purpose is to help a reader recognise a scenario that genuinely tests a service, as distinct from one that merely exercises a plan.