What is a tabletop exercise?
A tabletop exercise is a facilitated discussion built around a simulated incident. Participants talk through what they would do, who would make which decisions, what evidence they would need, and where response steps would stall. No production systems are touched. No alerts fire. No containment action actually runs. The value comes from testing assumptions before a real incident forces the team to test them under pressure.
That distinction matters. A tabletop is not a red team engagement, and it is not a hands-on drill. It answers a different question. If you want to know whether your decision-making, escalation logic, and response playbooks hold up, a tabletop is usually the right format. NIST SP 800-84 is still a useful foundation for explaining why discussion-based and operational exercises are different tools.
The 2026 Cloud Threat Report
Understand the real-world attack patterns driving the need for CIRA.
| Tabletop exercise | Red team engagement | Functional drill | |
|---|---|---|---|
| Format | Facilitated discussion around a scenario | Scoped adversary simulation against defenses | Hands-on rehearsal of response tasks |
| Participants | Decision-makers, responders, facilitator, observers | Offensive team and internal defenders | Operators executing assigned procedures |
| Live systems | None touched | Production or staging, carefully scoped | Controlled systems or simulated environment |
| Primary output | Coordination gaps and decision findings | Attack-path and detection findings | Procedure validation and timing data |
| Best used when | Testing assumptions without production risk | Validating defenses against realistic adversary behavior | Rehearsing technical execution under pressure |
Why security teams run tabletops
The first reason is straightforward: incident-response readiness. Tabletop exercises expose the gaps teams usually discover too late. A detection rule exists on paper but has never been validated against a realistic attack path. A response step assumes access to a tool, log source, or cloud account permission that the responder does not actually have. An escalation path looks clean in a diagram but breaks the first time two teams need to make a decision together.
The second reason is coordination. A useful exercise does not stay inside the security team. Platform or DevOps engineers can say whether an isolation step is technically possible in the current environment. Legal can explain what facts are needed before any notification decision is made. Communications can expose how long it really takes to prepare a customer, regulator, or executive message. Those are not side issues. In a real incident, they are part of the response.
The third reason is evidence. A well-run tabletop produces artifacts that are useful well beyond the session itself: a scenario summary, participant list, session notes, an after-action report, and a finding register. Those documents can support internal governance reviews and help demonstrate that the organization is exercising and improving its incident-response process. In regulated environments, they may also contribute evidence for programs such as PCI DSS incident-response testing, SOC 2 incident-response controls, or HIPAA contingency-plan review processes. The key point is not that a tabletop automatically satisfies every control. It is that a documented, well-scoped exercise gives the organization evidence it can actually use.
How a tabletop exercise works
The difference between a tabletop that exposes real gaps and one that simply confirms comfortable assumptions comes down to two decisions you control before the meeting starts: who is in the room, and how the session is structured.
Who should you include in a tabletop exercise
A practical tabletop usually works best with four role types: decision-makers, responders, observers, and a facilitator or evaluator. Keeping those roles distinct prevents the session from collapsing into status updates or turning into a free-form debate with no decisions attached.
Beyond the formal roles, the right functions need to be present. Security owns the detection and response choices the exercise is meant to test. Platform or DevOps engineering understands the real state of the environment and can confirm whether a playbook step is executable. Legal is essential when the scenario could trigger notification analysis, preservation requirements, or outside counsel involvement. Communications matters because response almost always includes internal messaging, executive updates, or external statements.
The CISO question depends on team size and culture. On a smaller team, the CISO can participate directly if the facilitator sets clear no-blame rules at the start. In a larger organization, it may work better to position the CISO as an observer or evaluator so executive presence does not unintentionally shut down candor.
Two ground rules improve the odds immediately. First, say explicitly that the session is for learning, not scoring. Second, send a short pre-read a few days in advance so participants can engage with the scenario instead of spending the first 20 minutes decoding it.
How should you structure a tabletop
A focused, single-scenario exercise often fits into 90 minutes. A cross-functional session with multiple escalation points may need three to four hours. In either case, the structure should stay simple: establish objectives, brief the scenario, introduce a sequence of escalating injects, discuss decisions at each point, then close with a post-exercise debrief. The CISA tabletop exercise packages and facilitator materials are useful models for structuring that flow.
The injects are where the exercise either becomes useful or wastes the room. A good inject does not test whether participants can guess the facilitator's preferred answer. It forces a decision under ambiguity. Two reasonable people should be able to make different calls from the same facts. That divergence is not a failure of the exercise. It is often the finding.
A few examples of good inject pressure points include: a detection with incomplete attribution, a containment option that threatens service availability, a privileged identity used in a way that could be legitimate or malicious, or a customer-impact question that arrives before the security team has confirmed scope. Each one forces the team to reveal how decisions are really made.
Close with a post-exercise debrief, but do not confuse it with the after-action report. The hot-wash captures what surprised people while the discussion is fresh. The after-action report comes later, after notes are reviewed and findings are translated into action items.
Tabletop exercise examples
Most published tabletop scripts still assume a generic ransomware event on a traditional enterprise network. That is fine if that is your main risk. For many cloud teams, it is not. If your environment is more exposed to IAM abuse, CI/CD compromise, toxic privilege combinations, or over-permissioned AI agents, the scenario has to reflect that reality.
IAM and credential abuse
A common cloud-native scenario starts with a valid but low-privilege identity and asks whether the team can recognize privilege escalation before it becomes full administrative access. For example: a Lambda execution role calls policy-version APIs multiple times in ten minutes, there is no approved change behind it, and the same identity is later tied to actions that suggest role-passing or privilege expansion. The decision being tested is not only whether the team investigates. It is whether they can distinguish authorized automation from adversary behavior quickly enough to act. The specific AWS permissions often discussed in this kind of escalation path include iam:CreatePolicyVersion and iam:PassRole.
CI/CD secrets exposure
This scenario starts in the build pipeline instead of the workload. A routine scan or package update completes successfully. Minutes later, the runner's ephemeral OIDC token is hijacked, making anomalous API requests across S3 buckets and secret managers it has no business touching. The room now has to decide: Is this a compromised third-party dependency, an unannounced infrastructure change, or a downstream credential leak? The exercise reveals whether engineering, security, and platform teams know who owns the pipeline, what logs exist, and how quickly secrets can be rotated.
Infrastructure drift with security impact
Drift by itself is not an ATT&CK technique and should not be treated like one. But it is a realistic precursor to incidents. A good scenario might reveal that a security group was changed directly in the console six weeks ago, SSH is now open from anywhere, Terraform still shows the original approved rule, and no one was alerted. The question is whether the team notices the mismatch, how they decide to remediate it, and whether they can explain the exposure window to leadership.
AI agent over-permissioning
As teams deploy coding agents, assistants, and connected AI services, a new class of scenario becomes useful. An AI agent in the CI/CD path has access to secrets it does not truly need. An indirect prompt injection or malicious instruction inside a pull request causes the agent to take an unsafe action or expose a credential. The team then has to answer three questions quickly: what authority the agent had, what it actually touched, and whether current monitoring would surface that behavior in time. The OWASP GenAI project’s LLM06: Excessive Agency is a useful framing reference for this type of risk.
The scenario is only valuable if the decisions, missing signals, and unanswered questions it exposes are turned into owned remediation work.
Post-exercise action items
The most common tabletop failure happens after the meeting ends. Notes exist, people agree the session was useful, and nothing closes. The fix is discipline.
Start with an after-action report that is built for action, not ceremony. A practical version usually includes an executive summary, the exercise scope, the objectives tested, the major observations, and an improvement plan. The improvement plan is the core. That is where each finding becomes a tracked work item.
Classify findings so remediation is easier to assign. A simple model works well: detection gap, process gap, communication gap, tool gap, or playbook gap. The labels are not there for elegance. They force precision. A missing SIEM rule is not the same problem as an unclear approval chain or a containment step no one can safely run.
Every finding should leave the exercise with three things attached: an owner, a due date, and a status field. Without all three, the register is just a list of observations. With them, it becomes a program the team can revisit 30 or 60 days later.
This is also where tabletop output becomes genuinely useful to auditors, risk teams, and leadership. A documented scenario, named participants, recorded observations, and evidence of closure show that the organization is not just discussing response readiness. It is improving it. NIST SP 800-61 Rev. 3 is a helpful reference point when connecting exercises back to broader incident-response improvement.
Watch 5-min demo
See how Wiz Defend automates cloud detection and response with real-time threat context.
Getting the most out of tabletop exercises
The most critical challenge of any tabletop exercise is keeping the scenario grounded in your actual threat landscape. Instead of drafting abstract, generic scenarios that fail to reflect your real cloud footprint, Wiz connects code, cloud configuration, and active runtime context into a unified security graph. This allows teams to build simulations directly from real-world risk profiles creating an immediate, shared source of truth that drives meaningful cross-functional decision-making.
For organizations navigating the risks of rapid AI adoption, Wiz AI security capabilities provide visibility across AI models, training pipelines, and Wiz AI Agents (such as Red, Green, and Blue), alongside the Model Context Protocol (MCP) servers and services they connect to. By contextualizing how AI risks tie back to your broader infrastructure, identity, and data, security teams can construct high-fidelity tabletop scenarios involving over-permissioned AI agents, exposed model endpoints, or unsafe AI-to-cloud relationships.
A tabletop exercise is only as good as the action taken after it ends. Once the discussion is over, Wiz Defend helps teams carry their security assumptions into real-world validation. Powered by the eBPF-driven Wiz Sensor, its runtime workload protection capabilities support continuous threat monitoring, active drift detection, file integrity monitoring, and rapid, response-oriented investigations across cloud workloads and Kubernetes environments. While a simulation helps you talk through your defense playbooks, Wiz helps you verify that the detection signals and security controls you discussed actually exist and function where they matter most.
If you want expert guidance, you can also leverage Wiz Tabletop Wargame Simulations, a part of our expert-led Wiz Threat Services (currently in Public Preview). Led by Wiz threat experts, these interactive decision-tree workshops are based on real incident response dilemmas and are tailored to your company's environment in dedicated executive or technical formats.
Ready to transform your cloud incident response?
See how Wiz unifies detection, investigation, and response across your entire cloud environment.
