Light, practical and human: because practising your incident plan should feel like rehearsal, not punishment.

What is a tabletop exercise (TTX)?

tabletop

A tabletop exercise is a facilitated, discussion-based rehearsal where people talk through a realistic incident scenario: no systems are taken offline, no scripts executed. The exercise focuses on decisions, roles, communications and processes, and helps teams uncover gaps in playbooks and handoffs before a real crisis. See the NIST SP 800-84 guide to tests, training and exercise programs for a formal definition and practical design details.

Why run tabletop exercises?

  • They test people and processes (not only technology): TTXs reveal communication breakdowns, unclear decision owners, and missing procedures that technical tests often miss. Agencies and practical guidance emphasise discussion-based exercises precisely for this reason.
  • They are cost-effective and repeatable: a well-scoped TTX can be run in 90–240 minutes and scaled across teams. Prebuilt packages speed planning. See CISA’s Tabletop Exercise Packages (CTEP) for dozens of ready scenarios and templates.
  • They support regulatory & resilience requirements: for financial entities in the EU, scenario-based testing (including tabletop exercises) forms part of the Digital Operational Resilience Act (DORA) expectations for demonstrating operational resilience. Read the EU overview of DORA / operational resilience for timelines and obligations.

DORA (the EU regulation for financial-sector digital resilience) expects firms to maintain a testing programme covering a range of scenarios, methods and tools. Regularly run and documented TTXs, with clear After Action Reports (AARs) and tracked remediation, are a practical way to show preparedness in audits or regulatory reviews.

For official exercise tools and smaller organisation guidance, the UK’s NCSC “Exercise in a Box” is a good model to adapt.

How to run a TTX: a practical, copy-paste runbook

1) Define clear objectives (30–60 minutes planning)

Pick 1–3 measurable objectives (for example: “validate ransomware playbook and backup restore for service X” or “test vendor failover and external comms”). Objectives drive scope and participants. (Guides such as NIST SP 800-84 describe objective-first planning.)

2) Choose scope & participants

Limit the scope to keep the exercise focused. Typical participants: SOC/IR, IT Ops, Legal, Communications, Business Unit leads, Vendor owners, Compliance, and an executive observer.

3) Design a realistic scenario (2–4 hours prep)

Start with a believable T0 (e.g., unusual outbound traffic, a service error, or a vendor outage) and plan timed injects that add facts: ransom notes, journalist social posts, vendor status updates.

4) Prepare materials & facilitation

Prepare a short scenario brief, facilitator script, inject cards, slide deck, and observer note sheets. CISA provides slide and AAR templates; NIST describes evaluation criteria you can reuse.

5) Run the session (90–240 minutes)

Rules up front: safe space, no blame, focus on learning. Present the scenario, let participants speak decisions aloud, deliver injects, and have observers capture decisions and gaps.

6) Hot-wash and After Action Report (AAR)

Run a 20–30 minute hot-wash immediately after to capture first impressions. Then publish a concise AAR listing findings, impact, root causes, recommendations, owners and target dates. Track remediation in your ticketing system: the AAR is the exercise’s most valuable deliverable.

7) Follow-through and re-test

Convert AAR items into tracked tasks, close them, and validate fixes in a future TTX.

Frameworks & sources to bookmark (adapt these)

Ready-to-use tabletop template (copy / paste)

Title: [Short scenario title]

Objectives:

  • Objective 1 (measurable)
  • Objective 2 (measurable)

Scope:

  • In scope systems/services:
  • Out of scope:
  • Key participants/roles:

Scenario summary (one paragraph):

Start condition (T0):

Agenda / timeline:

  • 0:00 — Welcome & rules (10 min)
  • 0:10 — Scenario brief (10 min)
  • 0:20 — Discussion round 1 (45 min): initial detection & containment decisions
  • 1:05 — Inject 1 (e.g., ransom demand / media mention): discussion (30 min)
  • 1:35 — Break (10 min)
  • 1:45 — Discussion round 2 (45 min): continuity & communications
  • 2:30 — Hot-wash & immediate actions (30 min)
  • 3:00 — End

Example injects:

  • Inject 1: “SOC detects large outbound data transfer to unknown IP.”
  • Inject 2: “Journalist posts about suspected customer data leak.”
  • Inject 3: “Vendor X reports partial outage in the region, failover unavailable for 4 hours.”

Facilitator prompts:

  • Who declares this an incident and who must be notified internally?
  • What containment steps in the first 60 minutes?
  • Who drafts and approves external communications?
  • Do regulators need to be notified? If so, when and by whom?
  • Which third-party dependencies block recovery and who owns them?
AAR fields: Finding Impact Root cause Recommendation Owner Target date Status

(For AAR and documentation templates you can adapt, see CISA’s documentation and the NIST SP 800-84 template examples.)

Quick tips to get leadership buy-in

  • Run a short, executive TTX (60–90 minutes) with one high-level scenario: execs like clarity on decision points and escalation.
  • Treat the TTX as learning; share a short AAR with leadership and keep operational detail with IR teams.
  • Show measurable gains (closed AAR actions, faster decision times) to justify repeated runs. ENISA’s best practices emphasise iterative exercises that build on prior results.