15 Business Continuity Test Scenarios (Plus a Sample Test Report Template)

Every company with a business continuity plan believes it works. Very few have watched it work. The gap between those two states is testing — and it's exactly the gap auditors, customers, and real incidents will find for you if you don't find it first.

If you're still at the "what even goes in a BCP" stage, start with our guide to business continuity plans and the companion piece on practical BCP exercises for SMBs, which explains the exercise formats — tabletop, walkthrough, simulation, parallel test, full interruption — in detail. This post assumes you know the formats and answers the harder question: what exactly should you test? Below are 15 scenarios worth running, grouped by the kind of failure they exercise, plus the test report template that turns each run into audit evidence.

Why frameworks care about testing, not just plans

Continuity testing isn't a nice-to-have layered on top of compliance — it's written into the requirements:

• ISO 27001:2022 — Annex A control A.5.29 requires you to plan how information security is maintained during disruption, and A.5.30 (ICT readiness for business continuity, one of the controls newly introduced in the 2022 revision) requires ICT readiness to be planned, implemented, maintained and tested. An untested continuity capability is a direct gap against the control's own wording. The full Annex A guide covers where these sit in the 2022 structure.
• ISO 22301 (the dedicated business continuity standard) requires an exercise programme — exercising and testing at planned intervals, not a one-off.
• SOC 2 — if the Availability category is in scope, the criteria expect recovery plan procedures to be tested; auditors will sample your review period and ask for the test report. Even Security-only reports touch this through incident response and recovery expectations.

In every case the auditor's question is the same: show me the record of the last test. Which is why every scenario below ends in a report, not just a warm feeling.

Technology failure scenarios

1. Your primary cloud region goes down. The classic. Walk through (or actually execute) failover for your main product: what breaks, what degrades, what the customer sees, and who declares the incident. Pass criteria: recovery within your stated RTO, and nobody had to look up how DNS failover works mid-exercise.

2. Restore production from backup. The single most valuable test on this list, and the one to run for real rather than around a table. Take a recent backup, restore it to an isolated environment, and verify the data is complete and usable. Pass criteria: restore completes within RTO, data loss is within RPO, and the restored system actually starts. A backup that has never been restored is a rumor.

3. Ransomware hits your infrastructure. Tabletop it: laptops and possibly servers are encrypted, attackers demand payment. Exercise the decision chain (who decides whether to engage counsel, insurers, law enforcement), the isolation steps, and recovery from offline or immutable backups. Pass criteria: a decision path exists, backups are genuinely isolated from the blast radius, and legal/notification duties were considered.

4. A critical SaaS vendor is down for 24 hours. Pick the tool that would hurt most — your identity provider, your payment platform, your hosting for status pages. Walk through the degraded-mode plan: what work continues, what waits, what you tell customers. Pass criteria: a documented workaround per critical vendor, and contract/SLA terms you've actually read.

5. Someone deletes production data by accident. Not an attack — a fat-fingered migration or a dropped table. Exercise detection (how long until you notice?), point-in-time recovery, and customer communication if data was lost. Pass criteria: recovery point is acceptable, and the exercise usually surfaces missing guardrails worth fixing anyway.

6. A critical credential or certificate expires. TLS certificate, signing key, cloud API credential — pick one and simulate its expiry or revocation. Who gets alerted, how fast can it be rotated, and does anything else break during rotation? Pass criteria: monitoring catches it before customers do, and rotation is documented rather than tribal knowledge.

People scenarios

7. Your key person is unreachable. The bus-factor test. Choose the one engineer or founder who "knows everything" and declare them unavailable for two weeks, starting mid-incident. Can the rest of the team deploy, access production, pay the bills, and talk to the bank? Pass criteria: no single-person dependency blocks a critical process — or at minimum, each one found is logged as a finding.

8. Half the team is out at once. Illness wave, a conference, a public holiday chain. Exercise minimum staffing: which processes must continue daily, and can the people remaining actually run them? Pass criteria: a documented list of critical processes with at least two people able to execute each.

9. The on-call engineer doesn't respond. Page the primary at an agreed test time and have them deliberately not answer. Does escalation fire? Does the secondary have the access and context to act alone? Pass criteria: escalation works end-to-end without anyone manually chasing people in private chats.

Facilities and environment scenarios

10. The office is inaccessible. Fire, flood, or just a burst pipe. For remote-first teams this is mercifully boring — which is worth proving, because "we're remote anyway" often hides a dependency like the one physical server, the safe with backup codes, or the registered-mail address. Pass criteria: a full working day proceeds with zero access to the site.

11. Extended power or internet outage at your main location. Different from #10: people are fine, infrastructure isn't. Exercise hotspot fallbacks, secondary workspaces, and what happens to anything hosted locally. Pass criteria: critical staff are productive within an hour through documented alternatives.

12. A severe weather event disrupts a region your team or infrastructure sits in. Heatwave-driven power cuts, flooding, storms — pick what's plausible for your geography. This is also where climate change enters your ISMS: since the February 2024 amendment, ISO 27001 Clause 4.1 expects you to determine whether climate change is a relevant issue — we covered the amendment in detail here. Pass criteria: the scenario connects to real risk-register entries, not generic hand-waving.

Third-party scenarios

13. Your payment provider fails during peak. Revenue stops mid-flow. Walk through customer-facing messaging, retry behavior, reconciliation once service resumes, and whether a secondary provider is realistic for your volume. Pass criteria: you know your hourly cost of payment downtime and the decision threshold for switching.

14. A critical vendor shuts down for good. Not an outage — bankruptcy or acquisition-and-sunset, with 30 days' notice if you're lucky. Exercise data export, migration targets, and contractual exit terms for your top three vendors. Pass criteria: for each critical vendor, you can name where your data would go and roughly how long migration takes.

Communications scenarios

15. Your primary communication channel is down during an incident. Slack or Teams is unavailable exactly when you need to coordinate. Where does the team assemble? Does everyone know without being told — including whoever joined last month? Pass criteria: a documented out-of-band channel (and current phone numbers) that people actually found within 15 minutes.

How to run these without burning out the team

You don't run all 15 a quarter. A defensible cadence for a small company: one real technical test (scenario 2 — backup restore — is the non-negotiable) and two or three tabletops per year, rotating categories so that over a couple of years you've touched technology, people, facilities, vendors, and communications at least once. Most tabletop scenarios here fit in 60–90 minutes with the right five people in the room. What matters to an auditor is planned intervals and records — not heroics.

The sample test report template

Every exercise ends with a one-to-two-page report. This is the artifact that satisfies A.5.30's "tested", ISO 22301's exercise records, and a SOC 2 auditor's sample request — and it's genuinely useful to you six months later. Copy this structure:

• Test ID and date — e.g. BCP-2026-03; date and duration of the exercise.
• Scenario tested — one paragraph: which scenario, what was simulated, what was real.
• Format — tabletop / walkthrough / simulation / live technical test.
• Scope — systems, processes, and locations covered; anything explicitly out of scope.
• Participants — names and roles, including who facilitated and who observed.
• Objectives and pass criteria — what "success" was defined as before the test started.
• Targets vs. actuals — RTO target vs. time actually taken; RPO target vs. data loss actually measured (for technical tests).
• Timeline of events — timestamped log of the exercise: injects, decisions, actions.
• What worked — capture the positives; they're evidence the plan functions.
• Findings and gaps — every surprise, missing document, unreachable person, or wrong assumption. A test with zero findings usually means the test was too soft.
• Corrective actions — each finding gets an owner and a due date. This is the line auditors follow up on: findings without actions are a worse look than no test at all.
• Sign-off — who reviewed the report (management review input, ideally) and the planned date of the next test.

Store the reports somewhere they'll be found at audit time, and feed the corrective actions into whatever tracker you already use — they're indistinguishable from any other compliance task at that point.

The bottom line

A continuity plan earns its name the first time it survives contact with a scenario. Pick one item from this list — backup restore, if you've never done it — schedule 90 minutes, and write the report. Then put the next test on the calendar before the glow fades. If you want to see how testing fits into the wider audit picture, the ISO 27001 internal audit guide shows how your own auditor should be checking this, and the exercise-formats guide helps you pick the right depth for each scenario.