“Severe but plausible” is one of the most widely accepted phrases in operational resilience. It appears sensible, responsible and even reassuring.

And yet, in practice, it often does the opposite of what scenario testing is meant to do.  Not because the phrasing is wrong, but because of how it’s interpreted.

Where “Severe but Plausible” Breaks Down

It’s worth being precise about what regulation actually says here. The PRA and FCA do not require firms to conduct “severe but plausible scenario testing” as a defined activity. They require firms to remain within impact tolerances in the event of severe but plausible disruption.

The issue this creates in practice is not regulatory intent, but translation. Firms still need a way to build confidence that those outcomes can be met, and scenario testing is one of the primary mechanisms they rely on. It is in that translation – from outcome-based requirement to testing design – that assumptions about severity often become fixed far too early.

In many organizations, “severe but plausible” is treated as a scenario category, rather than a testing discipline.

The typical sequence will often look like this: plausibility is assessed upfront, severity is assumed based on the scenario description, a scenario is designed that sounds bad, it is labeled as “severe”, and controls are tested to see if they cope.  The organisation has already decided how bad the outcome will be before it has seen how the system behaves. This sequencing seems backwards.

The Core Error

The mistake is subtle but fundamental.  Plausibility is a property of conditions. Severity is a property of system response.

In operational resilience, severity is not defined by how dramatic the initiating event appears. It is defined by whether impact tolerance is breached.  That outcome cannot be assumed at design time. It only becomes visible when plausible conditions are stressed – when underlying assumptions are tested, interaction effects observed, and margins allowed to erode, stretch, or collapse.

Severity does not exist at design time. It emerges.

Prioritization Without Pre-Declaring Severity

There is, of course, a pragmatic tension here. Organizations cannot test everything deeply, and they should not try to. Prioritization is unavoidable. But prioritization does not require severity to be pre-declared. What it requires is a way of deciding where learning is most likely to occur.

Rather than asking “how bad do we think this will be?”, a more useful starting question is “where might this system behave in ways we don’t fully understand?” Early testing can be broad and relatively shallow, with depth increasing where friction, confusion, or disproportionate response begins to appear.

In other words, follow the gradient of surprise, not the label of severity.

This is not an argument for avoiding severe scenarios or softening stress. It is an argument for allowing severity to reveal itself through disciplined stress, rather than assuming we already know its shape.

A Simple Example

Consider a scenario that might initially appear “moderate”, for example the loss of a key third-party for 24 hours. On paper, this looks plausible, but not obviously severe.

Run properly, however, something very different often appears. Manual queues grow rapidly, approval bottlenecks surface, downstream cut-offs are missed and confidence begins to erode.  The outcome becomes severe – not because it was labelled that way, but because plausibility was stressed hard enough to reveal how the service actually behaves.

Had it been pre-classified as “moderate,” it likely would not have been exercised seriously at all.

A Real World Example

Covid is often cited as evidence that organizations must begin scenario design by assuming severity.

Yet the pandemic itself did not predetermine outcome severity. In some services, tolerances were breached quickly. In others, disruption was absorbed. The difference lay not in the scale of the event, but in how systems were structured – workforce concentration, geographic clustering, third-party interdependence, and assumptions about physical co-location.

Had plausible constraints such as sustained workforce unavailability, simultaneous supplier disruption, and operational restriction been stressed independently of a pandemic narrative, much of what Covid revealed would already have been visible.

The initiating event was global. The severity of outcome depended on system response.

The Hidden Danger of Pre-Labeling Severity

When teams decide severity in advance, they tend to constrain scenario scope, soften assumptions, avoid uncomfortable combinations, and design tests that are meant to pass.  This is how “severe but plausible” quietly becomes challenging but survivable by design, which is the opposite of what resilience testing is for.

What Actually Gets Lost

When organizations say “we know our biggest outages”, “we know our worst historical incidents”, or “we know what regulators expect us to test”, they are anchoring severity to the past, to compliance, or to familiarity.

Often unintentionally, they also fix three things in advance:

• the type of stress (usually technology failure, cyber, or site loss)
• the interaction pattern (single cause leading to linear impact)
• the failure mode (things stop working rather than degrading, stretching, or distorting).

Once these are fixed, everything else is excluded.

The Cost of “Known Severe Scenarios”

When severity is pre-declared, organizations become very good at surviving the failures they already expect. Controls are optimized against known patterns, and confidence is built around familiar shapes of failure.

In doing so, slow erosion, coordination collapse, cumulative load, and second-order effects are systematically missed.  Some of the most severe outcomes are not obviously catastrophic at the start. They emerge from ordinary conditions interacting in untested ways.

A More Honest Framing

This is not an argument against regulatory language, but for a more accurate interpretation of it.   Treat plausibility as the design constraint. Do not assume severity. Stress plausible conditions until the system reveals where it loses margin.

In meaningful scenario testing, plausibility is the input. Severity is the outcome.

What “Severe but Plausible” Was Trying to Prevent

It is also worth acknowledging what the phrase “severe but plausible” was originally trying to prevent. It was never meant to encourage organizations to predefine their worst cases. It was meant to stop testing from drifting into either the trivial or the fantastical.

Interpreted this way, plausibility constrains the design space. Severity is not assumed – it is revealed when plausible conditions are stressed far enough to expose where the service loses margin.

The Question That Actually Matters

The real question is not whether severe scenarios have been tested.

It is: what kinds of severity are we structurally unable to see?

Because the moment we say we already know our severe scenarios, we have constrained what testing is allowed to teach us. And that is where surprise is born.

###

This article is republished with permission by FragilityByDesign.com