What is a tabletop exercise?
A tabletop exercise is a structured discussion in which the people who would respond to an incident or disaster talk through a realistic scenario and explain what they would do. A facilitator presents the scenario in stages, and participants describe their decisions, whom they would call and which part of the plan they would follow. No systems are changed, shut down or restored. The point is to test the plan, the roles and the decisions cheaply and without any risk to production. NIST SP 800-84, the NIST guide to test, training and exercise programs, describes tabletop exercises alongside hands-on functional exercises.
How a tabletop exercise runs
- Planning: choose objectives, such as testing who may authorize taking systems offline or how breach notification decisions are made, and write a scenario that fits the organization.
- Participants: IT and security responders, business owners, communications, legal and an executive with authority to make the big calls. Outside parties such as an incident response retainer firm or a cyber insurer may join.
- Injects: at intervals, often every 15 to 20 minutes, the facilitator adds a development that forces new decisions.
- Scribe or observers: record decisions, disagreements and gaps as they appear.
- After-action report: each gap gets an owner and a due date, and the plan, playbooks and contact lists are updated.
Example: a scenario built from injects
- Tuesday, 9:00 a.m.: the identity team sees a global administrator sign-in from an unfamiliar country, approved through an MFA push.
- 9:40 a.m.: new forwarding rules appear on the CFO's mailbox, sending copies of mail to an outside address.
- 11:00 a.m.: a supplier calls to confirm a change of bank details that was approved from the CFO's mailbox.
- 2:00 p.m.: legal asks whether any of this is a reportable breach and who makes that call.
Typical findings from a session like this: nobody is sure who may disable a global administrator account outside business hours, the emergency access account's credentials are in a safe that no one can reach remotely, and legal and communications each assumed the other would contact the supplier. None of those gaps would show up in a technical test.
Tabletop vs. walkthrough, simulation, parallel and failover tests
| Test | What happens | Risk to production | What it proves |
|---|---|---|---|
| Walkthrough | Team reads the plan step by step to confirm it is current | None | Plan accuracy |
| Tabletop exercise | Facilitated discussion of a scenario | None | Roles, decisions, communication, plan gaps |
| Simulation | Responders carry out steps with real tools against a staged event or test systems | None to low | Technical skill, timing and coordination |
| Parallel processing | Recovery systems run real workload beside production | Low | Recovery systems give correct results |
| Failover | Production moves to the secondary system or site | Moderate to high | Switchover works under real load |
A tabletop cannot prove that a backup restores or a failover works, because nothing is actually done. Organizations use tabletops to find decision and communication gaps, then use technical tests to prove the technology.
Tabletop exercise on the CompTIA Security+ exam
Tabletop exercises appear in two SY0-801 objectives: objective 3.4, with continuity and disaster recovery testing, and objective 4.7, with incident response preparation. Wording such as "discuss", "walk through", "conference room", "minimal cost" or "without affecting production systems" points to a tabletop. "Hands-on", "realistic" or "test the responders' technical ability" points to a simulation, "compare results without disrupting production" points to parallel processing, and "switch production to the secondary site" points to a failover test. When a question asks for the least disruptive way to test roles and decisions, the tabletop is the answer; when it asks for proof that systems actually recover, it is not.