How to use AI to run a cybersecurity incident tabletop exercise

A cybersecurity tabletop exercise is a structured discussion of how an organization would respond to a realistic incident. It tests decisions, ownership, communication, business priorities, and recovery assumptions without touching production systems. AI can help tailor scenarios, manage facilitator material, and organize observations, but it must operate within safe boundaries and an approved incident response plan.

This guide explains how to use AI before, during, and after a tabletop exercise. It is designed for security, engineering, IT, legal, privacy, communications, customer support, operations, and executive teams. It does not provide exploit instructions or replace qualified incident response leadership.

Define the exercise objective

Choose two to four learning objectives. Examples include testing who can declare an incident, how customer impact is assessed, when legal and executive teams join, how a critical vendor is contacted, whether recovery priorities match business needs, and how public statements are approved.

Avoid a vague goal such as test our security. A bounded objective produces observable decisions and useful follow-up work. Decide whether the exercise is a learning session, a validation of a mature plan, or a retest of previous gaps.

Set safety, confidentiality, and scope

Declare that the exercise is simulated. Do not scan systems, execute malware, use real credentials, contact external emergency services, or send messages that could be mistaken for a live incident. Establish an immediate stop phrase and a route for reporting a real incident discovered during the session.

Use an AI environment approved for incident plans and system information. Remove credentials, exploit details, personal data, customer secrets, and sensitive architecture that is not necessary. Keep the participant list, notes, and after-action report at the correct classification.

Gather the authoritative inputs

Collect the current incident response plan, role roster, escalation thresholds, service inventory, business impact analysis, dependency map, recovery objectives, contact procedures, communication templates, regulatory decision process, vendor obligations, and open actions from previous exercises.

Record the version and verification date of each input. If the on-call roster or vendor contact is stale, fix it before the exercise rather than testing a known clerical error.

Design a realistic scenario

The scenario should be plausible for the organization's technology and business model, but it does not need detailed attack mechanics. Examples include stolen administrative credentials, a compromised software supplier, ransomware affecting a shared service, unauthorized data access, or a cloud-region outage with suspicious activity.

Use this English Prompt:

Act as a cybersecurity tabletop exercise designer. Using only the incident response plan, system inventory, business impact priorities, and participant roles I provide, propose three realistic exercise scenarios. For each scenario, define the learning objectives, initial conditions, affected services, threat assumptions, required participants, boundaries, safety controls, and evidence needed to judge decisions. Do not provide exploit instructions or assume controls that are not documented.

Security leaders should approve the scenario and remove details that would disclose unnecessary defensive weaknesses. Keep the exercise challenging but solvable with information participants could realistically obtain.

Select participants and role boundaries

Invite people who own decisions, not only security specialists. Typical roles include incident commander, technical lead, operations, service owner, legal, privacy, communications, customer support, HR when relevant, vendor manager, executive sponsor, facilitator, and observer.

Give participants their normal authority. If the real process requires an unavailable executive to approve a shutdown or notification, the exercise should reveal that dependency rather than granting imaginary authority.

Build facilitator injects

Injects reveal new information in stages: an alert, customer report, unavailable backup, media question, vendor update, evidence of data access, regulatory deadline, or recovery conflict. Each inject should test a decision linked to an objective.

Create a facilitator inject sequence for this approved scenario: [scenario]. Each inject must include release time or trigger, information visible to each role, the decision being tested, expected discussion, optional follow-up evidence, and the condition for advancing. Include technical, customer, legal, executive, third-party, and recovery decisions without turning the exercise into a trivia test.

Prepare optional branches so the facilitator can adjust pace. Do not reward participants for guessing the hidden story. Provide evidence when they ask the right operational question, just as an incident team would query logs, owners, or vendors.

Establish evaluation evidence

Define what observers will capture: time to declare, decision owner, facts requested, assumptions, escalation points, customer impact method, containment tradeoffs, notification decisions, recovery sequence, and unresolved questions. Record decisions and rationale without judging speaking style or individual confidence.

Use a shared clock and decision log. Mark whether an action was supported by the current plan, improvised, blocked, or assigned for later verification. This makes the after-action report evidence-based.

Facilitate the exercise

Begin with scope, confidentiality, safety controls, objectives, and the rule that participants should act in their real roles. Release the opening scenario, let the team organize, and ask neutral questions: Who owns this decision? What fact would change it? Which service is the business priority? What must happen before recovery?

Avoid teaching the answer while the decision is being tested. If discussion stalls, release an approved clue or ask participants to use the documented plan. Keep technical details connected to business and communication consequences.

Test communication and notification decisions

Include internal updates, customer support guidance, executive briefings, vendor coordination, and a public or media question where appropriate. Participants should distinguish confirmed facts, working hypotheses, unknowns, actions, and next update time.

Legal and privacy specialists should own conclusions about contractual or regulatory notification. AI can organize the relevant facts and draft a holding statement, but it should not make the legal determination.

Test containment and recovery tradeoffs

Force at least one tradeoff, such as disabling a revenue-critical service to protect data, restoring from a backup that may be incomplete, rotating credentials while key staff are unavailable, or waiting for forensic evidence before rebuilding.

Ask the team to state decision criteria, business impact, dependencies, rollback conditions, and the evidence required to declare recovery. Recovery is not complete merely because a server is running; integrity, security, data reconciliation, customer impact, and monitoring must be addressed.

Run the after-action review

Hold a short hotwash immediately after the scenario, then analyze the decision log, observer notes, and participant feedback against the objectives. Focus on systems and process, not blame.

Analyze the exercise notes against the approved objectives and response plan. Build an evidence-based after-action report with observed strengths, decision gaps, unclear ownership, missing information, communication delays, policy conflicts, and recovery assumptions. For every finding, include the exercise evidence, business impact, owner role, corrective action, priority, due date, and a measurable retest condition. Do not assign blame to individuals.

Validate the AI-generated draft with the facilitator and role owners. Merge duplicate findings, remove unsupported criticism, and preserve disagreements that need policy decisions.

Track corrective actions and retest

Convert each material finding into a specific action with an owner role, priority, deadline, dependency, evidence of completion, and retest method. Rewriting a plan is not sufficient if the gap involves permissions, monitoring, backup integrity, vendor contracts, staffing, or executive authority.

Schedule a focused retest for high-risk gaps. Report overdue actions through the same governance route that owns incident risk. An exercise creates value only when it changes readiness.

Practical example

A SaaS company runs a supplier-compromise scenario. The team quickly contains API access but discovers that no one owns the decision to notify customers when evidence is incomplete. Support drafts a message, legal asks for affected-region data, and engineering cannot produce a reliable tenant list within the exercise window.

The after-action plan assigns ownership for notification decisions, adds a query to produce affected tenants, updates the vendor escalation path, and sets a 60-day retest. The useful result is not that participants found the fictional attacker. It is that the company can now make a real decision faster with better evidence.

Quality checklist

• Objectives are specific and observable.
• The scenario matches real services, roles, and business priorities.
• No exploit activity, production changes, or misleading external messages occur.
• Injects test decisions instead of obscure technical knowledge.
• Participants act with their real authority and dependencies.
• Observers capture time, evidence, decisions, and rationale.
• Legal conclusions remain with qualified reviewers.
• Findings become owned actions with measurable retest conditions.

Common mistakes

• Creating an exciting attack story with no learning objective
• Inviting only technical staff
• Using stale plans or contact lists
• Giving participants authority they do not have in real life
• Turning the session into a quiz with hidden answers
• Letting AI invent architecture, controls, or legal duties
• Measuring success by whether the scenario was solved
• Publishing an after-action report without tracking fixes

FAQ

**How long should a tabletop exercise take?** A focused exercise often fits into 90 minutes to three hours. Complex cross-border or recovery scenarios may need separate sessions rather than one exhausting event.

**Should participants see the scenario in advance?** Share objectives, scope, and preparation material. Keep specific injects private when surprise is necessary to test decisions, but do not use surprise to embarrass participants.

**Can AI facilitate the live session?** It can help retrieve approved injects and organize notes, but a human facilitator should control timing, safety, ambiguity, and group dynamics.

**How often should we run exercises?** Base frequency on risk, regulatory needs, major system changes, leadership turnover, and previous findings. Retest high-risk gaps sooner than the next annual exercise.

Related guides

• How to use AI to document legacy software
• How to use AI to plan a data migration
• How to use AI to create standard operating procedures