The exercise should include the people responsible for incident decisions, a facilitator who can keep the scenario moving, and someone to document actions and gaps. Cross department participants are also valuable because breaches usually affect more than one team. For larger scenarios, leadership and compliance stakeholders should join so the organisation can test escalation, messaging, and accountability end to end.
Who should be in the room for a tabletop exercise?
The right participants depend on the scenario, but the core group should mirror the people who would actually make, execute, and record decisions during an incident. That usually means decision-makers, technical responders, communications leads, and a facilitator who can keep the discussion moving. Include adjacent teams when their actions or approvals would shape containment, recovery, reporting, or business continuity.
A tabletop is not a performance by one team, it is a rehearsal of how the organisation behaves under stress. If the exercise only includes the security team, you will miss the handoffs, delays, and approval bottlenecks that often determine whether the response works in practice. The goal is to involve the smallest group that still reflects the real decision path.
For a practical starting point, use the incident response roles and review structure in Incident Response Guide, then add the people who own the business, legal, and operational decisions the scenario is likely to trigger.
Which teams and roles add the most value?
Start with the incident commander or decision owner, the technical responders, and a note-taker or observer who can capture decisions, gaps, and follow-up actions. Then add the functions that would be asked to approve containment, customer communication, evidence handling, regulatory notification, or service restoration. In larger organisations, that often includes IT operations, cloud or platform teams, legal, privacy, compliance, HR, customer support, and communications.
Different scenarios justify different seating. A ransomware exercise should involve backup, recovery, and leadership decision-makers; an insider or account compromise scenario should include identity and access owners; an OT or production outage scenario needs operations and safety stakeholders. If you are testing escalation and executive coordination, bring in senior leadership early enough to observe how they receive information and make trade-offs.
Use the exercise to validate role clarity, not just attendance. The most useful participants are the ones who can confirm who has authority, who must be consulted, and who needs to be informed when the situation changes. A well-chosen group exposes whether your process depends on one person being available rather than on a repeatable decision structure.
When you need a broader operating model for how roles, injects, and after-action follow-up fit together, the Tabletop Exercise Guide is the most direct reference point.
How do you decide who to include without overloading the exercise?
The best filter is materiality. Invite people whose decisions, systems, or approvals would change the outcome of the scenario, and keep observers to a minimum unless they are there to learn a specific lesson. Too many participants can slow the discussion, but too few can hide the exact coordination failures the exercise is meant to expose.
Cross-functional inclusion is especially important when the scenario crosses boundaries such as technology, legal duty, customer impact, or executive messaging. That is where a tabletop becomes useful as an organisational test rather than a technical discussion. If you want to compare what was assumed to happen with what the teams would actually do, the Tabletop Exercise After Action Report Template helps structure the findings around actions, owners, and deadlines.
Do not treat seniority as a substitute for relevance. A director who has no role in the decision path may add little, while a lower-level operator who owns a critical approval or recovery step may be essential. The right room is the one that can surface decision friction, communication gaps, and accountability issues without turning the session into a status meeting.
Risk and Threat Considerations
Tabletop exercises can fail when the room does not reflect the real response chain. If key approvers, communications owners, or recovery teams are absent, the exercise can produce a false sense of readiness because the hardest coordination problems never appear.
Failure mechanism: Important decisions get delayed, delegated incorrectly, or made without the functions that would be required in a live incident, so the team rehearses an idealised response rather than the actual one.
Impact: The organisation may discover too late that escalation paths, messaging, legal review, recovery ownership, or executive approvals are unclear, which increases downtime, reporting risk, and confusion during a real event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IR-2 — Incident Response Training | Tabletops are a core incident response training activity. |
| IR-4 — Incident Handling | The question centers on who executes incident handling decisions and actions. | |
| Recommendation — Include the roles that must practice coordinated incident decision-making. Map each participant to the handling actions they would own in a live event. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | CIS 17 covers incident response roles, exercises, and communication readiness. |
| Recommendation — Assign the incident response functions that the exercise must validate. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | Tabletops test prepared incident management roles and coordination. |
| A.5.26 — Response to information security incidents | The exercise tests response coordination across the teams involved. | |
| Recommendation — Use the exercise to confirm who is prepared to perform each incident management role. Bring in the people who would coordinate and execute incident response actions. | ||
Practitioner Guidance
What to prioritise: Prioritise the people who own incident authority, cross-team dependencies, and outward-facing decisions before you add observers or subject-matter specialists. If a person would need to approve, execute, or communicate in a real incident, they belong in the exercise.
What to verify: Verify that each participant has a clear reason to be there and that the group collectively covers decision-making, technical execution, documentation, escalation, and messaging. If any of those functions are missing, the exercise will likely under-test a real failure point.
Practitioner takeaway: The best tabletop team is not the largest one, it is the one that reproduces the real incident decision chain closely enough to expose where the organisation slows down, loses clarity, or fails to coordinate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org