# Testing your business continuity plan

Pick scenarios from your impact analysis, run tabletop or failover tests against recovery objectives, act on findings, for ISO 27001, SOC 2 and DORA.

Source: https://sted.digital/docs/guides/business-continuity-testing · Last reviewed 17 October 2026 · Strand Guides

A useful continuity test proves you can recover your critical activities within the times you promised, and changes the plan where you can't. Pick scenarios from your business impact analysis, choose a tabletop or a live test, set recovery objectives before you start, run it with a scribe, record what happened against the plan, and fix what failed.

## When you need this

ISO 27001:2022 Annex A 5.29 asks you to keep information secure during a disruption, and Annex A 5.30 asks for ICT readiness that is planned, implemented, maintained and tested against your continuity objectives. SOC 2 A1.2 covers the recovery infrastructure and A1.3 asks you to test the recovery plan procedures. EU DORA Article 11 requires an ICT business continuity policy and plans, and EU DORA Article 11(6) requires them to be tested at least yearly and after substantive changes to critical systems; DORA has applied to EU financial entities, such as banks, payment firms, investment firms and insurers, since 17 January 2025.

The triggers are the annual cycle, a SOC 2 report period, a new critical system or supplier, and an incident that became a continuity event. An IT or continuity lead runs it.

This is guidance to help you understand the requirement, not legal advice.

## Before you start

You need the business impact analysis with a recovery time objective (RTO) and recovery point objective (RPO) for each critical activity, the continuity and recovery plans, the contact list, and the risk register. For a live test, agree a rollback plan and a change window. Tell your critical suppliers if the test involves them, and decide in advance who can stop a live test that starts to harm service.

A tabletop takes a day to prepare and an hour or two to run. A technical restore or failover test takes one to three days of engineering time, including the write-up.

## Steps

1. Pick one or two scenarios from the business impact analysis and the risk register, aimed at your most critical activities. Done when each scenario names the activities and systems it disrupts.
2. Choose the exercise type: tabletop, walkthrough, simulation or full failover. Done when the type matches what you need to prove.
3. Set the objectives and measures before the test, such as the RTO, the RPO and the time to tell customers. Done when each objective has a pass or fail threshold.
4. Plan the logistics: participants, a facilitator, a scribe, the date, and a rollback plan for live tests. For a SOC 2 Type II report, schedule the test inside the report period. Done when every participant has the date and role.
5. Run the exercise and log every decision and action with its time. Done when the log covers the whole exercise.
6. Record the result against the plan: actual recovery times, data lost, steps that failed and evidence such as logs and screenshots. Done when each objective shows pass or fail.

Records follow templates with sections and, where useful, structured fields you can report on.
Records are part of the Full Management System plan.
Records take file attachments, scanned for malware before download.

7. Agree the findings and an action for each, with an owner and a due date. Done when no finding is without an action or a recorded decision to accept it.
8. Update the continuity plan, the recovery plan and the contact list, and have them re-approved. Done when the plans reflect the findings.
9. Report the result to management and schedule the next test. Done when the next date is set and the report is filed.

## Choosing the exercise type

Each type proves something different. Start with tabletops if your plan is new, and add technical tests for the systems with the tightest objectives.

| Type | What happens | Effort | What it proves |
|---|---|---|---|
| Tabletop | People talk through a scenario around a table | Half a day | Roles, decisions and communication |
| Walkthrough | Each team steps through its part of the plan | One day | The plan's steps are complete and current |
| Simulation | Parts of the recovery run for real in a test environment | One to three days | Recovery steps work and how long they take |
| Full failover | Production moves to the standby site or region | One to three days, planned window | Objectives can be met for real |

## Running a tabletop in a small firm

A one-hour tabletop needs a facilitator who knows the scenario, a scribe, and the people who would act on the day: a director, the IT lead, someone who talks to customers and someone from finance. Keep the scenario secret until the start.

Use three injects, each a new fact that forces a decision. At 10 minutes, the trigger: staff cannot open files. At 25 minutes, the escalation: a demand arrives, or the restore is slower than planned. At 40 minutes, the side effect: a large customer calls, or a key person is unreachable. Spend the last 15 minutes on what went well, what did not and who will fix it.

The usual failures are a scenario so gentle nobody is stretched, answers read from the plan rather than decided, and a debrief with no owners. If the plan says call the IT supplier, ask for the number, and see whether anyone has it without email.

## Worked examples

### ISO 27001, a tabletop of a ransomware day

Moorcroft Accountants, 20 staff, sets an RTO of 8 hours for its practice management system and runs a tabletop on 11 March 2026 under Annex A 5.30. The injects: at 08:30 files on the server are encrypted; at 10:00 a ransom note threatens to publish client data; at 12:00 the IT supplier reports that restoring from the off-site backup (ISO 27001:2022 Annex A 8.13) will take 11 hours, because of download speed. The team estimates recovery at 13 hours against the 8-hour objective, and finds that the contact list exists only in email, which is down.

Two actions: a local immutable backup copy to cut restore time, owner IT lead, by 30 April; a printed and phone-held contact list, owner office manager, by 31 March. A simulation on 10 June restores the system in 6.5 hours, inside the objective, and the plan is updated.

### SOC 2, a quarterly database failover

Tessellate, a SaaS firm, has a Type II period from 1 January to 30 June 2026 and promises an RTO of 1 hour and an RPO of 5 minutes. On 18 February the team promotes the standby database in a second zone (the redundancy that ISO 27001:2022 Annex A 8.14 and SOC 2 A1.2 describe): 42 minutes, 2 minutes of data lost. On 20 May the same test takes 71 minutes, because cached DNS records kept clients pointed at the old database. The finding is logged, DNS lifetimes are cut, and a retest on 3 June takes 38 minutes. The auditor samples all three tests under A1.3, with the runbook, timestamps and sign-offs as evidence.

### DORA, yearly testing as a legal duty

EU DORA Article 11(6) follows the ISO 27001 example as a yearly legal duty for firms in scope, and firms other than microenterprises must include cyber-attack and switchover scenarios. EU DORA Article 25 adds a wider programme of resilience tests, scenario-based tests among them.

## Checklist

- [ ] Each scenario comes from the business impact analysis or the risk register.
- [ ] Recovery objectives were set before the test.
- [ ] The exercise type matches what the test had to prove.
- [ ] A scribe logged decisions and times throughout.
- [ ] Actual results are recorded against each objective.
- [ ] Evidence such as logs and screenshots is attached.
- [ ] Every finding has an action with an owner and a due date.
- [ ] The plans and contact list were updated and re-approved.
- [ ] Critical systems had a technical recovery test this cycle.
- [ ] The next test is scheduled.

## How Sted helps

Sted's knowledge base carries the Business Continuity and Disaster Recovery Policy (POL-BCP) with six record templates, the Business Impact Analysis (REC-BIA), Business Continuity Plan (REC-BCP), Disaster Recovery Plan (REC-DRP), BC/DR Communication Plan (REC-BCC), BC/DR Test Record (REC-BCDRT), which comes with a suggested quarterly frequency, and BC / DR Review Record (REC-BCDRR).
Records are part of the Full Management System plan.
33 periodic record types come with a suggested frequency, but nothing is scheduled until you pick a first due date.

Sted does not run the exercise or the recovery for you. It holds the plans and the dated record of each test you run.

## Related standards

- [ISO 27001 Annex A organisational controls](/docs/standards/iso-27001/annex-a-organisational-controls): ICT readiness for continuity under control 5.30.
- [SOC 2 availability](/docs/standards/soc-2/availability): the recovery test A1.3 asks for.
- [SOC 2 Type I and Type II](/docs/standards/soc-2/type-1-vs-type-2): why the test must fall inside the report period.
- [Backup and restore testing](/docs/guides/backup-and-restore-testing): the restore tests behind your recovery point.
- [Incident response and breach notification](/docs/guides/incident-response-and-breach-notification): when an incident becomes a continuity event.
- [Records](/docs/product/records): where test records and their evidence live in Sted.

## Frequently asked questions

Q: What scenarios should a business continuity test cover?
A: The disruptions most likely to stop your critical activities: ransomware, the loss of a key cloud service or supplier, losing your office, and losing key people. Pick one or two a year from your business impact analysis and risk register, and rotate them so every critical activity is tested over a few years.

Q: How often should we test our business continuity plan?
A: At least once a year, and after any major change to the systems or people the plan relies on. EU DORA Article 11(6) makes yearly testing a legal duty for financial entities in scope, and a SOC 2 Type II report needs a test inside the report period.

Q: What is the difference between a business continuity test and a disaster recovery test?
A: A business continuity test checks that the business can keep its critical activities going, including people, premises, suppliers and communication. A disaster recovery test checks that specific systems and data can be restored within their recovery objectives. Most organisations need both.

Q: Does a tabletop exercise count as a test?
A: Yes, for checking that the plan, roles and decisions work. It does not prove that systems can be restored in time, so auditors also expect at least one technical recovery test a year for your critical systems.