How to Test a Business Continuity Plan (And Why Most Tests Miss the Point)

By Mike, Founder of Navpoint Group | ACA-qualified Chartered Accountant

You've written the plan. It's sitting in a shared drive somewhere — maybe even printed and filed in a folder with a reassuring label on the spine. Job done?

Not quite.

A business continuity plan that hasn't been tested isn't a plan. It's a guess. And in my experience — nearly a decade across FTSE 100 businesses and top-10 accountancy firms — the gap between what organisations think will happen in a crisis and what actually happens is enormous.

This guide walks you through how to test your business continuity plan properly. Not with a tick-box exercise that makes everyone feel good, but with a test that genuinely tells you whether your business can keep operating when things go wrong.

Why Test?

Put bluntly, the most common reason business continuity plans fail isn't that they're badly written. It's that they've never been stress-tested against reality.

I've seen plans that look immaculate on paper fall apart within minutes of a simulated scenario — not because the plan was wrong, but because the people who needed to execute it had never practised doing so. They didn't know where to find the plan. They didn't know who was supposed to make the call. They argued about priorities that should have been agreed months ago.

Testing your BCP does three things that no amount of drafting can achieve:

It reveals assumptions you didn't know you'd made. Every plan is built on assumptions — about who's available, what systems are working, how quickly suppliers respond. Testing forces those assumptions into the open.

It builds muscle memory. When a real incident happens, you don't want people reading a document. You want them acting. Testing creates familiarity with roles, escalation paths, and decision-making under pressure.

It proves to stakeholders that you're serious. Whether it's your board, your clients, your insurers, or a regulator — a tested plan carries weight that an untested one simply doesn't. If you're working towards a more mature risk management framework, regular testing is a fundamental part of that.

The Four Levels of BCP Testing

Not every test needs to be a full-blown simulation. Think of testing as a ladder — each level builds on the last, and where you start depends on how mature your current planning is.

1. Document Review (The Desk Check)

What it is: Someone (ideally not the person who wrote the plan) sits down and reads through the BCP with a critical eye.

What you're looking for: Out-of-date contact details. Processes that reference systems you no longer use. Recovery time objectives that were plucked from thin air. Gaps where a critical function simply isn't covered.

When to use it: As a minimum, annually. Also after any significant organisational change — a restructure, an office move, a new system implementation.

This sounds basic, and it is. But you'd be surprised how many plans reference a server room that was decommissioned two years ago or list a "key contact" who left the business in 2022.

If your internal controls are in good shape, this review often happens naturally as part of your wider control environment. If they're not, a desk check is a good way to surface that too.

2. Walkthrough (The Talk-Through)

What it is: You gather the key people referenced in the plan — usually department heads or function leads — and walk through a scenario verbally. "If X happened, what would you do first? Who would you call? What would you need?"

What you're looking for: Confusion. Disagreement. Blank looks. All of which are infinitely better to discover in a meeting room than during an actual crisis.

When to use it: After a document review has confirmed the plan is broadly current. This is your first test of whether the plan works with actual people.

The walkthrough is where most organisations discover that their plan exists in a vacuum. The IT team has one understanding of recovery priorities, the operations team has another, and finance assumes someone else is handling the client communication. A walkthrough flushes out these disconnects before they matter.

3. Tabletop Exercise (The Simulation)

This is where things get interesting — and where I believe most organisations get the highest return on their testing investment.

What it is: A structured, facilitated scenario where your leadership team (or crisis management team) responds to an unfolding situation in real time. Not a discussion about what they would do. A live exercise where they're making decisions, receiving new information, and dealing with consequences.

What you're looking for: Decision-making under pressure. Communication breakdowns. Gaps between the plan and reality. Leadership dynamics. The moments where someone says "I assumed someone else was handling that."

When to use it: At least annually for any organisation that takes business continuity seriously. More frequently if you operate in a regulated sector or have complex dependencies.

I'll go into more detail on this below, because it's the type of test I facilitate most often — and the one I think makes the biggest difference.

4. Full Simulation (The Live Test)

What it is: Actually invoking elements of your plan. Relocating to your disaster recovery site. Switching to backup systems. Running operations from a secondary location for a day.

What you're looking for: Whether the physical, technical, and logistical elements of your plan actually work as described.

When to use it: For critical systems and high-risk environments. Not every organisation needs this, but if your BCP includes commitments like "we can be operational from our DR site within four hours," the only way to validate that is to do it.

Full simulations are expensive and disruptive, which is why most organisations below enterprise level don't run them regularly. But a well-run tabletop exercise can tell you 80% of what you need to know at a fraction of the cost and disruption. In the past I have recommended ‘lite’ versions of this, such as switching the site over to emergency power at a weekend to ensure the generator actually works.

The Navpoint Approach to Tabletop Exercises

Most tabletop exercises I've seen fall into one of two traps.

The first is the "reading group" — someone reads out a scenario, everyone nods sagely, someone says "yes, we'd activate the plan," and everyone goes back to their desks feeling reassured. Nothing was tested. Nothing was learned.

The second is the "ambush" — a scenario so extreme or contrived that participants disengage because it doesn't feel relevant. If your scenario involves a simultaneous earthquake, cyberattack, and alien invasion, people stop taking it seriously.

I take a different approach. I act as what I call the Games Master — I design and run the scenario, control the flow of information, and adapt the exercise in real time based on how the team responds.

Here's how it works in practice:

Before the exercise, I work with you to understand your business, your sector, your risk profile, and your existing plan. I design a scenario that's realistic for your organisation — something that could genuinely happen and that would test the areas where your plan is most likely to be vulnerable. This isn't a generic "ransomware attack" script pulled off the internet. It's built around your actual operations, your actual dependencies, and your actual people.

During the exercise, I present the scenario to your team in stages — what we call "injects." The situation evolves. New information arrives. Things get worse before they get better. And crucially, I'm watching and adapting as we go.

If the team handles the first phase comfortably, I increase the pressure. If they're struggling with a particular decision, I let it breathe so we can understand why. If someone makes a call that would have real consequences, I feed those consequences back into the scenario.

The goal isn't to catch people out. It's to create an environment where genuine decision-making happens — where people are reacting to a developing situation rather than discussing a hypothetical one. That's where the real insights live.

After the exercise, I run a structured debrief. What worked? What didn't? Where did the plan hold up, and where did it fall apart? What decisions were made well, and which ones would you want to revisit?

I then produce a detailed report with findings, observations, and practical recommendations — not a 50-page document you'll never read, but clear, actionable points that feed directly into improving your plan, and can be provided to auditors, insurers or other stakeholders to evidence completion of the test.

What Makes a Good Scenario?

The best tabletop scenarios share a few characteristics:

They're plausible. The scenario needs to feel like something that could actually happen to your business. A logistics company should be rehearsing supply chain disruption, not pandemic response (unless that's specifically relevant). A professional services firm should be thinking about data breaches, key person loss, or office access issues.

They're layered. A single event is too simple. Real crises compound — the power outage happens on the same day your IT manager is on holiday. The supplier failure coincides with your busiest quarter. Layering creates the complexity that reveals how your team actually thinks under pressure.

They force decisions. The scenario should present genuine dilemmas — moments where the "right" answer isn't obvious and the team has to weigh competing priorities. Do you prioritise client communication or operational recovery? Do you invoke the full plan or try to manage it informally?

They test communication, not just process. In my experience, the process is rarely the thing that fails. It's communication — internal and external. Who tells the board? Who talks to clients? Who coordinates with suppliers? What happens when the usual communication channels aren't available?

Common Mistakes When Testing a BCP

Testing the plan, not the people. The plan is a document. The test should be about whether the people responsible for executing it can actually do so. If your test is focused on whether the plan's contents are correct, that's a document review, not a simulation.

Not involving senior leadership. I understand that the CEO is busy. But if your crisis management structure relies on senior decision-makers, those people need to be in the room. A tabletop exercise with middle management only tells you half the story.

Running the same scenario every year. Your risk landscape changes. Your business changes. Your plan should change, and your tests should change with it. If you're running the same fire drill every September, you're building familiarity with one scenario, not resilience.

Treating it as pass/fail. There is no such thing as "passing" a tabletop exercise. The entire point is to find weaknesses. If you come out of a test with nothing to improve, either the test wasn't challenging enough or people weren't being honest.

Not following up. The test is only valuable if the findings lead to action. Every exercise should produce a clear set of recommendations with owners and deadlines. If the same issues surface in the next test, that's a governance problem, not a planning problem.

How Often Should You Test?

As a general guide:

Document review: At least annually, plus after any significant change.

Walkthrough: Annually, ideally six months offset from your document review so you're touching the plan twice a year.

Tabletop exercise: Annually for most organisations. Quarterly or semi-annually for regulated sectors, critical infrastructure, or businesses with complex operational dependencies.

Full simulation: As required — typically driven by regulatory obligations or specific recovery commitments that need validation.

The right cadence depends on your risk profile, your sector, and how mature your broader business continuity programme is. If you're just starting out, begin with a desk check and a walkthrough. If you've been maintaining a plan for years but never tested it properly, a facilitated tabletop exercise is probably the single most valuable thing you can do.

Ready to Test Your Plan?

If you've read this far, you probably already know that your plan needs testing. The question is whether you want to facilitate that yourself or bring in someone who does this regularly.

I run tabletop exercises for businesses across the UK — the kind of organisations that need professional-grade testing without the six-figure consultancy price tag. I design every scenario, tailored to your business, and I facilitate the exercise personally. No junior consultants, no generic scripts, no death by PowerPoint.

If you'd like guidance on how to facilitate a BCP test yourself, or want to discuss whether a full facilitated exercise is right for your business, get in touch. I'm always happy to have a conversation — no obligation, no hard sell.

Mike is the founder of Navpoint Group, a consultancy specialising in business continuity, risk management, and internal controls for SMEs and mid-market businesses. With nearly a decade of experience across FTSE 100 companies and top-10 accountancy firms, he helps organisations build practical resilience — without the corporate overhead.