Home / Knowledge hub / Tabletop exercise
Knowledge hub
Tabletop exercise
A talk-through of an incident scenario to test the plan without touching systems.
What it means
A tabletop exercise is a discussion-based rehearsal of an incident. A facilitator describes a scenario, such as customer data found for sale or ransomware on a file server, and the people who would respond talk through what they would do, step by step. No systems are touched. Nobody types a command or restores a backup; the work is the conversation.
NIST describes tabletop exercises as discussion-based sessions where team members meet to talk through their roles and responses in an emergency, under the direction of a facilitator. The value is in finding disagreements and unknowns in a calm room, not during an actual incident.
Why it matters
A written incident plan looks complete until someone has to use it. A tabletop shows the gaps cheaply: nobody knows who can approve shutting a service, the contact list is out of date, legal has not been told, or the plan assumes a tool you no longer have.
It also builds the habit of working together. During a real incident, decisions are made under stress, and rehearsed people make better ones. Auditors and insurers often ask whether you test your incident response plan, and a record of exercises answers that.
How it shows up
A typical session lasts a couple of hours. The facilitator introduces the scenario and adds new facts every few minutes, such as a journalist calling or a regulator asking questions. Attendees include engineering, security, operations, legal, communications and a business decision maker.
Mistakes: only technical staff attending, a scenario too easy to be useful, and no follow-up. Capture the gaps, give each an owner and a date, and repeat the exercise. Scenarios built from your own data breach risks and real findings are the most useful.
Questions people ask
Tabletop exercise, answered
How is a tabletop different from a penetration test?
A pentest tests the application. A tabletop tests the people and plan that respond when something goes wrong. No systems are touched in a tabletop.
Findings from a pentest make good scenarios.
Who should attend?
Everyone with a role in an incident: engineering, security, operations, legal, communications and a senior decision maker.
Include the people who would be unreachable on a bad night, so you learn about gaps in cover.
How often should we run one?
At least once a year, and after major changes in systems, people or the plan. Short, frequent sessions work better than a rare long one.
Vary the scenario each time.
What should we produce?
A short list of gaps, owners and dates, plus updates to the plan and contact list.
Without follow-through the session is only a meeting. Review progress at the next session.
Do we need an outside facilitator?
Not necessarily, but an outsider asks questions insiders skip. For a first session, a neutral facilitator often helps.
Pick someone who will challenge the plan.
Sources
Where this comes from
Related
Terms that sit next to this one
Incident response plan
A written plan for who does what in the first hours after a security incident.
Incident response
The agreed plan for the hours after something has gone wrong.
Incident playbook
A step-by-step guide for handling one type of incident the same way each time.
Breach notification
Telling regulators and affected people about a data breach within a set time.
Post-incident review
A blameless look back at an incident to improve the plan and the system.
Does your plan survive a bad scenario?
Real findings make the best scenarios. We prove what we exploited with the request, response and proof, so your rehearsal starts from facts. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.