The short answer
Run one scenario with three timed injects among the people who would actually manage a crisis, and in 90 minutes you expose more real gaps than a year of policy reviews. Assign a facilitator, timekeeper and scribe, keep the discussion decision-focused, and close by converting each finding into an owned, dated corrective action.
Key takeaways
- A tabletop exercise is a facilitated, discussion-only drill with no impact on live systems, making it a low-cost, safe and repeatable way to test an incident response plan with leadership and operations.
- Keep the group tight: a senior decision-maker, an IT/security core, legal, communications and a scribe, with a facilitator and timekeeper who are not the 'owners' of the incident.
- Build the scenario on three escalating injects that force decisions about confirmation, escalation, communication and recovery rather than drifting into technical analysis.
- The value is the decision log and open-question register, not a polished story: record every decision, assumption and follow-up as the session runs.
- Turn each gap into a corrective action with an owner and due date, brief leadership on the top priorities, and open the next exercise by checking their status.
- Free national scenario packages from cyber agencies accelerate preparation, letting you adapt ready-made scenarios and discussion questions instead of starting from a blank page.
Why 90 minutes is the right size
A tabletop is a facilitated discussion in which the leadership team walks through a realistic scenario, articulates decisions and exposes gaps in roles, authority and communication. National cyber agencies describe this kind of exercising as one of the most cost-effective ways an organisation can test its ability to respond to a cyber incident — and unlike technical simulations, it touches no live systems, so it is safe and easy to repeat.
The 90-minute window works because it forces constraints: one scenario, one group of decision-makers and a small number of injects. Executives who will not clear several hours for an exercise can follow three or four decision points, and the operations team gets direct feedback on how leadership reacts under time pressure. The decisions that most often shape an incident's outcome — confirming the event, when to escalate, what to say externally — fit naturally into this window.
- Discussion-only: safe, inexpensive and repeatable with minimal approvals
- A fixed timebox forces focus on decisions rather than the full lifecycle
- Realistic time pressure trains teams to act on incomplete information
Who belongs in the room
Composition matters more than headcount. Alongside the operational core you need a senior leader who can commit resources and make business decisions; without that authority the session becomes a discussion that cannot resolve anything. A typical set is a senior executive such as a CFO or risk leader, the head of IT/security, a legal representative, a communications lead and a scribe to record findings.
A practical range is six to twelve people who genuinely own response decisions, plus separate facilitator, timekeeper and scribe roles that do not belong to the people 'running' the incident. You may add an HR representative or an external incident-response provider as an observer, but remember that a wider circle makes 90 minutes harder to hold. The scribe keeps the decision log, while the facilitator stops the room from sliding into technical detail and keeps every block moving.
- Senior leader with authority over resources and budget
- IT/security and the incident response lead
- Legal, communications/PR and, when relevant, HR
- Facilitator, timekeeper and scribe as distinct roles
Choose a scenario and write three injects
Start with a scenario that has a real ancestor — a similar incident in your industry or among organisations of comparable size. Cyber agencies publish ready-made tabletop packages with objectives, scenarios and discussion questions spanning ransomware, phishing, insider threats and industrial control system compromise. You can adapt these to your own systems and sector rather than authoring everything from scratch.
Build the story on three escalating injects, short messages that move the timeline forward. The first inject is detection: on a Friday evening, for example, your SOC flags suspicious activity or file encryption. The second is escalation: more systems are affected, the 'pay or not pay' question appears and you decide whom to bring in. The third is communication and recovery: who notifies the regulator, customers, staff and insurers, and how the team restores services. Each inject should end in a concrete decision, not a technical deep dive.
- Inject 1 — detection and first severity assessment
- Inject 2 — escalation, scope, ransom decision, involving partners
- Inject 3 — external communications, regulators and service recovery
The 90-minute agenda
Break the time into blocks and respect them. The first ten minutes set the ground rules, distribute the scenario and confirm roles. Three blocks of roughly fifteen minutes then walk each inject, with the team discussing and taking a decision in every one. After that comes a consolidation block for decisions and open questions, followed by a hotwash and the action register. The last five minutes assign owners and set the date of the next exercise.
The clock is the exercise: the timekeeper moves the room to the next block whether or not the discussion feels finished. That trains the team to act on partial information, exactly as it must in a real incident. When a conversation clearly goes too deep, the facilitator moves the topic to the open-question list and returns the group to a decision. The output is a decision log with the assumptions the group made under time pressure, not a perfect plan.
- 0–10 min: ground rules, scenario and roles
- 10–55 min: three injects with decisions
- 55–70 min: consolidate decisions and open questions
- 70–90 min: hotwash, action register, owners and dates
Facilitation ground rules
The biggest risk is turning the exercise into a technical meeting about 'what exactly happened'. Separate three layers: what is fact in the scenario, what the group assumes, and what it decides. Facts come from the injects, assumptions go on the open-question list, and decisions are recorded with who made them and why. This prevents the team from hiding behind uncertainty.
Create a no-blame environment: the purpose is to find weaknesses in the plan, not to find fault. The facilitator reminds the room that silence and confused roles are themselves valuable findings. It also helps to mark explicitly which decisions need a lawyer, insurer or external expert, so the team understands both the limits of its authority and how quickly external resources must be engaged.
- Separate scenario fact, group assumption and the decision taken
- Keep open questions distinct from decisions
- No-blame atmosphere: test the plan, not the people
From findings to corrective actions
A tabletop pays off only when every gap becomes a corrective action with an owner and a date. Cyber agencies publish preparation and response checklists that work well as the basis for an action register — clarifying roles, drafting a regulator notification template, verifying the incident team's contact list or testing backup and recovery assumptions.
After the session, the response lead prepares a short brief for leadership: what works, which gaps were found, which actions were assigned and when the next check happens. Resist the urge to fix everything at once: pick the three to five highest-impact actions, assign owners and track them. Keep the register alive between exercises and open the next one by reviewing the status of previous items.
- Every gap maps to an action with owner, due date and status
- A one-page leadership brief summarises findings and assignments
- The next exercise begins by checking the status of past items
Frequency and repeatability
Guidance on frequency varies, but practice shows that a single generic scenario once a year is rarely enough; a common failure is one annual drill covering a broad story that challenges nobody. Better to run shorter, focused sessions more often: a baseline scenario such as ransomware annually, with narrow checks — for example, regulator notification or data-breach response — after major changes in team, systems or requirements.
Free tools and scenario packages from national cyber agencies keep the programme affordable, letting an internal team run sessions themselves; in more mature settings you can engage accredited providers for structured tabletop or live-play exercises. Set a rhythm, put it in the calendar, and make each session slightly harder than the last. That turns readiness testing from a one-off event into an ongoing discipline.
- A baseline tabletop at least annually; focused checks after significant changes
- Free scenario packages keep regular exercising affordable
- Every session verifies the status of actions from the previous one
Put it into practice
90-Minute Tabletop Run-Sheet: Scenario, Decision Log and Action Register
This one-page run-sheet carries a team from ground rules to assigned corrective actions. Print it or share it for the scribe, and fill it in as the session runs so you leave with a ready decision log and an owner list rather than vague memories.
- Lock in the single scenario and three injects before inviting anyone
- Confirm the roster: senior decision-maker, IT/security, legal, communications and scribe, with facilitator and timekeeper named
- Agenda with five blocks and their timeboxes (0–10, 10–55, 55–70, 70–85, 85–90 minutes)
- For each inject, three columns: scenario fact, group assumption, and the decision taken with the name of the decider
- Decision log: time, decision, rationale, decision-maker and open questions
- Escalation and communication log: to whom (regulator, insurer, customers, staff), when, by whom and what was said
- Corrective action table: gap, action, owner, due date, status and source inject number
- One-page leadership brief: what works, gaps found, actions assigned
- Exit agreement: who publishes the findings and when the next exercise is scheduled
Questions people ask
What is the minimum roster for a useful 90-minute tabletop?
At minimum you need a senior leader who can commit resources, the head of IT or security, a legal representative, a communications lead and a scribe, plus a facilitator. The timekeeper role can sit with the scribe or facilitator. Without the senior leader the session risks becoming talk with no authority, and without legal and communications you will not test the most painful points — external statements and regulator notifications.
Does a tabletop exercise touch live systems, and is it safe to run?
No — a classic tabletop is a discussion and does not touch production networks or require taking services down, so approvals are minimal and the event is safe and repeatable. If you also want to test the technical side, such as isolating a segment or restoring from backups, that is a separate technical simulation that needs planning and approval and should not be mixed into the 90-minute discussion session.
How do we stop the room drifting into technical detail?
Separate three layers: scenario fact (defined by the inject), group assumption (moved to the open-question list) and the decision (recorded with a name). The facilitator and timekeeper pull the group back to a decision when discussion goes deep, and complex technical topics are logged as open questions for separate follow-up. The session tests who makes decisions and how, not the mechanism of a particular attack.
What should we do with the results after the exercise ends?
Immediately afterwards the incident response lead prepares a short brief for leadership covering what works, which gaps were found and which corrective actions were assigned with owners and dates. Pick the three to five highest-impact actions and track them in a register that stays alive between exercises. Open the next exercise by reviewing the status of previous items so the programme genuinely improves readiness rather than being a one-off event.
How often should an organisation run incident tabletops?
A baseline exercise at least once a year is common, but a single generic drill is usually not enough. Run additional focused sessions after major changes — new roles, new systems, changed regulatory requirements or a real incident. Many organisations prefer shorter, more frequent checks of individual functions such as regulator notification or data-breach response over one long annual event.
Which scenario should we start with if we have never run one?
Choose a realistic scenario close to home with a known ancestor, such as ransomware or compromise of an executive mailbox if your sector has seen those. National cyber agencies publish ready-made packages with scenarios and discussion questions you can adapt to your own environment. Make the first session simpler than you feel you need: three clear injects and obvious roles, so the team learns the format before you add complexity.
Sources and further reading
Sources were checked when this page was generated. Confirm changing dates, rules and prices with the original publisher.
- CISA Tabletop Exercise PackagesCybersecurity and Infrastructure Security Agency (CISA)
- CISA Releases Incident and Vulnerability Response Playbooks to Strengthen Cybersecurity for Federal Civilian AgenciesCybersecurity and Infrastructure Security Agency (CISA)
- Computer Security Incident Handling Guide (NIST SP 800-61 Rev. 2)National Institute of Standards and Technology (NIST)
- Tabletop Exercise in a BoxGovernment of British Columbia
- Exercise in a BoxNational Cyber Security Centre (NCSC)