How to run a business continuity exercise: the tabletop exercise step by step, with a sample script

The short answer: a business continuity exercise is a rehearsal of the plan with the people who would have to carry it out, on a realistic scenario and against the clock. The most useful one to start with is the tabletop exercise: two or three hours in a room, a facilitator who tells the incident in parts and a team that decides what it would do at each moment, with the plan in front of it. Nobody passes or fails. A good exercise is one that finds problems, and its output is a list of improvement actions with an owner and a date, not a certificate that everything worked.

The rest of the article is the full method in seven steps, the script of ACME's exercise and what it found, the mistakes I see most often and a template to prepare your own.

Which kind of exercise to choose

Not all exercises are the same, and you do not have to start with the most expensive one. From lightest to heaviest:

A tabletop exercise does not prove that your backup restores in four hours, and a technical test does not prove that anyone knows who declares the crisis. You need both. This article focuses on the tabletop, because it finds the most problems per hour spent and almost nobody does it well.

Step 1. Set a specific objective

"Test the continuity plan" is not an objective: there is no way to tell at the end whether it was met. A useful objective can be checked with a yes or a no:

• Does the crisis team get together and decide to invoke the plan within an hour?
• Does anyone know which customers to notify, with what message and who signs it?
• Does the fallback order procedure let us keep selling while the ERP is down?

Two or three objectives per exercise. If you try to test everything, you will test nothing properly.

Step 2. Choose a scenario that hurts

The scenario comes from the business impact analysis, not from imagination. Take a critical process, look at what it depends on and break that dependency at the worst reasonable moment: month-end close, peak season, payroll day.

A good scenario meets three conditions:

• It is plausible. Ransomware, a cloud provider outage or a fire in the warehouse. Not a meteorite.
• It forces decisions. If the answer is obvious, the exercise teaches nothing. The scenario has to put the team in front of dilemmas: pay or not, tell people now or wait to know more.
• It reaches the limits of the plan. If the plan says the ERP's RTO is 4 hours, the scenario lasts more than 4 hours.

Step 3. Write the injects

The scenario is not told all at once. It is told in parts, through injects: each inject is a new piece of news that forces the team to revisit what it has just decided. A two-hour exercise usually has between five and eight.

Each inject has:

• The simulated time: "It is 11:30, two and a half hours after the incident".
• What happens: "The backup provider confirms the last good backup is from 02:00 last night".
• The question to the team: "What data have you lost and what do you do about it?".
• What the plan says should happen, which only the facilitator knows.

The last column is what turns the exercise into a test: at the end, what the team did is compared with what the plan said.

Step 4. Choose the participants and the roles

The room needs the people who would really make the decisions, not their delegates. On top of that, you need three roles who do not take part:

• The facilitator tells the scenario, delivers the injects and keeps the pace. It should not be the author of the plan: they tend to defend it.
• The observer writes down what happens, above all what nobody says out loud: the doubts, the glances at phones and the "someone else handles that".
• The role-player answers as the provider, the customer, the journalist or the supervisor when the team calls them.

Between six and twelve participants. With more, half the room just watches.

Step 5. Run the session

At the start, the facilitator makes three rules clear:

1. There are no right or wrong answers. The plan is being assessed, not the people.
2. Work with what you have. If the plan lacks a piece of information, nobody looks it up on their phone: it is noted as missing.
3. What you decide, you say. "I would call the provider" does not count. Who calls, on what number and to ask for what.

Then, inject by inject: the facilitator reads the news, the team discusses for ten or fifteen minutes and says what it does, and the observer writes it down. The facilitator neither corrects nor gives hints. If the team gets stuck, they move to the next inject and the sticking point is recorded as a finding.

Step 6. Hold the hot debrief

When it is over, before anyone leaves, half an hour with three questions:

• What worked as we expected?
• Where did we get stuck, and why?
• What would have to change in the plan so it does not happen next time?

This is when the best findings come out. By the next day, people have already reconstructed what happened and remember it better than it was.

Step 7. Turn findings into actions

Each finding becomes an action with an owner, a date and a closure criterion. "Improve communication" is not an action. "Draft the notice template for the three major customers, owner: sales director, by 30 November" is.

The exercise report records the objective, the scenario, who took part, the findings and the actions. Management reviews and approves it. And the next exercise starts by checking whether the previous one's actions were closed.

A full example: ACME's exercise

ACME is a distributor that sells online and by phone. In its business impact analysis, the order management process has a maximum tolerable period of disruption of 24 hours, an RTO of 4 hours and an RPO of 1 hour, and depends on the ERP, which runs on its own servers, and on the web shop, which is a cloud service.

Exercise objectives:

1. The crisis team gets together and invokes the plan within an hour.
2. Orders keep coming in, even by hand, while the ERP is down.
3. The three major customers know what is going on before they ask.

Participants: the CEO, the CFO, the head of operations, the head of IT, the sales director and the warehouse manager. An external facilitator and an observer from quality.

The script:

What it found:

The outcome: the first objective was met by a whisker (plan invoked at 50 simulated minutes), and the other two were not. No finding was a disaster on its own. Together, on a real Monday in December, they would have turned a serious incident into a lost week. That is exactly what an exercise has to find.

My rules for what the standards leave open

No standard tells you what a good exercise looks like. These are the rules I apply:

• If the exercise goes perfectly, the scenario was too easy. An exercise with no findings only shows that the team can answer what it already knew.
• The facilitator is not the author of the plan. Whoever wrote the plan tends to give hints and explain what they meant. The plan has to make sense on its own.
• You test the plan, not the people. As soon as someone feels examined, they stop saying "I don't know", and that "I don't know" is the most valuable finding.
• A finding without an owner is not a finding. It is an anecdote that will come up again at the next exercise.
• Change the scenario every time. Repeating last year's tests the team's memory, not the plan.

What the standards require

The most common mistakes

1. An exercise with a known script. If participants have read the injects beforehand, the exercise is a performance, not a test.
2. Testing only the technology. Restoring the backup on time is pointless if nobody decides to restore it.
3. Sending delegates. If the decision-makers are not in the room, you are testing a plan nobody will carry out that way.
4. Forgetting the providers. The scenario that happens most often in real life, a critical provider going down, is the one least rehearsed.
5. Not writing down the doubts. The observer is the first thing to be cut, and they collect half the findings.
6. A report with no actions. "Areas for improvement were identified" helps nobody. Each finding needs its owner and its date.
7. Not closing the previous actions. Next year's exercise finds the same problems, and so does the auditor.

A template to prepare your own

The script, one row per inject:

And the findings log, one row per action:

You can download the script and the findings log as CSV, with ACME's case already filled in, and open them in Excel or LibreOffice.

How to keep it solved

An exercise in loose spreadsheets has the same problem as a BIA in a spreadsheet: actions get lost from one year to the next, and nobody cross-checks the findings against the plan that needed changing.

In Almenara, the Continuity module records each exercise with its scenario, its results and its improvements, and each finding goes into Compliance as a corrective action, tracked until it is closed. The exercise stays as evidence for the ICT continuity control, and the next exercise starts from what was left open. If you would rather we prepare and run it, the business continuity exercise leaves you the exercise report and the improvement actions with their owners. And the DORA guide covers the rest of the testing obligations.

Frequently asked questions

What is the difference between an exercise and a test of the plan?

A test checks that something works: that the backup restores, that the alternate site starts up. An exercise checks that people know what to do and do it in time. A plan needs both.

How often should a business continuity exercise be run?

At least once a year, and whenever something important changes: a process, a system or a critical provider. DORA requires it at least yearly for financial entities, and ISO 22301 requires an exercise programme at planned intervals.

How long does a tabletop exercise take?

Two to three hours, plus half an hour of debrief. With less time the scenario cannot build up; with more, attention drops.

Should participants be told the scenario in advance?

The date and the length, yes. The scenario, no. If they know it, they will prepare their answers and the exercise will find nothing.

What evidence should be kept for the audit?

The objective, the scenario and the injects, the list of participants, the observer's notes, the report with the findings and actions, and proof that the actions were closed. An auditor looks mostly at the last one.

Does a cyber incident exercise count as a business continuity exercise?

Partly. A cyber exercise focuses on detecting, containing and notifying; a continuity exercise, on keeping the business running in the meantime. Ransomware works as a scenario for both, but the questions are different and both sides should be in the room.