How to Run a Tabletop Exercise That Isn't a Waste of Time

A tabletop exercise is worth the time when it tests specific decisions, involves the people who would actually make them, uses a scenario built from your own systems, and ends with a short list of fixes that each have an owner and a due date. Most exercises that feel wasted skip at least one of those. They run a generic scenario, invite whoever is free, talk for two hours, and produce a report nobody reads.

This guide walks through how we plan and run tabletop exercises for small and mid-sized organizations, from setting objectives to closing out the action items.

What is a tabletop exercise?

A tabletop exercise is a facilitated, discussion-based session. A group of responders and decision-makers walks through a realistic incident scenario and talks through what they would do at each stage. Nobody touches production systems.

It sits at the lighter end of the testing spectrum. Functional exercises and full-scale simulations test people and systems under live conditions. A tabletop tests the plan, the roles and the decisions. NIST SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, covers the differences if you want the formal version.

Most tabletops run two to four hours. That's long enough to get past the obvious first steps and into the harder calls that come later.

Why do so many tabletop exercises feel like a waste of time?

The failure patterns are predictable:

• No clear objective. The exercise exists because an auditor or insurer asked for one.
• The wrong people in the room. Technical staff attend, but nobody who can approve taking a service offline or notifying customers.
• A generic scenario. Participants can't relate it to their own systems, so they answer in generalities.
• A happy path. Every tool works, every person answers the phone, and the incident wraps up neatly.
• Weak facilitation. One senior voice dominates, or the group spends 40 minutes on a side debate.
• No follow-up. Gaps get discussed, then forgotten.

Each section below addresses one of these.

How do you set objectives for a tabletop exercise?

Start with two or three objectives. Each one should describe something you want to test and be specific enough that you can say afterward whether it was met.

Weak objective: "Improve incident response readiness."

Better objectives:

• Confirm the team can identify who has authority to disable a customer-facing application during business hours and after hours.
• Test whether we can determine, within the first hour, which customer records were in an affected system.
• Validate the escalation path to legal counsel and the decision process for notifying customers.

Good sources for objectives include findings from past incidents, audit or assessment results, sections of your incident response plan that have never been used, and recent changes. A new cloud platform, a new outsourced provider or a reorganization are all reasons to test whether the plan still fits.

Who should participate?

Invite the people who would really be involved, not a representative sample. For most organizations, that means 8 to 12 participants.

Add a note-taker whose only job is capturing decisions, questions and gaps. The facilitator should not also be the note-taker.

Executives are often the hardest to schedule. If you can't get them for the full session, consider a shorter, separate executive tabletop focused on the decisions only they can make.

How do you design a realistic scenario?

The scenario should match your objectives and your environment. If your objective is testing customer notification decisions, the scenario needs a data exposure. If it's testing recovery, it needs an outage.

Scenarios that work well for small and mid-sized organizations include:

• Leaked cloud access keys. A key with broad permissions turns up in a public code repository.
• A compromised vendor. A managed service provider or software supplier with remote access to your systems reports that its own environment was breached.
• Exposed customer data. A storage bucket holding customer exports is found to have been publicly readable for months.
• A critical outage. Your core line-of-business application goes down during the busiest week of the quarter.
• Insider data misuse. An employee who recently resigned downloaded a large volume of customer records in their last two weeks.
• A lost unencrypted laptop. A laptop holding HR or client files is left on a train, and disk encryption was never turned on.

Build the scenario from your real environment. Use your actual system names, your real vendors, and the people who actually hold each role. When participants recognize the systems, they stop answering hypothetically and start answering specifically.

A sample scenario timeline

Here's a condensed outline for the leaked cloud keys scenario:

1. Starting situation (Tuesday, 4:30 p.m.): A developer notices that a configuration file pushed to a public repository three weeks ago contains an access key for your production cloud account.
2. Inject 1: A billing alert shows a spike in compute spending in a region you don't use.
3. Inject 2: Access logs show the key was used to list storage buckets, including one that holds nightly customer data exports.
4. Inject 3: The team discovers that log retention for that account is only 14 days, so activity from the first week of exposure can't be reviewed.
5. Inject 4: A large customer's security team contacts your account manager asking whether they were affected.

Each stage forces a harder decision than the last. That progression is what makes the session useful.

What are injects and how should you use them?

Injects are pre-scripted pieces of new information the facilitator introduces as the exercise progresses. They move the scenario forward and keep it from settling into an easy conclusion.

Useful injects tend to fall into three types:

• New facts. Log findings, a vendor update, a discovery about the scope of affected data.
• Complications. A key person is on leave, a backup turns out to be incomplete, a tool doesn't have the data you expected.
• Outside pressure. A customer inquiry, a regulator question, a request from the board for an update.

Write your injects in advance and list them in order with the time or trigger for each. The Homeland Security Exercise and Evaluation Program (HSEEP) calls this a master scenario events list. Prepare two or three spare injects too. If the group resolves something faster than expected, you'll have more material ready. If they're struggling, you can skip ahead.

How do you facilitate a tabletop exercise well?

The facilitator steers the discussion and shouldn't be one of the people whose decisions are being tested. An internal facilitator from another team can work, as can an outside one.

Set ground rules at the start:

• This is a no-fault exercise. We're testing the plan and the process, not individuals.
• Answer based on what you would actually do today, with the tools and access you actually have.
• If you don't know, say so. That's a finding, not a failure.

During the session, keep asking follow-up questions: "Who specifically would do that?" "How would you know?" "Where is that written down?" "What if that person doesn't answer?"

Watch the clock and park side discussions in a visible list. Draw in quieter participants by name, especially when a senior leader is steering everyone else.

How do you keep the exercise realistic?

Realism comes from making people check rather than assume. Ask participants to open the actual incident response plan and find the relevant section. Have someone pull up the contact list and check whether the after-hours number for your cloud provider is on it. If someone says "we'd check the logs," ask them to confirm those logs exist and how far back they go.

Add realistic constraints:

• Start the incident at an inconvenient time, like late Friday or the day before a holiday.
• Make one key person unavailable.
• Give incomplete information early, the way real incidents unfold.

Don't let the group "fight the scenario" by declaring it impossible. If a participant says that can't happen here, note it as an assumption to verify later and continue.

What goes in the after-action report?

Run a short hot wash immediately after the exercise. Spend 15 minutes asking participants what worked, what didn't and what surprised them, while it's fresh.

Then write the after-action report within one to two weeks. Keep it short. It should cover:

1. The objectives and whether each was met
2. What went well
3. Gaps and issues identified
4. An improvement plan with specific actions

The improvement plan is the most important part. Every action needs a named owner and a due date:

Track these items like any other project work. Review their status at the start of your next exercise. If the same gaps show up twice, that's a sign the follow-up process isn't working.

Frequently asked questions

How often should we run tabletop exercises?

Once a year is a reasonable minimum for a full exercise. Shorter quarterly sessions, each testing a different scenario, often deliver more. Also run one after major changes, such as a new plan, a system migration or a merger.

Should we use an outside facilitator?

An outside facilitator brings neutrality and makes it easier to ask uncomfortable questions of senior staff. An internal facilitator from a different department can also work well, as long as they aren't a participant in the response being tested.

Do executives need to attend?

At least one person with authority to make high-impact decisions should be there. Without that person, participants end up saying "we'd escalate to leadership" and the most important decisions never get tested.

Where can we find free tabletop exercise materials?

CISA publishes its Tabletop Exercise Packages (CTEPs) for organizations to download and use for their own exercises. Each package is customizable and includes sample objectives, scenarios and discussion questions, plus templates for invitations, feedback forms and an after-action report. They make a solid starting point that you then adapt to your own systems and people.

Next steps

• Pick two or three objectives from your plan's weakest or least-tested areas.
• Build a scenario that fits them, using your real systems and vendors, and script injects that add complications.
• Invite the actual decision-makers, including someone who can approve high-impact actions.
• Publish an after-action report within two weeks, with an owner and due date on every action, and review those actions at the next exercise.