Tabletop Exercise: How to Plan and Run One for Cyber Teams
A tabletop exercise is a structured discussion in which the people who would handle a real incident walk through a realistic scenario, decision by decision, without touching any systems. NIST SP 800-84 puts it plainly: a tabletop exercise "is discussion-based only and does not involve deploying equipment or other resources".
This guide is for security leads, compliance managers, IT directors and founders. You have an incident response plan on paper. Now you need to prove it works. It is also for anyone whose auditor, insurer or regulator has asked, "When did you last test it?"
What a Tabletop Exercise Is
A facilitator presents a scenario, then asks the participants what they would do next. The NIST definition describes the mechanics: "A facilitator presents a scenario and asks the exercise participants questions related to the scenario, which initiates a discussion among the participants of roles, responsibilities, coordination, and decision-making".
The point is not to test the firewall. It is to test the plan and the people. NIST calls tabletop exercises "cost-effective tools to validate the content of IT plans, such as contingency plans and incident response plans, to ensure the plan content is viable and implementable in an emergency situation".
FEMA's Homeland Security Exercise and Evaluation Program (HSEEP), the methodology CISA itself uses, abbreviates the tabletop exercise as TTX. It defines a TTX as "a discussion-based exercise in response to a scenario, intended to generate a dialogue of various issues to facilitate a conceptual understanding, identify strengths and areas for improvement, and/or achieve changes in perceptions about plans, policies, or procedures".
Two features matter in practice. HSEEP says a TTX "requires an experienced facilitator". And participants should "be reminded that they are making decisions in a no-fault environment". People who fear blame give the expected answer. You want the one they would give at 2 a.m.
Tabletop vs functional vs full-scale exercises
HSEEP splits exercises into two families. "Discussion-based exercises include seminars, workshops, tabletop exercises (TTXs), and games". Operations-based exercises "include drills, functional exercises (FE), and full-scale exercises (FSE)" and involve "a real-time response such as initiating communications or mobilizing personnel and resources".
The practical difference is effort. CISA's exercise planning page gives planning timelines for each type:
| Exercise type | What it does (CISA) | Planning timeline (CISA) |
|---|---|---|
| Seminar or workshop | Orients people to a plan, or develops a new plan or procedure | 1 to 2 months |
| Tabletop | Validates understanding of plans, rehearses concepts, assesses response and recovery needs | 3 to 4 months |
| Functional | Tests plans, procedures and the staff in management, command or control functions | 6 to 12 months |
| Full-scale | Simulates reality with complex problems that need rapid, trained responses | 12 to 24 months |
CISA's timelines describe exercises it plans with partners. NIST's own guidance for an internal tabletop is lighter: planning "is typically started at least three months before the conduct date for large, complex exercises and at least one month in advance for less complex exercises".
One caution on vocabulary. NIST notes that "some people use 'tabletop exercises' to refer to discussion-based exercises in general, while other people consider 'tabletop exercises' to refer to a specific type of discussion-based exercise". When an auditor or customer asks for a tabletop, confirm what they mean. A slide review in which nobody has to decide anything is not one.
Which Rules Expect You to Test Your Incident Response Plan

Few rules use the words "tabletop exercise". Many require you to test or evaluate a plan, and a tabletop, which takes no system offline, is a practical way to produce that evidence. Here is what the text says. We read each one at source on November 5, 2026.
| Rule | What the text requires | Status |
|---|---|---|
| HIPAA Security Rule, 45 CFR 164.308(a)(7)(ii)(D) | Procedures for "periodic testing and revision of contingency plans" | In force, addressable |
| HIPAA Security Rule proposed rule, January 2025 | Test incident response plans "at least once every 12 months" | Proposed, not final |
| NYDFS 23 NYCRR 500.16(d) | Test incident response and BCDR plans "at a minimum annually" | In force |
| FTC Safeguards Rule, 16 CFR 314.4(h) | Written plan, clear roles, revision after a security event | In force; no testing clause |
| EU DORA, Article 11(6) | Test ICT response and recovery plans "at least yearly", with cyber-attack scenarios | Applies since January 17, 2025 |
| NIST CSF 2.0, ID.IM-02 | Improvements identified from "security tests and exercises" | Voluntary framework |
HIPAA
The HIPAA Security Rule's contingency plan standard includes an implementation specification titled "Testing and revision procedures (Addressable)": "Implement procedures for periodic testing and revision of contingency plans". That text is in 45 CFR 164.308, current as of November 3, 2026.
Addressable does not mean optional. Under 45 CFR 164.306(d)(3), you assess whether the specification is a reasonable and appropriate safeguard. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure if that is reasonable and appropriate. Separately, the incident response specification at 164.308(a)(6)(ii) is required: "Identify and respond to suspected or known security incidents". Our HIPAA Security Rule safeguards guide explains the addressable logic in full.
The proposed Security Rule update of January 6, 2025 would go further. Its proposed 164.308(a)(12)(ii)(A)(3) says to "Review and test security incident response plan(s) and procedures" required by the proposed incident response paragraph "at least once every 12 months, document the results of such tests, and modify security incident response plan(s) and procedures as reasonable and appropriate". As of November 5, 2026 it remains a proposed rule. eCFR still shows the old text, and no final rule appears in the Federal Register.
NYDFS Part 500
New York's cybersecurity regulation is the most direct. Under section 500.16(d) of the Second Amendment, as posted by the New York Department of Financial Services, each covered entity "shall periodically, but at a minimum annually, test its: (1) incident response and BCDR plans with all staff and management critical to the response, and shall revise the plan as necessary; and (2) ability to restore its critical data and information systems from backups".
The same section requires the plans to address "disruptive events such as ransomware incidents" and requires training for "all employees responsible for implementing the plans". DFS labels its posted copy as not the official version, so check the official text before relying on precise wording.
FTC Safeguards Rule (GLBA)
Do not tell a client the FTC requires a tabletop exercise. It does not. 16 CFR 314.4(h) requires "a written incident response plan" that includes "the definition of clear roles, responsibilities, and levels of decision-making authority" and "the evaluation and revision as necessary of the incident response plan following a security event".
A tabletop is still the obvious way to check that roles and decision authority are actually clear. Our GLBA compliance guide covers the rest of the Safeguards Rule.
NIST and DORA
The NIST Cybersecurity Framework 2.0 has two outcomes that a tabletop feeds directly. ID.IM-02 reads: "Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties". ID.IM-04 covers incident response plans that are "established, communicated, maintained, and improved".
NIST SP 800-61 Rev. 3, published April 2025, replaced the 2012 Rev. 2 incident handling guide. It rates ID.IM-02 as a High priority for incident response and refers readers to SP 800-84 "for more information on simulations, tabletop discussions, and other forms of exercises".
In the EU, the Digital Operational Resilience Act (DORA) requires financial entities to test ICT response and recovery plans "at least yearly", and entities other than microenterprises must include "scenarios of cyber-attacks". Article 25 lists "scenario-based tests" among the tests in a resilience testing programme. DORA has applied since January 17, 2025.
PCI DSS is not covered here. Its standard sits behind a license agreement on the PCI Security Standards Council site. Read the incident response text in your own licensed copy before telling an assessor what it requires.
Real Cases: What Happens When Nobody Tests the Plan
The evidence that untested plans fail comes from government auditors, who publish their findings.
In GAO-23-107012 (September 2023), the Government Accountability Office reviewed the State Department. "State conducted a test of its incident response procedures in 2019. Subsequently, DS officials stated that they had planned to conduct a tabletop exercise to test its incident response procedures in 2020, but COVID-19 delayed it". The department's own policy required annual tests.
The same report answered the most common objection to testing. Contingency plans "can be tested in various ways such as walk-through and tabletop exercises, checklists, and simulations, which do not require systems to be powered down".
The problem is old. In GAO-14-354 (April 2014), "Four of the six agencies had not tested their incident response capability". GAO's conclusion still holds: "If an agency's incident response capability has not been tested, the agency will have limited assurance its controls have been effectively implemented".
In health care, untested contingency planning has a price tag. The HHS Office for Civil Rights opened a compliance review of Heritage Valley Health System after media reports of a data security incident. The resolution agreement records a $950,000 payment and lists the contingency plan standard at 164.308(a)(7) in the conduct the agreement covers. Its corrective action plan required contingency planning with "provisions related to testing and revision procedures," following an assessment of whether they are reasonable and appropriate.
How to Plan a Tabletop Exercise, Step by Step
The steps below follow the HSEEP cycle, which FEMA describes as "program management, design and development, conduct, evaluation, and improvement planning". Scale it to your size.
1. Get approval and set the objectives
NIST is direct about the first step: "It is important that when an exercise is being scheduled, managers are notified and their approval obtained". Executive sponsorship also gets senior people into the room.
Then write two to four objectives. Good objectives are testable. "Confirm who can authorize taking the payment system offline" is testable. "Improve ransomware readiness" is not.
2. Form a small planning team
HSEEP's planning team "manages and is responsible for exercise design, development, conduct, and evaluation". Its members are "not exercise players; they are trusted agents". Keep them out of the participant list so the scenario stays a surprise.
At minimum, name two roles. NIST describes "an exercise facilitator, who leads the discussion among the exercise participants, and a data collector, who records information about the actions that occur during the exercise". The note-taker matters as much as the facilitator. Those notes become the after-action report.
What this means for a small team. In a small company, the planning team may be one person, usually the security lead who also wrote the plan. That person should facilitate, not play incident commander. If the author of the plan answers the questions, you test their memory of the plan instead of the plan itself. Give the commander role to the person who would hold it on a holiday weekend, and borrow a colleague from finance or operations as data collector.
3. Choose the participants
NIST advises: "All personnel with responsibilities under the IT plan should participate in exercises; however, senior-level teams and operational-level teams should participate in separate tabletop exercises initially because of their different levels of responsibility". Once both groups have been exercised, run a combined session "to validate coordination between the groups".
For a cyber scenario, the operational room usually includes security, IT operations, engineering on-call, and whoever owns the affected service. The senior room includes the executive sponsor, legal counsel, communications, finance and, if you have one, the person who calls your cyber insurance carrier.
4. Write the scenario and injects
The scenario is the opening situation. Injects are new pieces of information the facilitator adds as time moves forward in the story. HSEEP defines the Master Scenario Events List (MSEL) as "a chronological timeline of expected actions and scripted events to be injected into exercise play by controllers". HSEEP holds a dedicated MSEL meeting for operations-based exercises. For a tabletop, HSEEP allows a "well-developed scenario to include injects" instead.
You do not have to start from a blank page. CISA publishes Tabletop Exercise Packages (CTEP): "With over 100 CTEPs available, stakeholders can easily find resources to meet their specific exercise needs". Each "includes template exercise objectives, scenarios, and discussion questions," plus templates for invitations, a slide deck, a participant feedback form and an after-action report. Cyber packages cover "ransomware, insider threats, phishing, and Industrial Control System (ICS) compromise," with sector versions for elections, local governments, maritime ports, water and healthcare.
NIST SP 800-84 also includes, in its Appendix A, "a sample tabletop exercise facilitator guide, sample participant guide, and sample after action report".
5. Set the length and logistics
NIST SP 800-84 gives the range: "Senior-level tabletop exercises typically range from two to four hours, while operational-level tabletop exercises range from two to eight hours". Book a room or video call and block calendars well ahead. Ask participants to bring the plan, their contact lists and their phones. "Who do you call?" always comes up.
Sample Scenario and Injects: Ransomware at a SaaS Company

Here is a compact scenario you can adapt. Each inject is a moment where the plan either answers the question or does not.
| Time in scenario | Inject | Questions for the room |
|---|---|---|
| Monday 06:10 | On-call engineer sees file servers encrypting and a ransom note | Who is paged first? Who declares an incident, and at what severity? |
| Monday 07:30 | Encryption reaches a backup server; customer portal is down | Who can authorize isolating production? Are backups offline and tested? |
| Monday 11:00 | The attacker emails the CEO and threatens to publish customer data | Who talks to the attacker, if anyone? When is counsel engaged? |
| Monday 15:00 | A customer posts about the outage; a reporter calls | Who approves the public statement? What do support agents say? |
| Tuesday 09:00 | Forensics confirms personal data was copied | Which notification clocks have started? Who tracks each one? |
Tailor the clocks to your obligations. A HIPAA business associate, a New York-regulated insurer and a public company each have different deadlines. Our incident response plan guide lists the main notification timelines in one place.
Rotate scenarios each year. Good options include a compromised administrator account at your identity provider and a breach at a critical vendor. Others: an insider exporting customer records before resigning, or a cloud misconfiguration found by a researcher. NIST CSF 2.0's ID.IM-02 explicitly mentions exercises "done in coordination with suppliers and relevant third parties", so at least one scenario a year should involve a key vendor.
Running the Session
Open with ground rules. Remind the room it is a no-fault exercise and that "I don't know" is a useful answer. The facilitator will move the clock forward whether or not every question is settled.
The facilitator's job is to keep pressure on decisions, not to lecture. Three habits make the difference:
- Ask the named role, not the room. "Priya, you are the incident commander. What do you do now?" gets a real answer. "What should we do?" gets a group nod.
- Make people use the actual plan. If the plan says to call a number, ask someone to read the number out. A number that no longer works is exactly the kind of gap the exercise is there to find.
- Do not rescue the room. When nobody knows who can approve taking a system offline, record the gap and move on. The silence is the finding.
The data collector writes down every decision, every hesitation and every point where the plan was silent or wrong. Time stamps help later.
After the Exercise: Hotwash and After-Action Report
The hotwash
End the session with a short debrief while memories are fresh. HSEEP calls it the hotwash: "a meeting that provides an opportunity to discuss exercise strengths and areas for improvement immediately following the conduct of an exercise". It notes that "an experienced facilitator leads the hotwash and ensures the discussion remains constructive". Ask each participant for one thing that worked and one thing that did not.
The after-action report and improvement plan
HSEEP's evaluation output is the After-Action Report/Improvement Plan (AAR/IP), which documents "strengths, areas for improvement, capability performance, and corrective actions". It "generally includes an exercise overview, analysis of capabilities, and a list of corrective actions".
Keep the improvement plan concrete. Each corrective action needs an owner, a due date and a way to verify it is done. "Update the on-call contact list" is weak. "Security lead replaces the on-call list in the plan with a link to the paging system roster by December 15; verified in the next exercise" is strong.
This report is your evidence. When an auditor, an examiner or a customer security questionnaire asks how you test the plan, it should show three things. The exercise happened. The gaps were recorded. The plan changed because of them.
Write the report so one exercise can answer several reviewers. Name the plan version you tested, the scenario, each attendee and the role they played, and every corrective action. The attendance list matters more than it looks: NYDFS 500.16(d) asks for testing "with all staff and management critical to the response," so a report that lists only "the IT team" invites the question of who was missing.
How Often to Run a Tabletop Exercise

NIST's guidance is to run them "periodically; following organizational changes, updates to an IT plan, or the issuance of new TT&E guidance; or as otherwise needed". Where a rule sets a floor, follow it: at least annually under NYDFS 500.16(d) and DORA Article 11(6), and every 12 months under the proposed HIPAA update if it becomes final.
For most organizations, a sensible rhythm is one operational and one executive tabletop a year. Add a short exercise after any major change, such as a new identity provider, an acquisition, a new incident response lead or a real incident. Tabletops do not replace technical testing. Pair them with penetration testing and restore tests, since NYDFS also requires testing the "ability to restore its critical data and information systems from backups".
Common Mistakes
Calling a slide review an exercise. If nobody had to make a decision under uncertainty, it was a briefing.
Mixing executives and responders the first time. NIST recommends separate sessions first. Junior staff stay quiet when the CEO is in the room, and executives drift into technical detail they do not own.
Skipping the after-action report. Without written corrective actions, the same gaps appear next year. The State Department case shows how quickly an annual cycle slips.
Never involving vendors. Your cloud provider, managed security provider and outside counsel are part of your response. CSF 2.0's ID.IM-02, a voluntary outcome, names exercises done with suppliers and third parties.
Overclaiming the regulatory basis. The FTC Safeguards Rule requires a plan and its revision after an event, not exercises. Be accurate when you document why you test.
Bottom Line
A tabletop exercise tests whether your people can make the hard calls your plan assigns them, without touching production. NYDFS and DORA require annual plan testing, HIPAA expects periodic contingency plan testing and has proposed a 12-month incident response test, and NIST CSF 2.0 builds improvement around exercises.
If you have never run one, start small. Take the CISA package closest to your sector. Have someone who did not write the plan facilitate. Build the first inject around a decision you suspect nobody owns, such as who can take the payment system offline. The after-action report from that session, with owners and dates on every fix, is what you show the next person who asks when you last tested the plan.
Frequently Asked Questions
What is a tabletop exercise in cybersecurity?
It is a facilitated, discussion-only session in which incident responders and decision-makers talk through how they would handle a realistic cyber scenario. NIST SP 800-84 says it "does not involve deploying equipment or other resources," so no systems are touched.
How long does a tabletop exercise take?
NIST SP 800-84 says senior-level sessions typically run two to four hours, while operational-level sessions run two to eight hours.
How often should we run a tabletop exercise?
At least once a year if you are subject to NYDFS Part 500 or DORA, both of which require annual plan testing. NIST also recommends an exercise after organizational changes or plan updates.
Is a tabletop exercise required by HIPAA?
HIPAA does not name tabletop exercises. It includes an addressable specification for "periodic testing and revision of contingency plans," and a tabletop is one way to meet it. The January 2025 proposed rule would require incident response plan tests at least every 12 months, but it is not final.
What is the difference between a tabletop exercise and a functional exercise?
A tabletop is discussion-based. A functional exercise has staff perform their duties in a simulated operational environment. CISA's planning timelines reflect the gap: 3 to 4 months for a tabletop, 6 to 12 months for a functional exercise.
Where can I find a tabletop exercise template?
CISA publishes over 100 Tabletop Exercise Packages with scenarios, discussion questions and an after-action report template. NIST SP 800-84 Appendix A has sample facilitator and participant guides and a sample after-action report.
Sources
- NIST, SP 800-84, Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities, September 2006, full text PDF, accessed 2026-11-05
- FEMA, Homeland Security Exercise and Evaluation Program (HSEEP), page updated January 27, 2025, and the HSEEP doctrine, 2020 revision, accessed 2026-11-05
- CISA, Exercise Planning and Conduct Support Services, accessed 2026-11-05
- CISA, CISA Tabletop Exercise Packages, accessed 2026-11-05
- eCFR, 45 CFR 164.308 and 45 CFR 164.306, current as of 2026-11-03, accessed 2026-11-05
- Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, proposed rule, January 6, 2025, accessed 2026-11-05
- New York DFS, 23 NYCRR Part 500, Second Amendment, accessed 2026-11-05
- eCFR, 16 CFR 314.4, current as of 2026-11-03, accessed 2026-11-05
- NIST, The NIST Cybersecurity Framework (CSF) 2.0, February 26, 2024, accessed 2026-11-05
- NIST, SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025, accessed 2026-11-05
- EUR-Lex, Regulation (EU) 2022/2554 (DORA), accessed 2026-11-05
- GAO, GAO-23-107012, Cybersecurity: State Needs to Expeditiously Implement Risk Management and Other Key Practices, September 28, 2023, accessed 2026-11-05
- GAO, GAO-14-354, Agencies Need to Enhance Policies and Practices for Responding to Cyber Incidents, April 2014, accessed 2026-11-05
- HHS, Resolution agreement and corrective action plan, Heritage Valley Health System, accessed 2026-11-05
Last reviewed: 2026-11-05. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.
