A business continuity plan that has never been tested is not a plan. It is a document. The distinction matters because the gap between the two usually only becomes clear when something actually goes wrong.
Tabletop exercises are how you close that gap before an incident forces it open. Run well, they show you where decision-making breaks down, where the plan assumes things that aren't true, and where the people who are supposed to act have never actually read what they're supposed to do. Run badly, they confirm that everything is fine and leave you no better prepared than before.
Most organisations run them badly, or don't run them at all.
What a tabletop exercise actually is
A tabletop exercise is a structured discussion in which a small group of people (usually the leadership team and whoever owns operational continuity) works through a realistic scenario to test how the organisation would respond. No systems are actually activated. No one is scrambling to find a supplier's phone number in real time. The point is to talk through the decisions and surface what the plan gets right, what it gets wrong, and what it doesn't cover.
It is distinct from a live exercise or a full simulation, which involves people actually executing their roles under pressure. Tabletops are lower-cost and lower-disruption than full simulations, which makes them the right first step for any organisation that hasn't tested its plan before, and a useful annual check-in for those that have.
What makes one useful
The scenario has to be plausible. Not catastrophic. Not so improbable that participants spend the exercise pointing out how unlikely it is, rather than thinking about the response.
For most Irish organisations, the most useful scenarios sit in a narrow band: an IT system is unavailable for more than 24 hours. A key supplier fails without warning. A significant number of staff are unable to work for a week. A public incident requires the organisation to communicate with stakeholders under pressure. These are not exotic. They happen. And the organisations that have thought them through before they happen respond better when they do.
The scenario also needs to develop over time. A single frozen snapshot, "your IT system is down, what do you do?", is too easy to answer in the abstract. A well-designed tabletop introduces new information as the exercise runs: two hours in, your IT provider says it will take 72 hours, not 24. Your CEO is unreachable. A journalist has asked a question. Each inject forces the group to make a real decision with incomplete information, which is what an actual incident looks like.
Where plans typically break down
Running these exercises at DEDICO, certain gaps come up repeatedly. They are worth knowing before you run your own.
The first is contact lists. Most continuity plans include them. Very few are current. Suppliers change key account managers. Staff leave. Phone numbers go to voicemail because they're personal mobiles nobody carries any more. A contact list that hasn't been reviewed in twelve months is likely to be unreliable, and an exercise will surface this quickly.
The second is role clarity under pressure. Plans typically assign roles (decision-maker, communications lead, recovery coordinator), but the person in the role often has not read the plan in any detail, and certainly not recently. When the scenario puts them on the spot, they either improvise (which is fine if their instincts are good, but not a plan) or they defer to whoever is senior in the room, which may or may not be the right person.
The third is the communications gap. Who tells staff what is happening, and when? Who communicates with funders, regulators, or key clients? Most plans have a section on this. Most teams, when pressed, can't answer who owns the first external communication and what it should say.
The fourth is recovery assumptions. Plans often state a Recovery Time Objective, the maximum tolerable downtime for a critical function, without testing whether that objective is actually achievable. A tabletop will expose quickly if the assumption that "we can restore the database in four hours" depends on a vendor response time nobody has verified.
Running the exercise
The basics are straightforward. Keep the group small: five to eight people is usually the right size. Larger groups diffuse accountability and make it harder for quieter participants to contribute. The facilitator should be someone who didn't write the plan, ideally external, but at minimum someone who can challenge the responses rather than validate them.
Start by briefing participants on the scenario and the ground rules. The exercise is not a test of individuals. It is a test of the plan and the system. People need to feel safe saying "I don't know" or "the plan doesn't cover that."
Work through the scenario in stages, with injects at pre-agreed intervals. After each inject, the facilitator asks: what would you do now? Who decides? What does the plan say? What would you actually do if you couldn't reach that person?
Take notes in real time. The value of a tabletop is in the after-action report, not in the exercise itself. If the gaps aren't written down before people leave the room, they will be forgotten by the following week.
The after-action report
The output of a tabletop is a short written document, typically two to three pages, that summarises what the exercise tested, what it found, and what needs to change. It should be tabled at the next board meeting. Not as reassurance that everything is fine, but as a working document with named owners and deadlines for each remedial action.
A board that sees a tabletop after-action report has done its governance job on business continuity. A board that has never seen one probably hasn't.
How often
For most organisations, an annual tabletop is sufficient, combined with a lighter review of the contact lists and role assignments every six months. After any significant change to the operation, such as a new site, a major IT migration, or a change in senior leadership, an unscheduled tabletop is worth considering, because the plan was written for an organisation that no longer exists.
Frequently asked questions
Do we need external facilitation for a tabletop exercise?
Not necessarily. But the facilitator should not be the person who wrote the plan, and should be willing to push back on responses rather than accept them. If internal facilitation feels too comfortable, external is worth the cost.
How long does a tabletop exercise take?
A well-designed tabletop for a single scenario typically runs two to three hours. A more complex exercise covering multiple scenarios can run a full day. Most organisations find a half-day the right scope for a first exercise.
What scenario should we use?
Start with the most likely, not the most dramatic. An IT outage, a key-person absence, or a supplier failure will surface more useful gaps than a scenario so extreme it triggers "we'd just call the government." The goal is to test decisions you'd realistically have to make.
Is a tabletop exercise the same as a fire drill?
No. A fire drill tests a physical evacuation procedure. A tabletop tests decision-making, communication, and recovery across a broader set of functions. They are complementary, not equivalent.
Does the plan need to be fully written before we run a tabletop?
It should exist in some form. A tabletop against a blank page is just a planning session. But the plan does not need to be polished or complete. Running a tabletop against a draft is a legitimate way to pressure-test it before finalising.
DEDICO supports Irish organisations with business continuity planning and tabletop exercises. Related reading: Structuring a business continuity process, Croke Park case study. If you need a plan built or an existing one tested, get in touch.