How to Test Your Business Continuity Plan (and Prove It Works)

To test a business continuity plan, choose a test format that matches your maturity — a tabletop walkthrough, a functional simulation, or a full failover exercise — run it against a realistic scenario with success criteria agreed in advance, then compare actual recovery times against your targets. An untested plan is a set of assumptions with a cover page. This guide walks through how to run the test and how to judge, honestly and in numbers, whether you passed.

Choose the right type of test for where you are

Business continuity testing is a ladder, not a single event. On the bottom rung sits the tabletop exercise: the people named in the plan gather in a room or on a Teams call, a facilitator reads out a scenario, and everyone talks through what they would do, step by step, with the plan open in front of them. It costs a couple of hours and finds a surprising number of problems — outdated phone numbers, steps that assume someone who left last year, two people who each thought the other owned a task.

Above that sits the functional test, where you actually do something: restore last night's backup to a spare machine, redirect the main phone number, or have the team work from home for a day using only what the plan provides. At the top is the full failover exercise, where you deliberately run the business from your recovery arrangements for a set period. If you have never tested before, start with a tabletop. Failing a cheap test first is the whole point.

Build a scenario worth testing against

Vague scenarios produce vague results, so pick something specific and plausible for your business. For most NZ organisations the shortlist looks like this: an extended power cut, a severed fibre connection, flooding or weather damage that makes the office unusable, a ransomware infection that locks your files, or the one person who knows all the passwords being unreachable for a week.

Before anyone plays out the scenario, write down what success looks like. That means agreeing a recovery time objective (RTO — how quickly each system must be working again) and a recovery point objective (RPO — how much data you can afford to lose) for every system in scope. If those numbers are not written down before the test starts, you cannot fail the test — and a test you cannot fail teaches you nothing.

Run the test like it's real

Appoint a facilitator who runs the scenario and an observer who does nothing except take notes with timestamps. The facilitator's job includes making things harder: partway through, announce that the IT manager is on a flight, or that the backup office has lost power too. Resist the urge to rescue people — if someone is stuck because the plan is wrong, that pause is your most valuable finding. Set clear boundaries first, though: agree in advance which live systems, customers and data are strictly off limits, so the test cannot cause the very outage it is simulating.

Measure against numbers, not impressions

The mood in the room after a test is a terrible measure of success — teams often feel good precisely because someone improvised heroically around a broken plan. Measure instead: actual recovery time for each system versus its RTO; actual data loss versus the RPO; minutes until the first message reached staff, and until the first reached customers; the percentage of participants who knew their role without prompting; and the number of plan steps found to be wrong, outdated or missing.

The technical numbers only mean something if you genuinely exercise the recovery path. Restoring a real backup to a test environment and timing it end to end is the single most informative measurement you can take, and it is far easier when your backups and workloads sit in well-managed cloud services, where a restore can run in an isolated environment without touching production.

Turn findings into fixes — then retest

Hold the debrief within a week, while memories are fresh, and keep it blameless: the plan failed or passed, not the people. Turn every finding into an action with an owner and a date — update the contact tree, rewrite the steps that were wrong, buy the backup router, document the password handover process. Then schedule a retest of the specific things that failed. A finding without a retest date is a finding you have quietly decided to ignore.

Set a testing cadence and get help where it's thin

A workable rhythm for a small or mid-sized business: a tabletop exercise once or twice a year, a technical backup-restore test more often than that, and a fuller exercise annually if your operations justify it. Always test again after major change — a new core system, an office move, or turnover in a role the plan depends on.

Testing is also where the gap between the plan on paper and your actual IT setup shows up, so it pays to have the people who run your infrastructure in the room. Solution Squad is a New Zealand IT company — Microsoft Partner and One NZ partner — with offices in Auckland and Hamilton, supporting businesses NZ-wide, and continuity testing fits naturally within managed IT services, because we already know where your systems and backups live.