How do you test a business continuity plan?
What testing a business continuity plan actually means, the test types and what each proves, how to write the test plan, and why the same exercise can also answer the testing question on a cyber insurance application.
Testing a business continuity plan means putting a disruption in front of the people named in the plan and making them run it, then writing down what happened. The methods run from a walkthrough through a tabletop to a functional and then a full-scale exercise, in ascending order of cost and realism. Most organizations should run a facilitated tabletop against a severe but plausible scenario, once a year, and keep the report. That is also, not coincidentally, the answer to the testing question on a cyber insurance application.
One scope note before anything else. This page is about testing the plan with people. It is not about IT failover, backup restores or disaster-recovery-as-a-service, which are tests of systems and answer a different question.
What does testing a business continuity plan mean?
It means finding out whether the plan survives contact with a disruption, which is not the same as checking that the plan is written.
The clearest Canadian statement we have read of what a test is for comes from the federal financial regulator. OSFI’s operational resilience guideline says that Business continuity plan tests should provide reasonable assurance that plans are effective, and that tests should consider a range of severe but plausible circumstances, including disruptions that are long in duration, are simultaneous in nature or involve critical third parties (OSFI, Guideline E-21, Operational Risk Management and Resilience, 2024).
That guideline binds federally regulated financial institutions, which most readers of this page are not. Even for the institutions it does bind, OSFI’s published timeline gives until 1 September 2027 to complete scenario testing of all critical operations (OSFI, Operational Risk Management and Resilience, covering letter to Guideline E-21, 2024). It is quoted here because it is the most precise Canadian public statement of the idea we have found, not because it applies to you.
Two phrases in it are worth taking seriously whatever sector you are in. Reasonable assurance sets the bar: a test that could only ever produce a pass is not providing assurance of anything. And severe but plausible rules out both the comfortable scenario and the apocalyptic one. The guideline is explicit that scenario testing should include a range of severe but plausible scenarios, including concurrent scenarios and those of longer duration (OSFI, Guideline E-21, Operational Risk Management and Resilience, 2024).
Long duration is the one to insist on. A four-hour outage is uncomfortable. A four-day outage is a different plan.
What are the test types?
The US government’s Ready.gov guidance for businesses gives a clear public set of definitions.
| Type | What it is | What it costs you |
|---|---|---|
| Walkthrough, workshop or orientation seminar | basic training for team members, designed to familiarise them with the plans and their roles in them | An hour or two |
| Tabletop | discussion-based sessions where team members meet in an informal, classroom setting to discuss their roles during an emergency and their responses to a particular emergency situation | Half a day |
| Functional | personnel validate plans and readiness by performing their duties in a simulated operational environment | A day, plus scheduling around the business |
| Full-scale | as close to the real thing as possible, on location, using the equipment and personnel that would be called on in a real event | Days, and weeks of preparation |
All four definitions are from the same source (Ready.gov, Exercises, business continuity training, 2026). The cost column is our rough guide, not theirs.
A walkthrough is training, on that description, not testing. It is useful and it is where a plan nobody has read should start. It does not put anything under pressure, so it does not tell you whether the plan works.
ISO 22301 is the international standard for business continuity management systems and is worth knowing by name. It sits above all of this as a program framework.
How do you write a BCP test plan?
Borrow the public one. The same US guidance publishes a facilitator handbook and a planner, and between them they describe a complete exercise.
The shape of the session: The entire BCP Test is a recommended three- to four-hour, scenario-driven, facilitated exercise (Ready.gov, Business Continuity Plan Test Facilitator and Evaluator Handbook, 2023), built as registration, an introduction, three scenario modules with a break, and a hot wash at the end.
The purpose, in its own words, is to create an opportunity for businesses to identify and examine the issues and capability gaps they are likely to face in implementing their BCPs and in recovering from business operation disruptions (Ready.gov, Business Continuity Plan Test Exercise Planner Instructions, 2023).
A worked test plan
This is the published planner’s own sequence, with the lead times it gives.
| When | Step | What it means, in our reading |
|---|---|---|
| Three months or more out | Review documents, decide who is coming | Read the plan you are about to test. Decide which roles must be in the room and which may observe |
| Three months out | Logistics | Room, date, and a date the executives will keep |
| Two and a half months out | Staffing and layout, planning meeting | Who facilitates, who evaluates, who plays |
| Two months out | Formal invitation | Sent as a commitment, not an invitation to reply later |
| A month and a half out | Adapt documents | The scenario is rewritten for your operations. A generic scenario produces generic findings |
| One week out | Print documents | Assume the network is the thing that is down |
| The day | Conduct the exercise | Three to four hours, three modules, one hot wash |
| Immediately after | Evaluate | Evaluators consolidate what they recorded while it is fresh |
| 30 days after | After-action report and improvement plan | The deliverable |
Two roles matter more than the rest. Facilitators provide situation updates and moderate discussion. Evaluators are responsible for gathering relevant data arising from facilitated discussions during the exercise and build the report from it (Ready.gov, Business Continuity Plan Test Facilitator and Evaluator Handbook, 2023).
Separating those two jobs is the single most useful thing in the handbook. A facilitator who is also taking the notes will miss many of them, because running the room takes everything.
What the evaluator records is a good specification for any exercise: who made the decision by name or position, what occurred, why it was made, how it was made, and what the outcome was. Findings written to that shape survive being read by somebody who was not there, which is the whole point of writing them.
How often should a plan be tested?
Annually is the working floor. The more defensible answer is OSFI’s, written for federally regulated financial institutions: The frequency and intensity of testing should be proportional to the criticality of and risk to operations, and Where there are significant changes in the risk environment, testing should take place more frequently and outside the regular cycle (OSFI, Guideline E-21, Operational Risk Management and Resilience, 2024).
In practice three things reset the clock early: a new core system, a new site or a major change in where work happens, and a reorganization of who is responsible for what. All three make the last test less informative than its date suggests, because the plan it tested is not the plan you now have.
What does a test produce?
A report, and the report is the part that outlives everyone’s memory of the day.
The published process ends with an after-action report and improvement plan about 30 days after the exercise (Ready.gov, Business Continuity Plan Test Exercise Planner Instructions, 2023). OSFI’s nearest equivalent, written for federally regulated financial institutions and about a real crisis rather than an exercise, is that Lessons-learned exercises should be undertaken following a crisis and incorporated into the plan, and that scenario testing is iterative, with the results of previous tests informing the design of future ones (OSFI, Guideline E-21, Operational Risk Management and Resilience, 2024).
Incorporated into the plan is the clause that matters. A report that does not produce a revised plan has recorded a problem rather than fixed one.
For comparison, we deliver ours in 15 days.
Does a business continuity tabletop count for cyber insurance too?
It can, and there is a public list that shows why.
Indiana’s state cybersecurity hub, a US state site, publishes sample questions it describes as typical for a cybersecurity insurance application. Its response planning category runs to 4 questions (Indiana Cybersecurity Hub, Cyber Insurance Toolkit, underwriting security controls questions, 2026). Three ask whether a document exists: an incident response plan, a data breach response plan, and a disaster recovery and business continuity plan. The fourth is the only one about testing, and it reads Does the Applicant test your Disaster Recovery and Business Continuity Plan annually?
So on this list, a US state’s sample rather than a Canadian carrier’s form, the only annual testing question is hung on the continuity plan rather than the incident response plan.
The Cyber Centre’s baseline controls tie the two plans together from the other side, saying an incident response plan should be part of the organization’s plans for disaster recovery and business continuity (Canadian Centre for Cyber Security, Baseline Cyber Security Controls for Small and Medium Organizations V1.2, 2020).
One session can serve both, and the way to make sure it does is in the scope section rather than in the room. Pick a scenario that runs past the technical response into the operating question, which for most organizations means a ransomware or major outage scenario carried far enough that the room has to decide how it works without its systems. Then record, against each finding, which plan it belongs to.
Do that and one exercise produces evidence for both plans. Do it loosely and it produces a report that is not quite about either.
Questions
Is a backup restore a business continuity plan test?
It is a test of the backup. It tells you the data comes back and how long it takes, which is worth knowing and is not the same question. A business continuity plan test asks whether the people would make the right calls while the restore is running: who declares the disruption, who tells customers, who decides which operations come back first.
How often should a business continuity plan be tested?
Once a year is the practical floor. The better answer is that frequency should follow how critical the operation is and how much has changed. A new site, a new core system or a reorganization of who does what all make the last test less reliable than its date suggests.
Can the same exercise cover business continuity and incident response?
Yes, if the scenario is chosen for it. A ransomware scenario that runs long enough to reach the question of how you operate without systems tests both plans in one session. Say so in the scope section of the report, and record which plan each finding belongs to, or the report evidences neither cleanly.
Do we need ISO 22301 to do this properly?
No. ISO 22301 is the international standard for business continuity management systems and it is a reasonable framework if you are building a formal program, usually because a customer or a regulator asked. Testing a plan with the people in it does not require the standard, and no cyber insurance application we have read mentions it.