Tabletop Exercise Template (CISA CTEP, HSEEP, NIST SP 800-84)

Tabletop Exercise Package: [Exercise name]

Complete package for a discussion-based cyber incident exercise: exercise overview, objectives and evaluation criteria, participants and roles, ground rules, a scenario delivered in modules with timed injects, discussion questions, facilitator notes, evaluation guidance, hot wash, After Action Report and Improvement Plan. Structure informed by the CISA Tabletop Exercise Packages (CTEP: exercise planner handbook, situation manual, facilitator and evaluator handbook, participant feedback form, After Action Report and Improvement Plan template), the FEMA Homeland Security Exercise and Evaluation Program (HSEEP) doctrine, 2020 revision, and NIST SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities (September 2006). Incident response concepts follow NIST SP 800-61 Rev. 3 (April 2025). Replace every [bracketed] value and every row marked Example. The worked scenario is a ransomware and extortion incident affecting the SaaS platform of Corvid Commerce, a fictional company (Example).

Document control

Approvals

Revision history

Contents

1. Exercise overview
2. Objectives and evaluation criteria
3. Participants and roles
4. Ground rules, assumptions and artificialities
5. Schedule and logistics
6. Scenario and injects
7. Discussion questions
8. Facilitator notes
9. Evaluation guidance
10. Hot wash and participant feedback
11. After Action Report
12. Improvement Plan
13. Traceability matrix
14. Glossary and references

1. Exercise overview

Why this exercise: [Example: Corvid Commerce adopted a new Incident Response Plan and Incident Commander Handbook this year, migrated backups to a new provider, and signed enterprise contracts with 24-hour breach notification clauses. Ransomware is the top-rated scenario in the risk register. The plans have never been exercised with executives.]

Exercise cycle. This package follows the HSEEP exercise cycle: design and development, conduct, evaluation, and improvement planning. Findings feed the organisation's integrated preparedness plan or annual exercise programme so that the next exercise tests whether corrective actions worked.

2. Objectives and evaluation criteria

Rating scale for each objective. The four levels are adapted from the HSEEP performance ratings (Exercise Evaluation Guide and AAR/IP templates). HSEEP writes them for core capabilities and critical tasks and applies them most rigorously in operations-based exercises; using them for discussion-based objectives is common practice but an adaptation, so rate what the discussion showed the plan and decision rights would achieve. Use your organisation's equivalent if it has one:

3. Participants and roles

3.1 Exercise roles

3.2 Players (Example)

3.3 RACI for the exercise

4. Ground rules, assumptions and artificialities

Ground rules:

1. This is a no-fault, open learning environment. The exercise tests plans and processes, not people.
2. Respond based on your knowledge of current plans, capabilities and authority. Say what you would actually do, not what the plan says if you would not follow it.
3. Decisions are not binding and do not commit resources.
4. Raise disagreements; a disagreement found today is cheaper than one found during an incident.
5. Keep side conversations and devices to a minimum; one conversation at a time.
6. Issues outside the scope go to the parking lot and are recorded.
7. Nothing discussed is attributed to individuals in the AAR.
8. Exercise communications start and end with "EXERCISE EXERCISE EXERCISE". No real external contact is made.

Assumptions:

1. The scenario is plausible and events unfold as described; do not fight the scenario.
2. All players have the knowledge and authority of their real role.
3. Current plans, contracts and tooling are as they exist today.
4. [Example: The cyber insurance policy and incident response retainer are in force as currently contracted.]

Artificialities:

1. Time is compressed: one module covers hours or days of incident time.
2. Information arrives through injects rather than tools.
3. The simulation cell plays every outside party.
4. Some technical details are simplified to keep the discussion at decision level.

5. Schedule and logistics

Logistics checklist: room with one table for players and a separate table for evaluators; screen for inject slides; printed situation manual for each player; copies of the plans under test; recording disabled unless legal approves; video bridge with waiting room; secure channel for injects to remote players; name cards with function names; parking lot board; feedback forms ready.

6. Scenario and injects

6.1 Background (Example)

Corvid Commerce provides a multi-tenant SaaS order management platform to about 2,400 retail customers, including 60 enterprise accounts with 24-hour security incident notification clauses. The platform runs in one public cloud region with a warm standby region. Customer data includes order records with names, delivery addresses and email addresses. Card payments are tokenised by a third-party payment provider. Under its data processing agreements (GDPR Art. 28), Corvid is a processor (Art. 4(8)) for its customers' order data, and each retail customer is the controller (Art. 4(7)); Corvid is itself a controller for its own staff and account data. Engineering administrators reach the cloud console through single sign-on. Backups are taken nightly to a separate backup account; the backup account was migrated to a new provider three months ago.

6.2 Module summaries for players

Module 1, detection and escalation (Day 1, 02:00 to 06:00). An alert about a change to cloud audit logging arrives overnight, followed by a partial platform outage that engineers first treat as a storage fault. By early morning customers and social media are asking questions.

Module 2, containment, extortion and notification (Day 1, 07:00 to 12:00). The morning investigation update arrives as the platform outage continues. Outside parties begin to contact the company, and contractual and regulatory obligations come into play.

Module 3, recovery and return to normal (Day 1, 15:00 to Day 4). Leadership turns to restoring service. Updates arrive from the backup team, the investigation and the data protection officer over the following days.

6.3 Inject list

The facilitator releases each inject at the incident time shown, one module at a time.

7. Discussion questions

7.1 Module 1 questions

7.2 Module 2 questions

7.3 Module 3 questions

8. Facilitator notes

8.1 Running the session

1. Open with the purpose and ground rules, then show the first inject without delay; long introductions drain energy.
2. Direct questions to functions, not names ("Legal, what do you need here?").
3. Probe beyond the plan: "Where is that written?", "Who backs you up if you are unavailable?", "How long does that take at 04:00 on a Sunday?"
4. If players solve a problem too easily, use a pre-planned complication (8.4). If they are stuck, offer a hint from the simulation cell instead of the answer.
5. Keep to the timebox per module. Park detailed technical debates.
6. Summarise decisions at the end of each module and confirm the note-taker captured them.

8.2 Master scenario timeline (Example)

The diagram shows the facilitator's master timeline, including attacker actions that players never see directly. Players learn only what the injects in section 6.3 tell them.

8.3 Inject expectations and what good looks like (Example)

8.4 Optional complications

• The incident commander becomes unavailable during Module 2: who takes over?
• The video bridge used for the incident is suspected to be compromised: which out-of-band channel is used?
• The cyber insurer requires use of its panel incident response firm, not the current retainer.

8.5 Parking lot

9. Evaluation guidance

9.1 Evaluator sheet (one per objective)

9.2 Evaluation rules

1. Observe the whole group; do not join the discussion or coach players.
2. Separate what the plan says, what players said they would do, and what would realistically happen.
3. Record root cause categories consistently: plan, policy, training, decision rights, tools, staffing, third party.
4. Meet with the other evaluators straight after the hot wash to reconcile ratings while memories are fresh.
5. Do not rate individuals.

10. Hot wash and participant feedback

10.1 Hot wash prompts

1. What surprised you most?
2. What is one strength we should keep?
3. What is the most important thing to fix before a real incident?
4. Which plan, contact list or decision right was missing or unclear?
5. Which outside party do we depend on most, and have we tested that dependency?

10.2 Participant feedback form

11. After Action Report

11.1 Executive summary (Example)

On YYYY-MM-DD, 14 leaders of Corvid Commerce took part in a 3.5-hour tabletop exercise based on a ransomware and data extortion attack on the production SaaS platform. The exercise tested six objectives across the Incident Response Plan, Incident Commander Handbook, Crisis Communication Plan, Backup Policy and Disaster Recovery Plan.

Major strengths: the SOC escalation path worked as written and the incident commander was named within the expected time; legal and communications produced a consistent holding statement; the team recognised the need to preserve evidence before failover.

Primary areas for improvement: no written position or decision forum exists for extortion demands; the authority to take the whole platform offline is undefined outside business hours; backup restore has not been verified since the provider migration; identity provider logs are kept for only 90 days, which limits scope confidence.

11.2 Exercise summary

11.3 Analysis by objective (Example)

11.4 Conclusion

[Example: The exercise met its purpose of revealing decision gaps before a real incident. Five of six objectives were performed with some or major challenges (two S, three M) and one could not be performed (U). The Improvement Plan assigns 8 corrective actions. A follow-up tabletop focused on extortion decisions and an operations-based restore test are scheduled within six months.]

12. Improvement Plan

Capability elements follow the HSEEP improvement planning practice (POETE): planning (including policies and decision rights), organisation, equipment (including systems), training and exercises. Use them to see whether failures cluster in one element.

Closure criteria: an action closes when the owner provides evidence (approved document version, test report, configuration change) and the exercise director verifies it. Actions that cannot meet their due date need sponsor approval for a new date.

13. Traceability matrix

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Based on the CISA Tabletop Exercise Packages, the FEMA Homeland Security Exercise and Evaluation Program (HSEEP) doctrine (2020 revision), NIST SP 800-84 (September 2006) and NIST SP 800-61 Rev. 3 (April 2025), works of the United States Government not subject to copyright in the United States. The package structure, exercise cycle, rating levels and document names are cited; all explanations, the scenario, injects and questions are original. The scenario and Corvid Commerce are fictional; any resemblance to a real organisation or incident is coincidental. Check the current official versions at cisa.gov, fema.gov and nist.gov before relying on this package, as updated materials may have been published. Original text written for this collection. Template licence: MIT.