Tabletop Exercise Guide

Most incident response plans are first tested by a real incident, which is the most expensive way to learn that the contact list is stale, the break-glass account does not work and nobody knows who can authorise taking the identity provider offline. A tabletop exercise is a facilitated, discussion-based walk through a realistic scenario that exposes those gaps for the cost of a few hours of senior time. This guide covers exercise formats, objectives, roles, scenario and inject design, executive and technical sessions, and turning the outcome into a tracked improvement plan using the HSEEP model, with a sample identity compromise scenario. It is written for security, resilience and risk leads who own an exercise programme, and for facilitators running their first sessions.

Key takeaways

• Exercise a plan, do not write one. The NCSC is explicit that exercising should not be used to create response plans; draft the plan first, then use the tabletop to find where it breaks.
• Objectives drive everything. Write three to five SMART objectives before the scenario and design every inject to test one of them; a dramatic scenario without objectives produces a discussion, not evidence.
• Run executives and technicians separately. Executives decide on shutdown, payment, disclosure and communications; technical teams work through containment and recovery. Mixing them wastes both groups' time.
• Put identity at the centre of at least one scenario a year. Many serious intrusions use valid accounts, so test what happens when the identity provider, privileged accounts or help desk are compromised, including whether break-glass access really works.
• The after-action report is the product. Every finding needs an owner, a date and a SMART corrective action tracked to closure, and the next exercise should test whether the fixes worked.

What a tabletop exercise is and where it fits

FEMA's Homeland Security Exercise and Evaluation Program (HSEEP) doctrine, revised in 2020, defines a tabletop exercise (TTX) as "a discussion-based exercise in response to a scenario, intended to generate a dialogue of various issues". NIST SP 800-84 adds that a tabletop "is discussion-based only and does not involve deploying equipment or other resources". HSEEP separates discussion-based from operations-based exercises, and a progressive planning approach that moves between them is one of its six principles.

A tabletop is cheap and low-risk, but it cannot prove recovery times: a group agreeing that backups would restore in six hours is not evidence that they do, so pair tabletops with drills for anything measurable. For validating controls rather than people, see the Breach and Attack Simulation (BAS) Guide.

Objectives, scope and planning

• Start from risk: the NCSC recommends a risk analysis to identify the most critical parts of the business, then choosing scenarios by impact and likelihood. The business impact analysis is the input. See the Business Continuity and Disaster Recovery Guide.
• Write SMART objectives: "Confirm who has authority to disconnect the corporate network from the internet, and the criteria for doing so" is testable; "improve ransomware readiness" is not.
• Name the plans under test: incident response plan, crisis communications plan, ransomware playbook, BCDR plan and relevant supplier contracts, circulated as read-ahead.
• Scale HSEEP's planning meetings: HSEEP uses Concept and Objectives, Initial, Midterm and Final Planning Meetings. For a single tabletop, a kick-off, a scenario review and a final walkthrough usually suffice.
• Keep the planning team trusted: the NCSC suggests a temporary development team from across the business. Anyone who knows the scenario cannot also play, so brief their deputies to attend.

Roles in the room

The NCSC advises including external stakeholders, such as contractors and third parties, that you would call on during an incident. Invite your managed security provider, incident response retainer and key SaaS contacts to at least one exercise a year. See the Incident Response Guide for CSIRT roles and retainers.

Executive and technical sessions

Run the technical tabletop first so its findings shape the executive session a few weeks later, and the board hears realistic timings rather than assumptions. For ransomware decision thresholds, see the Ransomware Response and Recovery Guide.

Scenario design

Build scenarios from your own architecture, suppliers and threat intelligence. NIST SP 800-84 advises keeping tabletop scenarios short and concise; the detail belongs in injects. CISA's Tabletop Exercise Packages (CTEPs), of which there are "over 100", and the NCSC's free Exercise in a Box provide starting material covering ransomware, insider threat, phishing, supply chain and industrial control systems.

The AI scenario is no longer speculative: CISA's Joint Cyber Defense Collaborative ran a four-hour tabletop with "more than 50 AI experts" that "simulated a cybersecurity incident involving an AI-enabled system". See the AI Agent Observability and Incident Response Guide, the Insider Threat Programme Guide and the Third-Party Access Guide.

Injects and the MSEL

Injects are the information participants receive as the scenario develops. The NCSC's guidance is to "be clear what each inject is designed to do, and the expected actions it will prompt", and to start every exercise message with "EXERCISE-EXERCISE-EXERCISE" so it cannot be mistaken for a real event. HSEEP calls the full timeline a Master Scenario Events List (MSEL): "a chronological timeline of expected actions and scripted events". A tabletop MSEL can be a spreadsheet with these columns:

• Number and scenario time: for example 2.3, T+6h.
• Simulated sender and channel: SOC alert, service desk ticket, supplier email, journalist's call.
• Content: the exact text, screenshot or log extract handed over, and the intended recipient.
• Objective and expected action: what a good response looks like, so the evaluator can score it.
• Facilitator prompts and contingency inject: questions for when discussion stalls, and an alternative if players resolve the problem too fast.

Plan three to five injects per module and three or four modules for a half-day. Mix an expected alert, an ambiguous signal, a business pressure (a sales director demanding systems back) and a complication (the key holder is on a flight).

Sample scenario outline: identity compromise to extortion

This outline suits a three to four hour technical tabletop followed by a shorter executive version. It is defensive and contains no attack procedures.

1. Module 1, T+0 (Monday 08:30): the reset. Inject 1.1: the service desk reset the password and MFA registration for a cloud administrator on Friday evening after a call from someone who knew the manager's name and the staff number. Inject 1.2: identity threat detection flags a new authentication method and sign-ins from an unfamiliar hosting provider. Inject 1.3: the real administrator says they never called. Questions: who can disable a privileged account, on whose authority, and who is told?
2. Module 2, T+3h: control of the identity plane. Inject 2.1: audit logs show a modified Conditional Access policy and a new application registration with directory permissions. Inject 2.2: two other admin accounts show password changes. Inject 2.3: the team cannot tell which admins are trustworthy and proposes emergency access. Questions: who holds the break-glass credentials and hardware keys, when were they last tested, and who receives the alert? What breaks if all sessions are revoked tenant-wide?
3. Module 3, T+26h: impact. Inject 3.1: the device management console issues wipe commands, or file shares show encryption. Inject 3.2: a message claims data theft and sets a deadline. Inject 3.3: a journalist calls. Questions: what is isolated first, how do staff communicate if email and chat are distrusted, and which notification clocks have started (for example the 72 hours in GDPR Article 33)?
4. Module 4, T+72h: recovery. Inject 4.1: the IT director asks for a restoration order. Inject 4.2: a key customer demands assurance before reconnecting. Inject 4.3: service accounts, API keys and federation certificates were readable by the attacker. Questions: in what order are the identity tier and applications rebuilt, and who owns rotation of each non-human credential?

The pattern mirrors real events: the MGM Resorts breach began with a help desk call that led to Okta admin access, and in the Stryker cyberattack a hijacked admin account used Microsoft Intune to wipe devices. For the response steps, see the ITDR Guide and the Account Recovery and Help Desk Security Guide.

Where identity fits

• Break-glass access as a live drill: pair the tabletop with a real sign-in using the emergency access account. Microsoft's Entra ID guidance is to "validate account functionality at least every 90 days", to test regularly (for example quarterly) that the accounts can sign in under the current Conditional Access configuration, and to alert on every use. If that alert does not reach the SOC within minutes, it is a finding. See the Break-Glass Account Guide.
• Distrusted identity provider: ask what still works if single sign-on is unavailable or untrusted: out-of-band communications, offline copies of the plan and contacts, privileged access to critical systems that does not depend on the IdP.
• Non-human credentials: recovery plans often list user password resets but not service accounts, API keys, CI/CD tokens and signing keys. Ask who owns each and how long rotation takes. See the Leaked Credential Response Playbook.
• Exercise accounts: if an operations-based exercise uses test accounts or temporary privileged access, give them an expiry date, list them in the exercise plan and remove them at the hot wash.

Ground rules and running the session

• No-fault: state at the start that the exercise tests plans, not individuals, and that notes record decisions rather than names.
• Do not fight the scenario: the NCSC asks participants not to "fight the scenario" even when they think it unrealistic; note the objection and move on.
• Decide with incomplete information: when players ask "would we know X?", ask what they would do to find out.
• Use the plan as written: players open the playbook and follow it; where they improvise, the scribe records a plan gap.
• Real-world stop word: agree a phrase such as "real world" that halts the exercise if a genuine incident occurs, and keep one person watching live alerts.
• Half-day agenda: 15 minutes on ground rules and objectives, three 45 minute modules with breaks, a 30 minute hot wash and five minutes on next steps.

After-action report and improvement plan

HSEEP describes the hot wash as "a meeting that provides an opportunity to discuss exercise strengths and areas for improvement", held immediately after play and feeding the After-Action Report and Improvement Plan (AAR/IP). NIST SP 800-84 suggests asking where participants excelled, where they need training and which plan areas need updating. Collect feedback forms before people leave.

The AAR contains the background (purpose, objectives, participants, scenario), observations against each objective with root causes, and recommendations. The improvement plan turns each area for improvement into a corrective action that HSEEP says should be specific, measurable, achievable, relevant and time-bound, with a named owner and due date. Track actions with audit findings and, as the NCSC puts it, "ensure any recommendations are implemented ahead of delivering subsequent cyber exercises".

Building the programme

1. Baseline (months 0 to 2): inventory plans, confirm owners, and run a seminar so players know the plan before it is tested.
2. Pilot (month 3): run one technical tabletop on the highest-risk scenario using a CTEP or Exercise in a Box pack, after a dry run with the planning team to time modules and test injects.
3. Executive session (month 4): run the executive version, informed by the technical findings.
4. Close actions (months 4 to 8): fix the top findings, update plans and confirm with drills: break-glass sign-in, out-of-band call tree, backup restore.
5. Escalate (year 2): move a priority scenario to a functional exercise with a SimCell and MSEL once tabletops stop finding basic gaps.
6. Roll back a bad session: if an exercise goes off course (wrong players, scenario too complex, a real incident), stop it, record the design lessons and rerun the module rather than forcing it to finish.

• Frequency: at least one executive and one technical tabletop per priority scenario each year, plus one after major change such as a merger, a new IdP or a new critical supplier. Rotate scenarios.
• Small organisations: one annual tabletop from a free pack, run by a senior manager with a scribe, covering ransomware and account takeover.
• Large or regulated organisations: a calendar across business units and suppliers, independent facilitation for executive sessions, and evidence retained for auditors and regulators.

Detection and measurement

The NCSC warns that "poorly focused or incomplete metrics will provide unreliable data, introduce bias and lead to false lessons". Measure the programme, not just sessions:

• Corrective action closure rate: AAR/IP actions closed by their due date.
• Repeat findings: findings recurring from a previous exercise; the target is zero.
• Coverage: priority scenarios and critical plans exercised in the past 12 months, and named plan roles (including deputies) that have played.
• Decision timings: scenario time to key decisions, such as declaring an incident or disconnecting a supplier, against plan targets.
• Drill results: break-glass sign-in success and alert delivery time, call tree completion time, achieved restore time against target.

Common failure patterns

• Exercising without a plan: the session becomes plan writing and produces no measurable findings.
• Assuming core tooling survives: scenarios where email, chat, the IdP and device management keep working, although the Stryker attack shows the management plane itself can become the weapon.
• Theatre over evidence: elaborate videos with no objectives or evaluators, so the AAR is a list of impressions.
• Only principals play: the deputies on call over a bank holiday have never seen the plan.
• Suppliers left out: the scenario stops at your network boundary, although the Marks and Spencer cyberattack involved impersonating a third-party user.
• Findings never closed: the same gaps recur in each AAR because actions have no owners.

Framework mapping

Practitioner checklist

• Confirm the plans under test exist, have owners and are circulated as read-ahead.
• Write three to five SMART objectives and map every inject to one.
• Assign a sponsor, a neutral facilitator, a scribe and, for formal exercises, evaluators.
• Run separate executive and technical sessions, technical first.
• Include an identity compromise scenario each year, paired with a live break-glass sign-in and alert test.
• Invite key suppliers and your incident response retainer to at least one exercise.
• Label all exercise traffic "EXERCISE-EXERCISE-EXERCISE" and agree a real-world stop word.
• Hold a hot wash immediately and issue the AAR/IP with owners and due dates.
• Retest closed corrective actions in the next exercise and report closure rate to the sponsor.

Standards and references

• CISA: CISA Tabletop Exercise Packages
• FEMA: Homeland Security Exercise and Evaluation Program (HSEEP) Doctrine
• NIST: SP 800-84 Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities
• NCSC: Exercise in a Box
• NCSC: Effective steps to cyber exercise creation
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• CISA: CISA, JCDC, government and industry partners conduct AI tabletop exercise

Related NHI Mgmt Group resources: Incident Response Guide · Business Continuity and Disaster Recovery Guide · Ransomware Response and Recovery Guide · Break-Glass Account Guide · ITDR Guide