Designing a Tabletop Exercise That Exposes Real Gaps

The usual corporate tabletop runs ninety minutes, uses whichever disaster was in the news that quarter, and ends with the facilitator asking, "Any final thoughts?" Nobody has any. The group agrees the discussion was valuable, someone writes "communication" under areas for improvement, and the same people sit through a nearly identical scenario the following year.

That exercise did not fail because the scenario was dull. It failed because nobody decided beforehand what it was supposed to prove, so it had nothing to disprove. A tabletop is a cheap, low-stakes test of decisions, authority and information flow. If it never produces an uncomfortable silence, it has not tested much.

The sequence below works for hospitals, utilities and retailers alike. It borrows vocabulary from the Homeland Security Exercise and Evaluation Program (HSEEP), FEMA's exercise doctrine, because the terms are useful even if you never touch a federal grant.

Step 1: Write objectives before you choose a disaster

Start with three to five objectives that an evaluator could mark as met or not met. HSEEP asks for SMART objectives (specific, measurable, achievable, relevant, time-bound), but there is a quicker test: could the people in the room fail this?

• Weak: "Discuss the company's response to a cyber incident."
• Better: "Within the first simulated hour, the team identifies who has authority to take the order-management system offline and confirms that person can be reached on a Saturday night."

The second version names a decision, an owner, a time window and a dependency. It can fail, which is what makes it worth testing.

Good objectives tend to come from near-misses (the vendor outage nobody escalated until lunch), from untested sentences in the plan ("Facilities will coordinate with building management"), and from old findings marked closed without proof.

If you have a finished business impact analysis, mine it. An objective such as "confirm payroll can run manually if the HR platform is down past its four-day recovery time objective" ties the exercise to a number leadership already approved. Our guide to setting RTOs and RPOs covers where those numbers should come from.

Step 2: Build the scenario backward from the objectives

With objectives in hand, the scenario becomes a delivery vehicle. Pick the hazard that forces the decisions you want to see, not the one that would make the best movie.

Testing authority to shut down systems? Ransomware does that well. Testing staff accountability and alternate work locations? You need something physical, such as a fire on a lower floor or a police perimeter that keeps people out of the building for three days. Testing operations at 40 percent staffing? Use an illness scenario; the pandemic continuity briefing lists the absenteeism assumptions worth pushing on.

Four design rules keep a scenario honest:

1. Make it plausible for this organization. Once participants decide a scenario is far-fetched, they stop thinking and start performing.
2. Close the easy exit. If the plan's answer is "fail over to the secondary site," make the secondary site slow or unavailable. Otherwise the exercise resolves in one sentence.
3. Start with incomplete information. Real incidents open with partial, contradictory reports.
4. End every module with a choice. Recall questions test memory. Picking between two bad options tests the plan.

Injects are where the testing happens

The scenario sets the stage; injects apply pressure. An inject is a new piece of information delivered at a set time: an email from a regulator, a call from a reporter, a status update that contradicts the last one. HSEEP tracks them in a Master Scenario Events List (MSEL), which records when each inject lands, who receives it and what response it should provoke.

Planners often skip that last column. If you cannot describe a good response, the inject is just noise.

Here is a sample timeline for a two-and-a-half-hour ransomware tabletop at an invented regional retailer:

The 1:10 inject is the one designed to hurt. Most plans quietly assume backups will be there. When they are not, the conversation shifts from technical recovery to business tradeoffs, which is exactly where the real cost of ransomware downtime gets decided.

Step 3: Invite the people who own decisions

A tabletop full of delegates tests whether delegates can guess what their bosses would do. Invite the people who hold the authority your objectives are about; deputies attend only if the principal is genuinely unavailable.

Next, add the people the plan depends on who never attend planning meetings: facilities, payroll, procurement, the person who actually runs the backup jobs, the shift supervisor who would be first on scene. Their answers to "how would you actually do that?" are often where the gaps show up.

Keep the main table to roughly 12 to 20 players. Fill the support roles deliberately:

• Facilitator: runs the conversation, keeps time, asks the hard follow-ups. Should not be the plan's author.
• Controller: delivers injects on schedule and adjusts pacing.
• Evaluators: one for every two or three objectives, each with an Exercise Evaluation Guide (EEG) describing what good looks like.
• Scribe: captures decisions, open questions and exact quotes.

If your organization runs an emergency operations center, consider testing the handoff between the executive table and the EOC itself. That seam is a common source of duplicated or dropped work.

Step 4: Facilitate for friction

Facilitation is where most tabletops go soft. A few habits make a large difference:

• Ask named people, not the room. "Priya, the network is still up and the vendor says isolate now. Your call?" gets an answer. "What would the team do?" gets a summary of the plan.
• Ask them to show you. When someone says "I'd call the vendor," ask them to find the number in the plan and read it aloud.
• Follow every answer one more step. "You'd escalate to the COO. She's on a plane for six more hours. Then what?"
• Keep the clock moving. Announce how much simulated time has passed. Decisions deferred to "later" should come back with consequences attached.
• Tolerate silence. Count to ten before filling a pause.
• Do not rescue. If the facilitator answers the question, the exercise has tested the facilitator.

Step 5: Break the "everyone agrees" trap

Consensus in a tabletop usually means the senior person spoke first, the plan's author is defending it, or the question was too easy. None of those is a finding. Some countermeasures:

1. Poll before discussing. At major decision points, have everyone write down an answer (or vote on their phones) before anyone speaks. A seven-to-five split on whether to pay a ransom is worth more than an hour of polite agreement.
2. Ask the most junior relevant person first. Hierarchy bends answers.
3. Run parallel groups. Give two breakout tables the same inject and compare their answers. The differences are your findings.
4. Feed conflicting facts to different functions. Tell IT the restore will take six hours and tell operations the vendor estimated two days. See whether anyone notices.
5. Ask what would have to be true. "For that to work, what has to already be in place?" turns a confident answer into a list of assumptions you can check.
6. Have the senior sponsor set the tone. An opening line from the most senior person present, saying that finding problems is the goal, changes behavior more than any facilitation trick.

Step 6: Hold the hot wash immediately

The hot wash happens right after play ends, before anyone checks email. Give it 20 to 30 minutes. Go around the table and ask each participant for one thing that worked and one thing that worried them. Evaluators then add observations against each objective, and the scribe captures it all in participants' own words.

Resist the urge to solve problems here; the hot wash collects, it does not fix. Hand out a short feedback form too, because some people will write what they would not say in front of their manager.

Step 7: Write an improvement plan someone owns

HSEEP pairs the after-action report with an improvement plan, usually abbreviated AAR/IP. The report summarizes the scenario and rates performance against each objective. HSEEP's four-level scale is handy: performed without challenges, performed with some challenges, performed with major challenges, or unable to be performed. A plain scale like that keeps the report from sliding into adjectives.

The improvement plan is the part that changes anything. Compare two versions of the same entry:

Draft the AAR/IP within two to three weeks and review it with participants. Track items to closure alongside audit findings. Anything still open at the next exercise becomes one of that exercise's objectives.

Before your next tabletop: a checklist

• Three to five objectives, each one capable of failing
• Scenario chosen after the objectives, with the easy exit closed
• An MSEL with an expected response written for every inject
• Decision-owners confirmed, plus the people who actually do the work
• A facilitator who did not write the plan, evaluators with EEGs, and a scribe
• Anonymous polling ready for at least two decision points
• Senior sponsor briefed to open with "we are here to find problems"
• Hot wash built into the agenda
• Last exercise's open items folded into this one's objectives

If you need a starting scenario, CISA publishes free tabletop exercise packages covering cyber and physical threats. Treat them as raw material. Rewrite the injects around your own objectives, and the exercise will tell you something you did not already know.