Tabletop Exercise Guide: Plan, Run and Review

A tabletop exercise is a discussion-based session in which the people who would respond to an incident walk through a simulated scenario and describe, role by role, what they would do. It is a role-playing activity in which players respond to scenarios presented by one or more facilitators, and it is non-technical: participants do not manipulate live systems or use security tools in real time. This guide sets out how to define objectives, assemble participants, design a scenario with injects, facilitate the session and convert findings into corrective actions.

TL;DR

• A tabletop exercise tests the incident response plan, the decisions behind it and the communication between teams, not the performance of tools.
• Planning has four parts: objectives, a planning team, a scenario tied to real risks, and a schedule of injects.
• Participants should span IT, operations, security, legal, HR and executive leadership, with a facilitator moderating and a scribe recording.
• The exercise yields value only when findings enter an after-action report with named owners and are folded back into the response plan.
• No legal frequency is prescribed, so most organizations run a full session on a regular cycle and use smaller sessions between cycles.

Table of Contents

• What a tabletop exercise tests
• Define objectives before designing anything
• Assemble the planning team and the participants
• Design the scenario
• Run the session
• Evaluate and convert findings into action
• Checklist for a first exercise
• How often to run an exercise
• Our perspective
• Support for your first exercise
• FAQ
• Sources

What a tabletop exercise tests

A tabletop exercise examines whether an organization’s response plan, as written, survives contact with the decisions that a realistic event forces. Exercises of this kind test an organization’s incident response plan and can identify gaps in people, processes, and technology. The same framework notes that a session can improve communications and cross-team collaboration and provide training outside an actual incident, which is its principal advantage over learning the same lessons during a live breach.

The distinction from a technical simulation is important. A red-team engagement or a live-fire drill evaluates controls and detection under attack conditions. A tabletop evaluates judgment: who declares an incident, who has authority to take a system offline, who speaks to customers, when counsel is engaged, and what happens when two people believe they own the same decision. Because no system is touched, the exercise is inexpensive, carries no operational risk and can include executives who would never join a technical drill.

In practice, a tabletop is well suited to questions such as the following:

• Does the response plan name an incident commander, and does everyone agree who that is?
• Are escalation thresholds specific enough to be applied under time pressure?
• Do the communications, legal and executive functions know what they will be asked, and by whom?
• Are third-party contacts (insurers, forensic providers, key vendors) documented and reachable?
• Do backup and recovery assumptions hold when examined by the people responsible for them? A related discussion of recovery-focused sessions appears in our guide to running a tabletop for disaster recovery testing.

Define objectives before designing anything

An exercise without objectives produces a conversation, not evidence. Objectives should be few, observable and tied to the plan under test. Three to five is a workable range for a single session of two to four hours. Examples of well-formed objectives include: confirm that the on-call engineer can reach the incident commander within the time the plan specifies; confirm that the decision to notify regulators or customers has a named owner; and confirm that the team can identify which systems hold regulated data.

The objectives determine everything downstream: the scenario, the invitation list, the length of the session and the measures used afterward. Where an organization is new to the practice, a narrow scope (a single plan, a single team, a single scenario) is preferable to an ambitious enterprise-wide exercise, since early sessions that overreach tend to expose so many gaps that the findings cannot be prioritized.

Assemble the planning team and the participants

The planning team is distinct from the participants. It writes the scenario, controls the schedule of injects and holds the knowledge of how the exercise will unfold, so its members generally should not play. The framework describes planning as defining objectives, assembling a team and designing a scenario with injects.

Roles during the session

CISA distinguishes four roles: players actively discuss or perform their regular roles; facilitators provide updates and moderate discussion; note-takers document activities; and observers may support players with questions or subject matter expertise. A practical allocation follows.

Participants should include subject matter experts from critical functions such as IT, operations, security, legal, HR, and executives. Participation by someone with authority to commit resources is what separates a useful exercise from a purely technical review. Where the organization uses a formal command structure, the roles in the exercise should mirror it; the basics of incident command structure and roles are a suitable reference for assigning them.

Logistics

The logistics of the session (room or video bridge, calendar holds, materials, breaks, and who receives what in advance) are modest but are a frequent cause of a weak exercise, since an interrupted or truncated session cannot reach its later injects. The same discipline applied to events generally is described in this overview of event logistics planning, and the principle of fixing the roster, the schedule and the contingencies before the day carries over directly. Provide players with the objectives and ground rules in advance, but withhold the scenario details.

Design the scenario

Scenarios should simulate threats that could plausibly affect the organization, and they should be tailored to the exercise objectives and to the organization’s threats, risks and vulnerabilities, using its own processes, policies and playbooks to structure responses. A scenario borrowed unchanged from a template will frequently describe systems the organization does not operate, and participants will then discuss the scenario’s fiction instead of their own plan.

CISA publishes CISA Tabletop Exercise Packages, customizable sets of resources that include template objectives and scenarios for a range of threat types, which are a reasonable starting point for adaptation.

Common cyber scenario types

The following categories cover most of what small and midsize organizations should rehearse. Each should be adapted to the organization’s actual systems and data.

1. Ransomware affecting file servers or a line-of-business application. Tests the decision to isolate systems, the status of backups, and the decision whether and how to engage law enforcement, counsel and insurers.
2. Business email compromise leading to a fraudulent payment. Tests finance and executive procedures for verifying payment changes, and the speed of escalation from a suspicious message to an incident.
3. Compromised cloud credentials. Tests logging, privileged access management and the ability to determine what was accessed. A related assessment approach is discussed in our piece on cloud security assessment for CISOs.
4. Vendor or supply chain compromise. Tests the inventory of third-party dependencies, contractual notification terms and the process for assessing exposure through a supplier.
5. Exposed vulnerability in an internet-facing system. Tests patching authority and emergency change procedures. Teams building this capability may consult our vulnerability management program guide and patch management strategy.
6. Data exposure involving regulated information. Tests legal, privacy and communications decision-making, which matters especially for independent healthcare practices and professional services firms.

Injects

Injects are items introduced periodically to simulate changes during an incident and prompt participants to analyze, discuss and respond. Candidate injects include incident reports, technical data and logs, news or social media items, regulatory notifications and customer complaints. A sound inject sequence escalates in complexity: an initial alert that is ambiguous, a second report that suggests wider scope, an external contact (a journalist, a customer, a regulator) that forces a communications decision, and a complication that invalidates an assumption, such as a backup that proves unusable.

A short worked example illustrates the construction for a ransomware scenario at a fifty-person firm:

• Inject 1 (start): The service desk reports that several users cannot open shared documents and that file names have changed. Who is notified, and who decides whether this is an incident?
• Inject 2 (about 30 minutes in): Logs show a privileged account authenticating from an unfamiliar location overnight. What is contained first, and who authorizes it?
• Inject 3: A ransom note references stolen client data and a public posting deadline. Who briefs leadership, and with what information? A structured format is described in our executive briefing framework.
• Inject 4: A client calls to ask whether their files are affected. What may be said, by whom, and when is counsel consulted?
• Inject 5: The last verified backup is found to be eleven days old. How are priorities and recovery order decided?

Each inject maps to at least one objective, and the facilitator should record which objectives remain untested at the end of the session.

Run the session

A session proceeds in a predictable sequence: an introduction that states the objectives and ground rules, the scenario briefing, the inject cycles with discussion, and a closing summary. The guidance on duration in published frameworks varies, and two to four hours is typical for a single-scenario exercise within a small or midsize organization. A longer session is rarely justified unless several teams are involved.

Facilitation practice

The facilitator’s task is to moderate, not to teach. Several techniques improve the quality of the discussion:

• Ask each function to state its first action and its rationale before others comment, which prevents the most senior voice from setting the answer.
• Ask “who decides?” and “where is that written?” repeatedly. Unclear authority and undocumented procedure are the most common findings.
• Hold the schedule of injects, but permit a discussion to run if it reveals a significant gap, and note what is deferred.
• Record disagreements as findings. A disagreement about who should act indicates an ambiguity in the plan that a real incident would amplify.

The tone of the session also matters. MITRE’s cyber exercise playbook warns that an “us against them” mentality between exercise controllers and the training audience can be toxic and must be actively dispelled. The exercise evaluates the plan and its supporting processes, not individual performance, and the facilitator should state this at the outset and reinforce it throughout.

Evaluate and convert findings into action

Evaluation begins immediately. The research literature recommends a hotwash directly after the exercise to collect participant feedback, followed by a formal debrief that reviews observation logs. Findings are then compiled into an after-action report that documents lessons learned and assigns specific action items to address identified gaps.

An after-action report is useful when each finding carries four attributes: a description of what occurred, the objective it relates to, a recommended correction, and a named owner with a due date. Findings without owners are the usual reason that the same gap appears in the next exercise. The after-action method is treated at greater length in our after-action review guide.

The corrections must reach the documents that govern response. CISA advises that, after a session, organizations incorporate lessons into the incident response plan and other policy and procedure documents so that habits and behaviors evolve. Revised playbooks, such as those described in our incident response playbooks mapped to NIST, CISA and AWS, provide a concrete destination for many findings.

Checklist for a first exercise

How often to run an exercise

No specific legal frequency is defined for tabletop exercises generally, although particular regulatory regimes or insurance requirements may impose their own expectations, which should be verified with counsel or the relevant regulator. In the literature, organizations often use after-action reports to shape the objectives and complexity of the following year’s exercise, which implies an annual improvement cycle. Because exercises are effective when they change habits, regular sessions, including scaled-down ones, are a reasonable supplement. A common pattern is one full cross-functional session per year, with shorter single-team sessions between, and an additional session after a major change in systems, vendors or leadership.

Our perspective

We approach tabletop exercises as an instrument of clarity under pressure rather than a compliance artifact. Our technical advisory work in risk assessment, security remediation and infrastructure automation repeatedly shows the same pattern: the technical controls are rarely the first point of failure, and the first ambiguity is usually who decides, who informs, and in what order.

For that reason we design exercises in which technical staff, leadership and communications functions share one table and one plan. Our leadership training on calm communication under pressure addresses the human side of the same problem, since a well-written playbook is of limited use if the people executing it have not rehearsed speaking plainly while information is incomplete.

We also regard the after-action report as the product of the exercise. Findings that become tracked work items, with owners and dates, are what convert a discussion into resilience, and our software and advisory services are built around keeping that record clear.

Jesse Hart

Support for your first exercise

Organizations that prefer an outside facilitator, or that want the findings translated into remediation work, can engage us through technical consulting and risk review. We offer technical systems and risk review, infrastructure automation review and cybersecurity assessments, and we can also deliver leadership workshops for the executives who will take part.

For teams that need to keep records of findings, contracts and production work organized after an exercise, Project Relay is published at $49 per month, and advisory support for independent consultants is described on the Project Praxis page.

FAQ

How long should a tabletop exercise last?

Two to four hours suits a single-scenario session for a small or midsize organization. Shorter sessions can test one team or one decision, while longer ones are justified when several departments or external parties participate. Allow time at the end for the hotwash.

Who should facilitate the exercise?

The facilitator should understand the plan and the scenario but should not be its sole author or owner, so that the plan can be examined without defensiveness. Many organizations use an experienced internal practitioner from another department, or an external advisor. A separate scribe should record the discussion.

Is a cyber tabletop exercise the same as a penetration test?

No. A penetration test attempts to compromise systems technically, while a tabletop is non-technical and involves no live systems or tools. The two are complementary: the test shows what an attacker can reach, and the exercise shows whether the organization can respond when that happens.

What should we do with the results?

Compile them in an after-action report that assigns each finding an owner and a due date, then update the incident response plan and related procedures. Review progress before the next exercise, and use unresolved items to set its objectives.

Sources

• Cybersecurity Tabletop Exercise Tips (CISA)
• Tabletop Exercise Framework (OpenSSF Vulnerability Disclosures Working Group)
• Cyber Exercise Playbook (MITRE)
• Cyber Tabletop Exercise Guidebook, 2025
• CISA Tabletop Exercise Packages
• Event Logistics Planning: Six Areas Organizers Must Lock

Recommended

• IT Leaders: Run a Tabletop This Quarter for Disaster Recovery Testing
• 5 Copy Ready Runbook Examples and Reusable Template for Ops Teams
• After Action Review: Four Questions and Ready Templates for Ops Teams
• Action Ready Incident Response Playbooks Mapped to NIST, CISA, and AWS