# 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*).

<!--
Guidance: How to use this template
- A tabletop exercise tests plans, decisions and coordination through facilitated discussion. Nobody touches production. For technical, operations-based tests of systems and runbooks use the Game Day Plan (`ops/game-day-plan`); for evidence of one disaster recovery test use the DR Test Report (`ops/dr-test-report`).
- Split this file in two before the exercise. Sections 1 to 7 form the situation manual for players and contain no facilitator-only content. Sections 8 and 9 (master scenario timeline, expected discussion per inject, complications, evaluation guidance) go only to facilitators and evaluators. Sections 10 to 13 are completed after the exercise.
- Release inject text to players module by module (slides or the secure channel) at the time of delivery, not in the printed manual handed out at the start, so later modules keep their surprise.
- Start from the objectives (2), not the scenario. A dramatic scenario that does not test an objective wastes senior time.
- Plan four to eight weeks ahead for a first exercise. Book executives early: their absence is the most common reason exercises lose value.
-->

## Document control

<!-- Guidance: Identify the exercise sponsor, the planning team lead and the handling rules. Exercise materials describe weaknesses and must be protected. -->

| Field | Value |
|---|---|
| Document ID | [TTX-YYYY-NN] |
| Version | [0.1] |
| Status | [Draft / Approved for conduct / Conducted / AAR final] |
| Owner (exercise director) | [@security-resilience-lead] |
| Exercise sponsor | [@ciso] |
| Approvers / reviewers | [@cto], [@head-of-legal], [@head-of-communications], [@incident-response-lead] |
| Last updated | YYYY-MM-DD |
| Classification | Confidential. Handling: share with named participants only; facilitator sections restricted to facilitators and evaluators |
| Exercise date and duration | YYYY-MM-DD, [*Example:* 3.5 hours including hot wash] |
| Exercise type | Discussion-based tabletop exercise |
| Plans under test | [*Example:* Incident Response Plan v2.1, Business Continuity Plan v1.4, Crisis Communication Plan v1.0] |
| Related | Incident Response Plan (`compliance/incident-response-plan`), Incident Commander Handbook (`ops/incident-commander-handbook`), Incident Severity Matrix (`ops/incident-severity-matrix`) |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Exercise sponsor | [@name] | [Approved / Changes requested] | YYYY-MM-DD |
| Exercise director | [@name] | [Decision] | YYYY-MM-DD |
| Legal counsel (privilege and handling) | [@name] | [Decision] | YYYY-MM-DD |
| AAR approval (after conduct) | [@name] | [Decision] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record design changes before conduct and the AAR versions after conduct. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Objectives and scope agreed with sponsor |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Scenario modules and injects drafted; legal review of handling |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for conduct |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* After Action Report and Improvement Plan added |

## Contents

<!-- Guidance: Keep aligned with the headings. Remove sections 8 and 9 from the player copy. -->

1. [Exercise overview](#1-exercise-overview)
2. [Objectives and evaluation criteria](#2-objectives-and-evaluation-criteria)
3. [Participants and roles](#3-participants-and-roles)
4. [Ground rules, assumptions and artificialities](#4-ground-rules-assumptions-and-artificialities)
5. [Schedule and logistics](#5-schedule-and-logistics)
6. [Scenario and injects](#6-scenario-and-injects)
7. [Discussion questions](#7-discussion-questions)
8. [Facilitator notes](#8-facilitator-notes)
9. [Evaluation guidance](#9-evaluation-guidance)
10. [Hot wash and participant feedback](#10-hot-wash-and-participant-feedback)
11. [After Action Report](#11-after-action-report)
12. [Improvement Plan](#12-improvement-plan)
13. [Traceability matrix](#13-traceability-matrix)
14. [Glossary and references](#14-glossary-and-references)

## 1. Exercise overview

<!-- Guidance: One page that tells a busy executive what, why, who and when. Players read this first. -->

| Item | Value |
|---|---|
| Exercise name | [*Example:* Corvid Commerce TTX "Locked Ledger"] |
| Exercise type | Discussion-based tabletop, facilitated, in person with remote dial-in |
| Scope | [*Example:* Detection, escalation, containment decisions, customer and regulatory communication, recovery prioritisation and extortion decision for the production SaaS platform] |
| Out of scope | [*Example:* Hands-on technical recovery, physical security, payroll systems] |
| Threat or hazard | [*Example:* Ransomware with data theft and extortion (double extortion)] |
| Plans and procedures tested | [*Example:* Incident Response Plan, Incident Commander Handbook, Crisis Communication Plan, Backup Policy, Disaster Recovery Plan, customer contract notification clauses] |
| Sponsor | [@ciso] |
| Exercise director | [@name] |
| Lead facilitator | [@name] |
| Location | [Room], [video bridge link], [secure chat channel for injects] |
| Point of contact | [@name], [contact] |

**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.

```mermaid
flowchart LR
  A[Design and development<br/>objectives, scenario, injects] --> B[Conduct<br/>facilitated discussion]
  B --> C[Evaluation<br/>hot wash, evaluator notes, feedback forms]
  C --> D[Improvement planning<br/>AAR and Improvement Plan]
  D --> E[Track corrective actions]
  E --> A
```

## 2. Objectives and evaluation criteria

<!-- Guidance: Write three to six SMART objectives (specific, measurable, achievable, relevant, time-bound). Each objective needs evaluation criteria that an evaluator can observe during discussion. Pitfall: objectives such as "test the IR plan" that cannot be scored. -->

| Objective ID | Objective | Capability or plan section | CSF 2.0 Function | Evaluation criteria (observable) |
|---|---|---|---|---|
| OBJ-01 *(Example)* | Assess the ability to classify the incident and activate the incident command structure within the time set by the Incident Response Plan | IR Plan section 1, IC Handbook | Respond | Participants assign a severity level (SEV1 to SEV4) using the Incident Severity Matrix (`ops/incident-severity-matrix`); an incident commander is named; the activation decision is reached by inject 1.3 |
| OBJ-02 *(Example)* | Evaluate containment decisions that trade service availability against further spread, including who has authority to take the platform offline | IR Plan containment, IC Handbook decision rights | Respond | Decision owner identified; criteria for isolation stated; business impact considered; decision logged with time |
| OBJ-03 *(Example)* | Validate the process for regulatory, customer and law enforcement notification, including the 24-hour contract clause and the GDPR duties Corvid holds as processor and as controller | Crisis Communication Plan, contracts register, data processing agreements | Respond, Govern | Clock start time agreed; processor notification to customers (controllers) without undue delay under GDPR Art. 33(2) planned, plus any controller duties for Corvid's own data; owner for each notification named; draft holding statement approved by legal and communications |
| OBJ-04 *(Example)* | Examine recovery prioritisation using RTO and RPO targets and the integrity of backups | DR Plan, Backup Policy | Recover | Recovery order agreed; backup integrity verification step named; dependency on identity provider recognised |
| OBJ-05 *(Example)* | Clarify the decision process for an extortion demand, including legal, sanctions and insurance consultation | IR Plan extortion annex | Govern, Respond | Decision forum named; parties to consult listed; policy position stated or gap recorded |
| OBJ-06 *(Example)* | Identify whether available logs can answer key investigation questions within the retention window | Security Logging Standard | Detect | Participants identify which logs answer scope questions; retention gaps recorded |

**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:

| Rating | Meaning (paraphrased from HSEEP) |
|---|---|
| P: Performed without challenges | Objective achieved; no negative impact on other activities; no added health, safety or business risk; done in line with applicable plans, policies, procedures, regulations and laws |
| S: Performed with some challenges | As P, but opportunities to improve effectiveness or efficiency were identified |
| M: Performed with major challenges | Objective achieved, but with a negative impact on other activities, added risk, or a departure from plans, policies, procedures, regulations or laws |
| U: Unable to be performed | Objective not achieved; the plan, decision right or capability did not exist or did not work |

## 3. Participants and roles

<!-- Guidance: Invite the people who would really decide. Delegates who cannot commit their function produce a polite but useless exercise. Incident roles themselves are defined in the Incident Commander Handbook (`ops/incident-commander-handbook`); do not redefine them here. -->

### 3.1 Exercise roles

| Role | Who | Responsibilities |
|---|---|---|
| Exercise director | [@name] | Owns design, approves materials, accountable for AAR |
| Lead facilitator | [@name] | Runs the discussion, delivers injects, keeps time, protects the no-fault environment |
| Co-facilitator / simulation cell | [@name] | Plays outside parties (customers, regulator, press, attacker, insurer, cloud provider) and answers requests for information |
| Evaluators | [@name], [@name] | Observe against objectives using section 9, do not take part in discussion |
| Note-taker | [@name] | Records decisions, times, open questions and parking lot items |
| Players | Listed in 3.2 | Respond as they would in a real incident, using real plans |
| Observers | [@name] | Watch only; may contribute in the hot wash if invited |
| Safety and trusted agent | [@name] | Knows the scenario in advance, ensures the exercise cannot be mistaken for a real incident |

### 3.2 Players (*Example*)

| Function | Player | Real-incident role per IC Handbook |
|---|---|---|
| Executive | Chief executive officer | Executive sponsor, approves extortion and public statements |
| Security | CISO | Incident commander for security incidents |
| Security | Deputy CISO | Deputy incident commander |
| Corporate IT | Head of IT | Identity provider and corporate devices |
| Engineering | VP engineering, platform lead | Operations lead, technical decisions |
| Security operations | SOC manager | Investigation lead |
| Legal | General counsel | Legal lead, privilege, regulators, law enforcement |
| Privacy | Data protection officer | Personal data breach assessment |
| Communications | Head of communications | Communications lead |
| Customer success | VP customer success | Customer liaison for enterprise accounts |
| Customer support | Customer support lead | Support desk messaging and ticket triage |
| Finance | CFO | Insurance, payments, cost authority |
| People | Head of people | Staff communications, welfare |

### 3.3 RACI for the exercise

| Activity | Exercise director | Lead facilitator | Evaluators | Note-taker | Sponsor |
|---|---|---|---|---|---|
| Approve objectives and scope | R | C | C | I | A |
| Build scenario and injects | A | R | C | I | I |
| Conduct the exercise | A | R | I | R | I |
| Evaluate against objectives | A | C | R | C | I |
| Draft AAR and Improvement Plan | A, R | C | R | C | I |
| Approve AAR and fund actions | C | I | I | I | A |

## 4. Ground rules, assumptions and artificialities

<!-- Guidance: Read these aloud at the start. They create the no-fault environment that lets people admit gaps. -->

**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

<!-- Guidance: Keep a tabletop to half a day. Protect at least 30 minutes for the hot wash: it is where most findings appear. -->

| Time (*Example*) | Activity | Lead |
|---|---|---|
| 09:00 | Arrival, sign-in, dial-in check | Note-taker |
| 09:10 | Welcome, sponsor opening, purpose | Sponsor |
| 09:20 | Ground rules, roles, objectives, how injects work | Lead facilitator |
| 09:30 | Module 1: Detection and escalation | Lead facilitator |
| 10:15 | Module 2: Containment, extortion and notification | Lead facilitator |
| 11:05 | Break | |
| 11:15 | Module 3: Recovery, communications and return to normal | Lead facilitator |
| 12:00 | Hot wash | Lead facilitator, evaluators |
| 12:30 | Close, feedback forms | Exercise director |

**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

<!-- Guidance: Build the scenario backwards from the objectives. Every inject must trigger a decision that an objective measures. Use realistic but fictional names, addresses and indicators: never real customer names or live indicators of compromise. -->

### 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.

| Inject ID | Module | Incident time | Delivered by | Inject content |
|---|---|---|---|---|
| INJ-1.1 *(Example)* | 1 | Day 1, 02:15 | SOC alert slide | The SIEM raises a high alert: the organisation audit trail in the production account was modified by an engineer's identity. The on-call SOC analyst cannot reach the engineer. |
| INJ-1.2 *(Example)* | 1 | Day 1, 04:50 | Monitoring slide | Database health checks fail for 40 percent of tenants. Engineering on-call suspects a storage fault and starts a failover. |
| INJ-1.3 *(Example)* | 1 | Day 1, 06:00 | Support lead email | 300 support tickets in one hour; two enterprise customers ask whether this is a breach. Social media posts mention the outage. |
| INJ-2.1 *(Example)* | 2 | Day 1, 07:30 | Investigation update | Snapshots in the production account were deleted. Volumes contain encrypted files and a ransom note. The attacker created a new access key at 22:55 on Day 0. |
| INJ-2.2 *(Example)* | 2 | Day 1, 09:00 | Email to CEO and press address | Extortion note: the group claims to hold 1.2 million customer order records, attaches a sample of 50 records, demands payment within 72 hours, threatens to publish and contact customers. |
| INJ-2.3 *(Example)* | 2 | Day 1, 10:00 | Simulation cell as enterprise customer | The largest enterprise customer cites its 24-hour notification clause and asks for a written statement and indicators of compromise. |
| INJ-2.4 *(Example)* | 2 | Day 1, 11:00 | Simulation cell as journalist | A trade journalist asks for comment before publishing at 14:00. |
| INJ-3.1 *(Example)* | 3 | Day 1, 15:00 | Backup team update | Backups in the new backup account are intact, but the latest verified restore test was before the provider migration. A full restore is estimated at 30 hours. |
| INJ-3.2 *(Example)* | 3 | Day 2, 09:00 | Investigation update | The stolen token came from an infostealer on an engineer's personal laptop used for SSO. Identity logs older than 90 days are not available from the SaaS identity provider. |
| INJ-3.3 *(Example)* | 3 | Day 3, 10:00 | Data protection officer | Sample records confirm personal data was taken. Customers in the EU are affected. |
| INJ-3.4 *(Example)* | 3 | Day 4, 18:00 | Engineering lead | Platform restored for 95 percent of tenants. Five tenants have data gaps of 20 hours. |

## 7. Discussion questions

<!-- Guidance: Prepare more questions than you will use and mark the priority ones. Ask open questions ("walk us through") rather than yes or no questions. -->

### 7.1 Module 1 questions

| Question ID | Question | Priority | Objective |
|---|---|---|---|
| Q-1.01 | Who receives the 02:15 alert, and what do they do in the first 15 minutes? | High | OBJ-01 |
| Q-1.02 | At what point does this become a security incident, and who decides? | High | OBJ-01 |
| Q-1.03 | Should the engineering failover in INJ-1.2 proceed before security has assessed the alert? What could it destroy or spread? | High | OBJ-02 |
| Q-1.04 | What severity applies under the Incident Severity Matrix, and what does that trigger? | High | OBJ-01 |
| Q-1.05 | Which logs tell you what the engineer's identity did since yesterday evening, and how quickly can the SOC query them? | Medium | OBJ-06 |
| Q-1.06 | What do support agents tell customers at 06:00? | Medium | OBJ-03 |

### 7.2 Module 2 questions

| Question ID | Question | Priority | Objective |
|---|---|---|---|
| Q-2.01 | What containment options exist, and what is the business impact of each? Who has authority to take the whole platform offline? | High | OBJ-02 |
| Q-2.02 | Which outside parties do you call now: incident response retainer, cyber insurer, law enforcement, cloud provider? Who calls them? | High | OBJ-05 |
| Q-2.03 | What is the organisation's position on paying an extortion demand? Who makes the decision and with what advice? | High | OBJ-05 |
| Q-2.04 | When did each notification clock start (contract, GDPR duties as processor and as controller, other regulators), and who owns each notification? | High | OBJ-03 |
| Q-2.05 | What can you share with the enterprise customer now, and under which handling marking? | Medium | OBJ-03 |
| Q-2.06 | How do you keep the customer, regulator and press messages consistent? | Medium | OBJ-03 |
| Q-2.07 | How are decisions and their times recorded, and is that record protected by legal privilege where applicable? | Low | OBJ-02 |

### 7.3 Module 3 questions

| Question ID | Question | Priority | Objective |
|---|---|---|---|
| Q-3.01 | In which order do you restore tenants and services, and who approves it? | High | OBJ-04 |
| Q-3.02 | How do you confirm backups are clean and complete before restoring? | High | OBJ-04 |
| Q-3.03 | How confident are you in the scope of the compromise given the 90-day log limit? What would raise confidence? | High | OBJ-06 |
| Q-3.04 | What do you tell the five tenants with data gaps, and what remedy do you offer? | Medium | OBJ-04 |
| Q-3.05 | What criteria end the incident, and what follow-up does the postmortem cover? | Medium | OBJ-04 |
| Q-3.06 | How are staff supported after several days of incident work? | Low | OBJ-04 |

## 8. Facilitator notes

<!-- Guidance: Restricted to facilitators and evaluators. Record what good looks like for each inject so the facilitator can probe without leading. -->

### 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.

```mermaid
sequenceDiagram
  participant A as Threat actor
  participant P as Corvid platform
  participant S as SOC
  participant L as Leadership
  A->>P: Uses stolen engineer session token (Day 0, 22:40)
  A->>P: Creates access key, disables some audit trails
  S->>S: Alert on audit trail change (Day 1, 02:15)
  A->>P: Deletes snapshots, encrypts database volumes (Day 1, 04:30)
  P-->>L: Customer outage, support tickets surge (Day 1, 06:00)
  A-->>L: Extortion note with sample of stolen data (Day 1, 09:00)
  L->>L: Containment, notification and extortion decisions
  L->>P: Recovery from backups in standby region (Day 2 to Day 4)
```

### 8.3 Inject expectations and what good looks like (*Example*)

| Inject | Objective | Expected decision or discussion | Indicators of a strong response | Common gaps to probe |
|---|---|---|---|---|
| INJ-1.1 | OBJ-01, OBJ-06 | Who is paged; initial triage; is this a security incident | SOC escalates to the security on-call; the engineer's sessions are revoked or monitored; the alert is treated as possible credential misuse | No authority for the SOC to disable an engineer at night; no backup contact |
| INJ-1.2 | OBJ-01, OBJ-02 | Is the outage linked to the alert; should failover proceed before security assessment | Failover is paused or coordinated with security; evidence such as volume snapshots is preserved | Engineering and security run separate incidents with separate channels |
| INJ-1.3 | OBJ-01, OBJ-03 | Severity classification (SEV1 under the Incident Severity Matrix: core journey unavailable for many customers); incident commander named; first holding statement | SEV1 set by the matrix; incident commander named; holding statement drafted | No customer-facing message owner during the night |
| INJ-2.1 | OBJ-02 | Containment options: revoke keys, isolate account, take platform fully offline; authority to decide | Containment options listed with impact; decision owner clear; isolation of the compromised account considered | Platform shutdown authority unclear; break-glass access untested |
| INJ-2.2 | OBJ-03, OBJ-05 | Extortion decision forum; legal, sanctions, insurer, law enforcement consultation; data breach assessment | Extortion forum convened; insurer, counsel, law enforcement contacted; sanctions screening raised; no commitment made under time pressure; the 50-record sample is treated as making a personal data breach likely | No written position; CEO decides alone; nobody starts the breach assessment until Day 3 |
| INJ-2.3 | OBJ-03 | When did the clock start; who approves the statement; what can be shared under TLP | Clock start defined from contract wording; legal and communications approve the statement; indicators shared with an appropriate TLP marking | Contract clauses not known; nobody owns the contracts register |
| INJ-2.4 | OBJ-03 | Public statement owner and content; alignment with customer and regulator messages | One statement owner; public statement consistent with customer messages; no speculation on attribution or data volume | Communications answers before legal review; journalist learns more than customers |
| INJ-3.1 | OBJ-04 | Recovery order by tenant and service; integrity checks before restore; communications on timeline | Restore tested on a sample before full restore; malware scan of restored data; priority by customer impact and dependencies | Restore order by loudest customer; identity provider dependency forgotten |
| INJ-3.2 | OBJ-06 | Scope confidence; logging and device policy gaps; reset scope | Scope stated with confidence level; logging gap recorded as a finding | Assumption that the attacker only used one access path |
| INJ-3.3 | OBJ-03 | Notify affected customers as controllers without undue delay with the Art. 33(3) information available; support their 72-hour notifications to supervisory authorities; assess whether Corvid is controller for any data (for example its own staff or account data) and notify its own lead authority if so | Processor notification to controller customers sent without undue delay with available Art. 33(3) details, information supplied in phases; customers supported for their own 72-hour notifications; Corvid's own controller data assessed separately; content checklist used | Corvid tries to notify the supervisory authority on customers' behalf without instruction; confusion between processor and controller duties; probe: awareness arguably began at INJ-2.2 (Day 1, 09:00), not Day 3 |
| INJ-3.4 | OBJ-04 | Criteria to declare recovery; communication to affected tenants; when to stand down | Recovery criteria stated (integrity checks, monitoring for re-entry, customer confirmation); affected tenants contacted directly; stand-down and postmortem owner named | Recovery declared on service availability alone; five tenants learn of gaps from their own users |

### 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

| Item ID | Topic | Raised by function | Owner for follow-up |
|---|---|---|---|
| PL-01 *(Example)* | Personal laptops used for SSO by contractors | Security | [@identity-lead] |
| PL-02 *(Example)* | Extortion policy needs board input | Executive | [@general-counsel] |

## 9. Evaluation guidance

<!-- Guidance: Give evaluators a structured sheet per objective (an Exercise Evaluation Guide in HSEEP terms). Evaluators record observations with times, not opinions. -->

### 9.1 Evaluator sheet (one per objective)

| Field | Content |
|---|---|
| Objective | OBJ-NN and text |
| Evaluation criteria | Copied from section 2 |
| Observations | Time-stamped notes of what was said and decided, by function |
| Strengths | What worked and should be kept |
| Areas for improvement | What did not work, with the root cause where visible (plan, training, authority, tooling, resourcing) |
| Rating | P, S, M or U (section 2) |
| Evidence | Inject IDs, question IDs, decision log entries |

### 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

<!-- Guidance: Hold the hot wash immediately after the last module. Ask each function for one strength and one improvement before opening the floor, so quiet voices are heard. -->

### 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

| Question | Answer |
|---|---|
| Your function | [Function] |
| The exercise objectives were clear (1 strongly disagree to 5 strongly agree) | [1 to 5] |
| The scenario was realistic for our organisation (1 to 5) | [1 to 5] |
| I understand my role in a real incident better after this exercise (1 to 5) | [1 to 5] |
| The three most important issues to address | [Free text] |
| Actions you or your team will take | [Free text] |
| How could the exercise design and conduct improve? | [Free text] |

## 11. After Action Report

<!-- Guidance: Draft within two weeks while memories are fresh and approve within the period your programme sets (HSEEP practice commonly cites 90 days for the final AAR/IP). Write for the sponsor: lead with the three to five findings that matter. -->

### 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

| Item | Value |
|---|---|
| Date, duration, location | YYYY-MM-DD, 3.5 hours, [location] |
| Scenario | Ransomware with data theft and extortion against the SaaS platform |
| Participants | [*Example:* 14 players, 3 evaluators, 2 facilitators, 2 observers] |
| Plans tested | [List] |
| Feedback forms returned | [*Example:* 13 of 14] |
| Average score, "scenario realistic" | [*Example:* 4.4 of 5] |

### 11.3 Analysis by objective (*Example*)

| Objective | Rating | Strengths | Areas for improvement | Root cause |
|---|---|---|---|---|
| OBJ-01 | S | Alert escalated within 10 minutes; severity set by matrix | Engineering on-call opened a separate incident channel | Two paging policies; no shared incident channel rule |
| OBJ-02 | M | Containment options well understood | No named authority to take the platform offline at night | Decision rights missing from IC Handbook |
| OBJ-03 | S | Holding statement approved quickly; processor duty to inform controller customers understood | Contract notification clauses not known to responders | Contracts register not linked to IR Plan |
| OBJ-04 | M | Recovery order discussion considered dependencies | Restore not tested since migration; identity provider dependency missed at first | Backup Policy test cadence not enforced |
| OBJ-05 | U | Players knew to involve counsel and insurer | No policy, no decision forum, no sanctions screening step | Extortion annex never written |
| OBJ-06 | M | SOC identified the right log sources | Identity logs kept 90 days only; personal device telemetry absent | Logging standard not applied to SaaS identity provider |

### 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

<!-- Guidance: Every area for improvement gets an action with a single owner and a date. Track actions to closure in the same system as other risk actions, and test them in the next exercise. -->

| Action ID | Objective | Issue | Corrective action | Capability element | Owner | Start | Due | Status |
|---|---|---|---|---|---|---|---|---|
| IP-01 *(Example)* | OBJ-05 | No extortion policy or forum | Write extortion annex to IR Plan, with board-approved position, forum and consultation list (counsel, insurer, sanctions screening, law enforcement) | Planning | [@general-counsel] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-02 *(Example)* | OBJ-02 | Platform shutdown authority undefined at night | Add decision rights table and deputies to the Incident Commander Handbook | Planning, organisation | [@ciso] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-03 *(Example)* | OBJ-04 | Restore untested since migration | Run a full restore test and record it in a DR Test Report (`ops/dr-test-report`) | Equipment, exercises | [@platform-lead] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-04 *(Example)* | OBJ-06 | Identity logs kept 90 days | Forward identity provider audit logs to the SIEM and apply the retention schedule in the Security Logging Standard (`security/security-logging-standard`) | Equipment, planning | [@secops-lead] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-05 *(Example)* | OBJ-03 | Contract clauses unknown | Link the contracts register notification clauses to the IR Plan communications section | Planning | [@legal-ops] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-06 *(Example)* | OBJ-01 | Separate engineering and security incidents | Single incident channel rule in the IC Handbook and alerting policy | Planning, training | [@sre-lead] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-07 *(Example)* | OBJ-06 | Personal devices used for SSO | Enforce managed-device conditional access for administrators | Planning, equipment | [@identity-lead] | YYYY-MM-DD | YYYY-MM-DD | Open |
| IP-08 *(Example)* | All | Executive familiarity | Schedule a follow-up executive tabletop on extortion decisions | Exercises | [@exercise-director] | YYYY-MM-DD | YYYY-MM-DD | Open |

**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

<!-- Guidance: Show that every objective was exercised by at least one inject and question, and that every finding leads to an action. Gaps in this matrix are design flaws. -->

| Objective | Injects | Questions | Finding (AAR 11.3) | Improvement action |
|---|---|---|---|---|
| OBJ-01 *(Example)* | INJ-1.1, INJ-1.2, INJ-1.3 | Q-1.01, Q-1.02, Q-1.04 | Separate incident channels | IP-06 |
| OBJ-02 *(Example)* | INJ-1.2, INJ-2.1 | Q-1.03, Q-2.01, Q-2.07 | Shutdown authority undefined | IP-02 |
| OBJ-03 *(Example)* | INJ-1.3, INJ-2.2, INJ-2.3, INJ-2.4, INJ-3.3 | Q-1.06, Q-2.04, Q-2.05, Q-2.06 | Contract clauses unknown | IP-05 |
| OBJ-04 *(Example)* | INJ-3.1, INJ-3.4 | Q-3.01, Q-3.02, Q-3.04, Q-3.05, Q-3.06 | Restore untested | IP-03 |
| OBJ-05 *(Example)* | INJ-2.2 | Q-2.02, Q-2.03 | No extortion policy | IP-01, IP-08 |
| OBJ-06 *(Example)* | INJ-1.1, INJ-3.2 | Q-1.05, Q-3.03 | Identity log retention, personal devices | IP-04, IP-07 |

## 14. Glossary and references

<!-- Guidance: Keep definitions short and use the terms consistently in the AAR. -->

### 14.1 Glossary

| Term | Definition |
|---|---|
| Tabletop exercise (TTX) | Discussion-based exercise in which participants talk through their response to a scenario |
| Discussion-based exercise | Exercise focused on plans, policies and decisions, such as seminars, workshops, tabletop exercises and games |
| Operations-based exercise | Exercise in which people and systems act, such as drills, functional and full-scale exercises; in this library see the Game Day Plan (`ops/game-day-plan`) |
| Inject | Scenario information delivered during the exercise to prompt discussion or decisions |
| Module | Time-bounded segment of the scenario with its own injects and questions |
| Situation manual (SitMan) | Player handbook with the scenario, objectives, ground rules and questions |
| Simulation cell | Facilitators who play outside parties |
| Hot wash | Facilitated discussion immediately after the exercise to capture strengths and improvements |
| After Action Report (AAR) | Report of exercise results by objective |
| Improvement Plan (IP) | Corrective actions with owners and dates arising from the AAR |
| Controller and processor (GDPR) | The controller decides why and how personal data is processed (Art. 4(7)); the processor processes it on the controller's behalf (Art. 4(8)) and must inform the controller of a breach without undue delay (Art. 33(2)) |
| Trusted agent | Planning team member who knows the scenario and keeps it confidential from players |

### 14.2 References

| Reference | Use |
|---|---|
| CISA, *CISA Tabletop Exercise Packages* (cisa.gov/resources-tools/services/cisa-tabletop-exercise-packages) | Package structure: exercise planner handbook, situation manual, facilitator and evaluator handbook, feedback form, AAR/IP template |
| FEMA, *Homeland Security Exercise and Evaluation Program (HSEEP)* doctrine, 2020 revision (fema.gov/emergency-managers/national-preparedness/exercises/hseep) | Exercise cycle, discussion-based types, evaluation, AAR/IP, rating scale |
| NIST SP 800-84, *Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities*, September 2006 (csrc.nist.gov/pubs/sp/800/84/final) | Tabletop design, conduct and evaluation for IT plans |
| NIST SP 800-61 Rev. 3, *Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile*, April 2025 (csrc.nist.gov/pubs/sp/800/61/r3/final) | Incident response concepts and CSF 2.0 Functions in objectives |
| Incident Response Plan (`compliance/incident-response-plan`) | Plan under test |
| Incident Commander Handbook (`ops/incident-commander-handbook`) | Incident roles and decision rights |
| Incident Severity Matrix (`ops/incident-severity-matrix`) | Severity classification used in Module 1 |
| Business Continuity Plan (`compliance/business-continuity`) | Continuity arrangements under test |
| Game Day Plan (`ops/game-day-plan`) | Operations-based technical exercises |
| DR Test Report (`ops/dr-test-report`) | Evidence of restore tests arising from actions |
| Postmortem (`dev/postmortem`) | Format for real incidents, not exercises |
| SOC Playbook (`security/soc-playbook`) | Technical response steps referenced by the SOC |

## 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.