Tabletop Exercise Prompt: Build an IR Scenario in Minutes

Most security teams run the same tabletop exercise twice and then stop. The scenario PDF goes stale, the injects name systems the team retired a year ago, and nobody wants to spend a week writing a fresh one. A tabletop exercise prompt fixes the bottleneck: it turns one parameterized prompt into a tailored incident-response drill for whatever stack, threat, and roster you point it at.

The web is full of advice about doing this with AI. CIS Security's white paper on generative AI for tabletop development explains the concept for under-resourced government teams but ships no copyable prompt (cisecurity.org). Vendor pages like Reflex Security describe a platform that scans your domain and spits out scenarios, but the methodology stays behind the product (reflexsecurity.io). What's missing is the thing a security lead can actually paste into ChatGPT or Claude today.

This post is that prompt. The whole point is reuse: write it once, swap the variables, run a new exercise every quarter without starting from a blank page.

What you can do with a tabletop exercise prompt

• Generate a ransomware, BEC, or supply-chain scenario sized to your environment
• Produce a timed inject schedule (T+0, T+15, T+45) instead of one flat narrative
• Get role-specific decision points for the SOC analyst, IC, legal, and comms seats
• Build facilitator discussion questions that probe your real gaps, not generic ones
• Tailor injects to your cloud provider, EDR, and SIEM by name
• Run a fresh drill quarterly so the same five people don't memorize one script
• Spin up a short version for a 45-minute lunch session or a full half-day exercise

The CM-Alliance scenario library is a good reference for what kinds of incidents to cover, but it's a list of conceptual frameworks you still have to flesh out by hand (cm-alliance.com). The gap a prompt closes is the fleshing-out.

Why static scenario PDFs fall flat

A canned tabletop scenario is written for an average org. Yours isn't average. The injects reference a "file server" when you're fully on S3, or a "domain controller" when you went passwordless. Participants notice instantly, and the moment the scenario stops feeling real, the room checks out.

The fix isn't more detail. It's your detail. When an inject says "PagerDuty alerts on the payments-api pod restarting in your EKS cluster," the on-call engineer leans in because that's a thing that could actually happen on Tuesday. That specificity is exactly what a {{tech_stack}} variable buys you.

Anatomy of the prompt

The structure matters more than the wording. The model needs a role, the scenario parameters as variables, and a hard output contract so it can't wander into a generic story.

Role:     You are a senior incident-response exercise facilitator.
Inputs:   {{org_profile}}, {{tech_stack}}, {{threat_scenario}},
          {{participant_roles}}, {{exercise_duration}}, {{maturity_level}}
Task:     Produce a tabletop exercise tailored to the inputs.

Output contract (return in this exact order):
1. Scenario brief — 4-6 sentences, named systems from {{tech_stack}}
2. Inject schedule — a table: Time | Inject | Source | What participants see
3. Decision points — grouped by {{participant_roles}}, 2-3 each
4. Discussion questions — 6-8, mapped to NIST IR phases
5. Curveball inject — one unexpected escalation
6. Debrief prompts — 3 questions on gaps surfaced

Notice where the contract sits. Put it at the end of the prompt, after the inputs, because models weight the most recent tokens. Claude honors a numbered ## Output format block reliably; GPT-4o sometimes needs the schema restated on the final line if you've pasted a long org profile above it.

Step-by-step usage

1. Gather inputs

Pull a short profile of the org (industry, size, regulated or not), the actual stack, and the seats you'll fill at the table. Don't over-research. Three sentences per input beats a wiki dump.

2. Fill the variables

Set {{threat_scenario}} to the thing you're actually worried about this quarter. Ransomware is the default reflex. Resist it if your real exposure is a leaked CI token or a vendor breach. Match the drill to the threat model, not to the scariest headline.

3. Run the prompt

Paste it into Claude or ChatGPT. Read the scenario brief first. If the named systems are wrong, fix the {{tech_stack}} variable and rerun rather than editing the output by hand.

4. Stress-test the injects

Check that the inject schedule escalates. A flat sequence where every inject is the same severity teaches nothing. You want a slow burn that forces a declaration decision, then a curveball.

5. Iterate per audience

For a board-level session, ask the model to compress decision points into business-impact language. For a SOC drill, keep the technical injects sharp and add log snippets. Same prompt, different {{maturity_level}}.

Prompt-craft patterns that make it land

Pin the inject schedule to a table. Free-form injects blur together. A markdown table with Time | Inject | What participants see columns forces the model to think in discrete, timed beats — and it's the part facilitators copy straight into their run sheet.

Format the inject schedule as a table with columns:
Time (T+0, T+15...) | Inject | Delivery channel | What the team observes
Escalate severity across rows. No more than 6 injects.

Map discussion questions to a framework. Tie each question to a NIST incident-response phase (detect, contain, eradicate, recover). This stops the model from asking six versions of "how would you respond?" and surfaces the phase your team is weakest on.

Force one curveball. Models write tidy, linear scenarios by default. Real incidents aren't tidy. Explicitly requesting one unexpected escalation (the backup is also encrypted, the comms lead is on a flight) is what separates a drill from a checklist read-through.

And no, asking for "a realistic scenario" five different ways doesn't make it more realistic. The named systems do that.

Variables you'll set

Getting started

1. Write a three-sentence {{org_profile}}.
2. List your {{tech_stack}} with real product names.
3. Pick the {{threat_scenario}} that matches this quarter's risk, not last quarter's news.
4. Name the {{participant_roles}} who'll be in the room.
5. Run the prompt in Claude or ChatGPT and read the scenario brief.
6. Tune the injects, then export to your facilitator run sheet.
7. Schedule the debrief before the exercise, not after, so the gaps get owned.

If you'd rather not assemble the contract from scratch, the Cyber Tabletop Exercise Builder ships it ready to run, and the Threat Modeling Workflow pairs well for choosing which scenario to drill first.

A tabletop is only as good as the follow-through. Once the exercise surfaces a gap, write it up the same way you'd write a real one — the blameless incident postmortem prompt turns the debrief into an action list, and the runbook authoring prompt closes the gaps the drill exposed. Run the drill, capture what broke, fix the runbook. That loop is the whole value.