Scenario testing puts an important business service through a severe but plausible disruption to find out whether the firm stays inside its impact tolerance. "Severe but plausible" is the load-bearing phrase: severe enough to stress the service properly, plausible enough that the firm cannot dismiss the result — typically something that has happened somewhere in the sector, or that follows credibly from your own mapped dependencies. An untested impact tolerance is a hypothesis; the test is what turns it into evidence, and a failed test with a dated remediation plan is a stronger position than an untested pass.
Why testing is the point
The UK operational resilience framework doesn't ask you to prevent every disruption — it accepts that disruption will happen and asks whether you can stay within your impact tolerances when it does. That question can only be answered by testing. Naming your important business services and setting tolerances is the setup; scenario testing is where you find out whether any of it holds.
What "severe but plausible" means
The standard sits deliberately between a routine blip and the end of the world: severe enough to genuinely strain the service, plausible enough for the result to count as evidence. Severe but plausible means a disruption serious enough to threaten the tolerance, realistic enough that it could actually occur to your firm: a major cloud outage, the failure of a key third party, a ransomware event, the loss of a critical site or team.
Good scenarios are chosen to threaten a specific tolerance. If a service has a four-hour tolerance, design the scenario that would put four hours at risk — then find out whether your people, processes and third parties actually keep you inside it.
Running the test
- Pick the service and the scenario — one important business service, one severe-but-plausible disruption aimed at its tolerance.
- Trace the mapping — walk the disruption through the systems, people and third parties the service depends on, using your resilience mapping.
- Measure against the tolerance — how long would the service actually be disrupted, and does that exceed the maximum you've said is tolerable?
- Capture what broke — the dependencies, hand-offs and assumptions that failed under pressure.
Turning results into remediation
A test that stays within tolerance is reassurance; a test that breaches it is the more valuable outcome, because it names a vulnerability while it's still cheap to fix. The findings feed your self-assessment: here is where we'd breach, here is why, and here is the remediation plan and timeline. Regulators are less interested in a firm that claims flawless resilience than in one that can show it tests honestly and fixes what it finds.
Evidence you can defend
The credibility of a test rests on whether the breach determination is objective. An incident either ran past the affected service's tolerance or it didn't — and that is read from the timeline. Qgentic OpRes takes the incident timestamps from a test (or a real event), computes whether each affected service's tolerance was breached, and records it in a tamper-evident trail — so your evidence of testing is a calculation. See it run in the live demo.
Qgentic OpRes turns each test's incident timeline into a computed breach determination you can defend.
See the OpRes platform Book a consultation