How Do You Run a Tabletop Exercise That Tests Real Readiness?

A tabletop exercise tests real readiness when it runs on your own environment with the people who make each decision, and when it is allowed to find a gap. Its output is a timed list of the moments where people paused or waited, with an owner for each fix.

What is a tabletop exercise?

A tabletop exercise is a discussion-based walkthrough of an incident scenario. A facilitator presents the scenario in stages, and participants describe what they would do and who they would call at each point.

CISA publishes free Tabletop Exercise Packages that include template objectives, scenarios and discussion questions, along with planning templates and an after-action report template. They are a practical starting point for structure.

Source: CISA Tabletop Exercise Packages.

Why does an exercise have to be able to fail?

A test that could not have failed proves nothing about the response. If the scenario is generic and the right answers are obvious, the exercise confirms that people know the plan, which is different from showing that the plan works in your environment.

Our post The System Looked Ready. explains why documented roles describe intent until they have been exercised together. Our post Security Leaders: How Do You Measure Readiness? sets out the rule we apply to any proof, that it has to be able to fail.

How does a walkthrough differ from a readiness test?

Both kinds of exercise have a place. A walkthrough builds familiarity with the plan, and a readiness test checks whether the plan holds.

Element	Walkthrough exercise	Readiness test
Scenario	A general scenario, often from a template	Built on your systems and recent incidents
Participants	The security team and its usual contacts	Everyone who holds a decision, including approvers outside security
Injects	Follow the planned path	Add the delays real incidents bring
Output	Familiarity with roles and the plan	A timed list of gaps, each with an owner and a retest date

How do you run a tabletop exercise that can fail?

1. Choose a scenario from your own risks. Build the scenario on systems and providers you actually use, such as a help desk reset used to take over an admin account.
2. Invite the people who own each decision. Include the approvers outside security, such as the leader who signs off on taking a system offline, along with any provider that would be involved.
3. Write injects that test the handoffs. Add the complications real incidents bring, such as an approver who cannot be reached or logs that turn out to be missing.
4. Record every pause. Note each question the team had to answer about its own environment and how long it took to get the answer.
5. Assign owners and retest. Give each gap an owner and a date, and count it as open until a later test shows the fix works.

For a scenario built on a common entry point, read how to protect the help desk from social engineering.

What should the exercise check?

• Logs exist where you need them. Confirm the systems in the scenario keep the logs an investigation would need, for as long as you would need them.
• The containment owner knows it is them. Ask who approves taking an account or system offline, and whether that person agrees.
• Approvers can be reached. Test the contact path for leaders outside security, including outside business hours.
• Automation does what you expect. Walk through which playbooks would fire and confirm someone has checked them recently.
• Provider handoffs work. Confirm what your MDR or IT provider may do on its own and how it reaches your team.
• The environment matches the plan. Check that the systems and settings the plan assumes are still the ones in place.

The last check can turn up drift between the plan and the tenant. For how to handle it, read what to do when configuration drift is detected.

What happens after the exercise?

Write the after-action report while the timeline is fresh, listing each gap with its owner and retest date. Each gap counts against readiness until a later test shows the fix works.

Accelerynt runs operational tabletop exercises that pressure-test response across identity, endpoint and cloud workflows. To plan one for your team, talk to an engineer.

If a provider handles part of your response, its actions belong in the exercise too. In Accelerynt MDR, our team defines response protocols with yours before an incident, and we test containment playbooks regularly to verify they work. The MDR stages page explains how. For the metrics that show whether response is improving, read which SOC metrics show whether risk is going down.

To measure the pauses you find, read why incident response stalls after the alert fires. For turning results into a readiness measure, read how to measure security readiness.

Frequently asked questions