Business Continuity

How to Run a Business Continuity Tabletop Exercise

A worked tabletop exercise for an order system outage: staged injects, the backlog arithmetic behind a 2 p.m. carrier cutoff, and the tests to assign afterward.

By Eric Kennedy · Thu Nov 05 2026 · 9 min read

ILLUSTRATIVE SCENARIO. It is 11:00. The order system came back an hour ago, 120 orders are still waiting, and the carrier collects at 2 p.m. Someone has to decide now whether to call in extra pickers, hold low-priority orders, ask the carrier for a later collection, or warn customers. A business continuity tabletop exercise is where you practice that decision before it is real.

This guide walks through one exercise built around a single order release workflow. It covers what to prepare, how to run the injects, the arithmetic that should drive the 11:00 conversation, and what to write down afterward. The numbers are constructed for teaching. They are not a client result or a benchmark.

Prepare one workflow and real shift data

Pick one process that ends in a commitment you can name. Here it is order release: orders arrive, are released to the warehouse, picked, packed and handed to the carrier before the 2 p.m. cutoff. One workflow is enough. An exercise that tries to cover the whole plan usually ends up covering none of it in enough depth to find a gap.

Then gather real operating data for a normal shift, not the numbers in the plan document. Ask operations for order arrivals by hour, processing capacity by hour with the staff actually rostered, the carrier contract or agreed collection time, and how orders are prioritized when the warehouse is behind. If the data does not exist, that is your first finding.

Assign roles before the day. You need a facilitator who runs the scenario and asks the questions, a note taker who records decisions and the reasons given, and the people who would make those decisions in a real outage: the operations lead, the IT owner for the order system, customer service and whoever talks to the carrier. Finance should attend if the decision involves overtime or customer credits.

Separate the simulated clock from the meeting clock

Write the simulated time at the top of every inject and keep it visible. The meeting may run 90 minutes while the scenario covers 08:00 to 14:00. If people lose track of which clock they are on, they start answering in meeting time ("we would sort that out after lunch") and the timing problem disappears from the discussion.

Move the simulated clock forward only when the facilitator says so. When someone says "we would call the carrier," ask at what simulated time, who makes the call and what they would say.

Run the injects in stages

ILLUSTRATIVE SCENARIO. The base case works like this. At 08:00 the queue is at zero. Orders arrive at 60 an hour. The order system fails at 08:00 and nothing is processed until it restarts at 10:00, so 120 orders are waiting.

Inject 1: the outage, 08:00

Tell the room the system is down, no estimated restart. Ask who knows first, who declares the incident, and what customer service says to a caller at 08:30. Ask whether orders still arrive. In this scenario they do, at 60 an hour, and the queue grows.

Inject 2: the restart, 10:00

The system is back. After restart the team can process 90 orders an hour in total. With 60 still arriving each hour, the queue shrinks by 30 an hour. From 120 orders at 10:00, it takes 4 hours to drain, and the queue clears at exactly 14:00.

That is the trap in the base case. The plan appears to work, but it works with zero buffer. Any slippage at all means orders are still waiting when the carrier arrives.

Inject 3: the slow first hour, 11:00

ILLUSTRATIVE SCENARIO. Now tell the room the first hour after restart ran at only 60 an hour, because the warehouse was rebuilding pick lists and checking for duplicate orders created during the outage. Arrivals and processing cancel out, so the backlog at 11:00 is still 120.

There are 3 hours until the 2 p.m. cutoff. To clear 120 orders in 3 hours, the team needs 40 an hour of catch-up on top of the 60 still arriving, so 100 an hour in total. At 90 an hour, the net drain is 30 an hour and the queue still holds 30 orders at 14:00.

At 10:00 both paths look identical. At 11:00, ask the shift lead for the first hour of actual releases before anyone promises a recovery time. A difference of 30 orders at that checkpoint consumes an hour of catch-up capacity.

Orders waiting at each decision point

The second graphic shows why 90 an hour is not enough once the first hour slips.

The 11:00 conversation

ILLUSTRATIVE SCENARIO. Ask which orders will still be on the floor:

Facilitator: Simulated time is 11:00. You have 120 orders waiting and 90 an hour of capacity. What happens at 2 p.m.?

Operations lead: We would be close. Maybe a few stragglers.

Facilitator: The arithmetic says 30. Which 30?

Operations lead: Probably the bulk orders. Same-day orders get picked first.

Facilitator: Is that written anywhere, or is it what the shift lead would do?

Customer service: We would want to know by noon so we can call the accounts that matter.

Facilitator: Who tells you, and how?

Notice what the room did not establish. It did not show that the shift lead actually picks same-day orders first, that two extra pickers can be found by 11:30, or that the carrier will wait. Discussion is not proof. A tabletop exercise is good at exposing assumptions and decision rights. It cannot confirm that people, systems or suppliers perform as described.

The 30 orders left at 14:00 also do not mean 30 customers miss their delivery. That depends on which orders they are, their service class, whether some are duplicates created during the outage, whether packing and the loading dock can keep up, and whether the carrier will take a late handoff or add a collection. Clearing the queue and delivering on time are different questions. The queue measures the order system. The customer feels the delivery date.

Clearing the whole backlog by 2 p.m. may not be the right objective at all. If same-day and contractual orders are protected and the remaining orders are standard ground with a next-day promise, letting 30 roll to the morning wave may be a sound decision. The exercise should make that a deliberate choice with an owner, not something the team discovers at 2:05.

What the guidance says

The CMS ISCP Exercise Handbook describes a tabletop as discussion-based, with a facilitator presenting a scenario and asking questions about roles, coordination and decisions, and with no equipment deployed. It describes functional exercises as staff performing their duties in a simulated operational environment. Its section on objectives asks for measurable outcomes and treats the time to clear transaction backlogs as part of recovery, not an afterthought. It also calls for an after action report covering strengths, areas for improvement and lessons learned, submitted to the business owner.

That handbook is written for federal information systems, and NIST SP 800-84 is federal guidance on IT test, training and exercise programs. Neither is a mandate for a private company, and neither provides evidence about how often exercises succeed or what they save. I use them because their structure is sound and freely available. The specific workflow, numbers and dialogue here are mine and constructed for illustration.

Close with tests, operators, evidence and dates

End the session by turning each unproven assumption into a test. For each one, record what will be tested, who will run it, what evidence will show the result, and the date. ILLUSTRATIVE SCENARIO. In this scenario the list might look like this:

The dates above are placeholders for the scenario. Set your own based on risk and the next peak period. The throughput test is the one I would run first, because every other decision in this scenario rests on whether 90 an hour is real.

Put these in the after action report with a named owner for each and a follow-up date. If the same gaps appear at the next exercise, the problem is no longer the plan. It is follow-through, and that belongs in your risk reporting.

For how internal audit can test the plan itself, see How to Audit a Business Continuity Plan. For the wider program around exercises, see Transforming Business Continuity Management for Mid-Market Leaders.

A tabletop result only helps if it reaches the people who decide on overtime, carrier terms and customer promises in a form they can act on. If you are not sure your current risk reporting does that, the Board-Ready Risk Reporting Scorecard is a quick way to check.

Take the Risk Reporting Scorecard