How to Test a Business Continuity Plan Properly

Most organisations have some kind of business continuity plan. Far fewer have tested it in a way that would reveal whether it actually works. Plans are written, approved, filed and then discovered, during a real disruption, to contain out-of-date contact details, assumptions nobody checked and steps that depend on systems that are themselves down.

Testing is what turns a plan into a capability. This guide explains the main types of test, how to design them so they are useful rather than theatrical, and how to make sure lessons lead to change.

Why testing matters

A test does three things a document cannot:

• It finds errors. Wrong phone numbers, missing steps, unrealistic recovery times and hidden dependencies.
• It builds familiarity. People who have rehearsed their role respond faster and more calmly under pressure.
• It tests decisions, not just procedures. Real disruptions require judgement: what to prioritise, what to tell customers, when to escalate. Exercises let leaders practise those decisions.

The main types of test

Organisations usually build up from simpler to more demanding tests.

Plan review

A structured read-through of the plan by the people named in it. Do they know their role? Are the contacts current? Do the steps make sense? This is quick and finds many basic errors, but it does not test how people respond under pressure.

Walkthrough

A guided discussion of the plan, step by step, against a simple scenario. Participants talk through what they would do and identify gaps. Useful for new plans or new team members.

Tabletop exercise

A facilitated scenario played out around a table, or on a video call, with information released in stages. Participants make decisions as the situation develops. Tabletop exercises are the workhorse of continuity testing: they are cheap, flexible and very good at revealing problems with decisions, communication and coordination.

Functional test

A test of a specific capability in practice: restoring a system from backup, switching to an alternative site, activating a call cascade, running a process manually. These verify that the technical and practical steps actually work.

Full simulation

A larger, realistic exercise involving multiple teams, sometimes with live systems and external partners. These are demanding to organise and run, but they test the whole response under realistic conditions.

Designing a useful scenario

The scenario is what makes or breaks an exercise. A few principles help:

Base it on real risks

Use your business impact analysis and risk register. Scenarios such as a cyber attack that takes core systems offline, the loss of a key supplier, a building being unavailable, or a sudden loss of key staff are far more useful than unlikely catastrophes.

Make it uncomfortable

A scenario that the plan handles perfectly teaches you little. Build in complications: the backup site is also affected, the usual decision-maker is unreachable, the press calls before you have a statement, customers start posting on social media.

Release information in stages

Real disruptions unfold over time, with incomplete information. Releasing updates, called "injects", at intervals forces participants to make decisions without knowing everything.

Test the plan, not the people

Make it clear that the exercise is testing the plan and the organisation's readiness, not judging individuals. People who fear being blamed will play it safe, and you will learn less.

Who to involve

• Decision-makers who would lead a real response.
• Operational teams who carry out recovery steps.
• Communications, HR and legal, who are often forgotten until the moment they are needed.
• Key suppliers, especially for functional tests that depend on them.
• An independent facilitator for larger exercises, who can manage the scenario and observe without being drawn into decisions.
• Observers whose job is to note what happens, what works and what does not.

After the exercise

The real value of a test lies in what happens next.

1. Hold a debrief immediately. While memories are fresh, ask participants: what went well, what was difficult, what surprised you?
2. Write a short report. Record the main findings, rated by importance, and specific actions.
3. Assign owners and deadlines. Every action needs someone responsible and a date.
4. Update the plan. Correct errors and gaps straight away.
5. Track actions to completion. Report progress to the relevant leadership forum, and check at the next exercise whether issues have been resolved.

How often to test

A reasonable rhythm for most organisations is:

• Plan reviews: at least annually, and whenever there is a significant change.
• Tabletop exercises: at least once or twice a year for critical services.
• Functional tests: at least annually for key recovery capabilities, such as restoring critical systems from backup.
• Full simulations: every one to three years, depending on risk and resources.

Vary the scenarios so that different parts of the plan, and different people, are tested over time.

Where testing fits in continuity maturity

Organisations at the earliest stage of continuity maturity have plans that have never been tested. As they mature, they test regularly and fix what they find. The most resilient organisations treat exercises as a routine part of how they work, test increasingly demanding scenarios, and can show that their response gets better each time.

The Business Continuity & Resilience assessment covers testing and exercising alongside business impact analysis, continuity planning, crisis management, recovery and broader organisational resilience. It is a quick way to see whether testing is your weakest link or whether the plans themselves need attention first.

Frequently asked questions

What is the difference between a tabletop exercise and a simulation?

A tabletop exercise is a discussion-based test where participants talk through their decisions in response to a scenario. A simulation involves carrying out actions in practice, sometimes with live systems, under more realistic conditions.

How long should a tabletop exercise take?

Two to three hours is typical, including a debrief. Longer exercises can be useful for complex scenarios, but attention tends to drop after about three hours.

Who should own business continuity testing?

A named continuity lead usually coordinates testing, but each critical service owner should be accountable for making sure their plans are exercised and improved.