How to Run an Incident-Response Tabletop Exercise Using ChatGPT-Generated Scenarios

The short answer: Describe your systems, suppliers and data to a model in general terms, then ask it to build a 90-minute scenario with timed injects rather than a single incident summary. The exercise reliably surfaces three or four "we have no process for that" moments. The deliverable is not the scenario — it is the debrief list of findings with owners and dates.

Most incident-response plans are written once, approved, filed, and never tested. They read well. They name a response team, define severity levels, and contain a communications tree. What they have never done is survive contact with twelve people in a room trying to make a decision under time pressure with incomplete information.

That is what a tabletop exercise is for: not to prove the plan works, but to find out where it does not. The reason SMEs skip it is straightforward — a facilitated exercise from a consultancy is a meaningful cost, and writing a realistic scenario in-house is genuinely hard. It requires knowing what an attack looks like from the inside, hour by hour, and most people who have not lived through one write scenarios that are too clean.

This is a good fit for a language model. Scenario construction is a writing task with a well-understood shape, and a model has read a very large number of incident reports. It will not know your environment and cannot facilitate the room, but it removes the biggest barrier to running the exercise at all.

Why Untested Incident-Response Plans Fail on the Day

The failures are consistent, and none of them are about technical capability.

Nobody knows who declares an incident. The plan says "the incident response team is activated." It does not say who has the authority to say the word out loud at 22:00 on a Sunday, which means the first hour goes to a group chat about whether this is really an incident.

The contact list is out of date. Two people have left, one number is a desk phone in an office nobody can get into, and the plan is stored on the file server that has just been encrypted. Where the plan lives is part of the plan.

Nobody has decided what to say. Clients, staff, insurer, regulator, and — in a growing number of jurisdictions — a notification obligation with a defined clock. Drafting a holding statement during an incident produces something you regret. Drafting it beforehand takes twenty minutes.

The technical response has no business decision behind it. Do we take the ERP offline to contain this, when the plant runs on it? That is not an IT decision, and if nobody has ever been forced to make it, it will be made badly and slowly.

Recovery was never tested end to end. Backups exist. Whether they restore, how long a full restore actually takes, and whether the backups are themselves reachable from a compromised network are three separate questions, and organisations routinely discover the answers during the incident.

A tabletop finds all five in ninety minutes. That is the argument for doing it.

Generating a Scenario That Fits Your Company, Not a Template

Asking for "a ransomware tabletop scenario" produces something generic and comfortable. Comfortable is the failure state — if nobody in the room is uncertain, the exercise is theatre.

The Inputs: Your Systems, Your Suppliers, Your Data, Your Realistic Attacker

Give the model four things, in general terms.

What you run, described by function. "A cloud ERP, a file server, an email platform, a manufacturing execution system on-premises at one site, and remote access for a distributed sales team." Function and topology are what make the scenario land. Exact versions, hostnames and IP ranges add nothing to the exercise and should stay out.

Who your dependencies are, by category. An outsourced IT provider, a payroll bureau, a logistics partner with a system integration. Supply-chain scenarios are among the most useful precisely because the response is mostly non-technical and almost nobody has rehearsed it.

What data would hurt. Client personal data, designs, pricing, employee records. This drives the notification and disclosure branch of the scenario, which is where most organisations are weakest.

A realistic attacker, not a sophisticated one. The common cases are credential theft through phishing, an unpatched internet-facing service, or a compromised supplier account. Ask explicitly for a scenario built on a plausible entry point for a company of your size and sector. A nation-state adversary is a worse exercise, because the honest answer to most of its injects is "we would call someone."

Then tell the model who is actually in the room — IT lead, operations, finance, HR, a director — and ask it to write injects that force each of them to make a decision. An exercise where IT answers every question tests nothing about the organisation.

Injects and Escalation: How a Scenario Stays Uncomfortable for Ninety Minutes

The structural difference between a real exercise and a discussion is timed injects: new information released at intervals that changes the situation and often invalidates the decision just made.

Ask for six to eight injects across ninety minutes, each with a timestamp, the information revealed, and the decision it is designed to force. A good sequence escalates along three axes at once — technical scope, business impact, external pressure. An alert, then evidence it started three days ago, then a business system failing, then a client asking a direct question, then evidence that data left the network, then a deadline.

Two instructions make the scenarios noticeably better. Ask for injects that create conflict, not just complexity — operations wanting a system back and security wanting it isolated is the moment worth rehearsing, because it is the decision that will actually be contested. And ask for at least one inject with no good answer, where every option costs something. Real incidents are made of those, and the point of practising is to have made a decision like it once before.

Keep the scenario document to the facilitator; participants get the first inject only.

A Worked Example: A Ransomware Tabletop for a 120-Person Company

A manufacturer with an office and a plant, a cloud ERP, an on-premises file server and MES, and an outsourced IT provider. Ninety minutes, eight people, one facilitator.

T+0. Two staff report files opening with errors; the helpdesk has three tickets. Nothing is confirmed. *Forces: is this an incident, and who decides?*

T+10. The file server is unresponsive and a ransom note appears in a shared folder. *Forces: containment. Do you isolate the site network, and who authorises the plant losing connectivity?*

T+25. Logs suggest initial access happened nine days ago through the outsourced provider's remote access account. *Forces: the supplier conversation, and the uncomfortable realisation that the party you would normally call for help is now inside the incident.*

T+40. The MES is degraded and the plant supervisor asks whether to stop the line. *Forces: a business decision with a real hourly cost, made by someone who is not in IT.*

T+55. A client emails asking whether their drawings are affected, and a journalist has called the main line. *Forces: external communications, and whether anyone is authorised to speak.*

T+70. Evidence of data exfiltration prior to encryption. *Forces: notification obligations, insurer contact, and legal counsel — a branch most teams have never walked down.*

T+80. The backup admin console authenticates against the compromised domain. *Forces: the recovery assumption everyone had been relying on for the previous eighty minutes.*

In practice this exercise produces the same shortlist in most organisations: no named incident commander, no out-of-band communications channel, no tested restore time for the primary system, and no pre-drafted client statement. None of those require a budget to fix. All of them take weeks to fix if you start during an incident.

AI-Generated Scenarios vs a Facilitated Exercise vs an Off-the-Shelf Template

• Cost and time to run — AI-generated scenarios win decisively. An hour of preparation, no external fee, and you can run one per quarter instead of one per year.
• Fit to your actual environment — AI-generated scenarios beat a template clearly, and approach a facilitated exercise, provided you supply real context. A template describes a generic company; the model describes yours.
• Pressure in the room — a facilitated exercise wins. A skilled external facilitator pushes back on comfortable answers, notices who is deferring to whom, and will not let the room resolve an inject by asserting that IT would handle it.
• Reading the organisational dynamics — the facilitator wins absolutely. The most valuable findings are usually about authority and hesitation, and an experienced outsider sees them in a way a colleague running the session does not.
• Credibility with an insurer or auditor — the facilitated exercise wins. An independent report carries evidentiary weight that internal minutes do not, though good internal records beat nothing.
• Off-the-shelf template — wins on effort only. It produces a discussion rather than an exercise, because everyone can see the scenario was not written about them.

The sensible progression for most SMEs is not to choose. Run AI-generated exercises quarterly to find the obvious gaps cheaply, and bring in a facilitator annually — or before a major audit — for the independent read. Doing the cheap ones makes the expensive one far more productive, because the facilitator spends the time on genuine weaknesses rather than on findings you could have caught yourself.

The Debrief Is the Deliverable

The exercise is not the point. Thirty minutes of debrief while everyone is still in the room is where the value is created, and it is the step most often cut for time.

Run it as three questions. What did we not know how to do? What did we assume that turned out to be untested? What would we have got wrong if this were real?

Then convert every answer into a finding with a named owner and a date. Not "improve communications" — "draft a holding statement for clients and get it approved by the MD, [owner], within three weeks." A tabletop that produces themes has produced nothing; one that produces eight owned actions has produced a work plan.

Findings cluster predictably: authority and escalation, out-of-band communications, recovery-time assumptions, third-party dependencies, and notification obligations. If your list looks like that, the exercise worked. Re-run the same scenario in six months — the second run tests whether the fixes actually landed, which no new scenario can.

Getting This Right — Describing Your Environment Safely, and When to Bring in IT

Three practical points.

Describe your environment functionally, not forensically. There is a real difference between "an on-premises file server and a cloud ERP" and a document containing your hostnames, IP ranges, firmware versions and admin account names. The first is all a good scenario needs. The second is a reconnaissance package sitting in a third-party service. Use a business or enterprise tier with contractual data-handling terms, and keep the version that maps the scenario to real systems in your own documentation.

Do not let the scenario become a shadow risk assessment. A tabletop tells you how you respond; it does not tell you how exposed you are. Those are different questions, and answering the first well can create false comfort about the second. The findings deserve to feed into a prioritised, framework-mapped view — which is what Brocent's IT risk profiler produces: a vendor-neutral assessment mapped to ISO 27001, NIST CSF and CIS Controls, with a board-ready report and a 90-day, six-month and twelve-month remediation roadmap. That is the correct next artefact after a tabletop, rather than another exercise.

Fix the operational findings with whoever runs your IT. Out-of-band communications, tested restore times, privileged access review and supplier access controls are ordinary work, and they are what our AI+ support practice and managed IT support exist to do. Brocent has supported clients across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016. For the staff-facing half of readiness, phishing simulation programmes test the entry point most of these scenarios start from, and AI-assisted phishing detection covers the technical side of the same problem.

Frequently Asked Questions

Is it safe to describe our infrastructure to an AI to build a scenario?

It depends entirely on how much you describe. Functional descriptions — "a cloud ERP, an on-premises file server, an outsourced IT provider" — carry almost no risk and are all a scenario needs. Hostnames, IP ranges, firmware versions, account names and network diagrams are a different matter and add nothing to the exercise. Use a business or enterprise tier with contractual data-handling commitments rather than a personal account, and keep the mapping between the scenario and your real systems in your own documentation.

Who should be in the room?

Not just IT. The exercise tests organisational decision-making, so you need whoever can authorise taking a system offline, whoever speaks to clients, whoever handles staff communications, and a director who can make a call with money attached. Eight to twelve people is a workable size. If IT answers every inject, the scenario is not testing the organisation — rewrite the injects to force decisions on the other roles.

How often should we run one?

Quarterly if you are generating scenarios yourself, which is realistic once the cost is an hour of preparation. Annually at minimum, and after any material change — a new core system, an acquisition, a change of IT provider, or a real incident. Re-running the same scenario six months later is underrated: it tests whether the previous findings were actually closed, which a new scenario cannot.

Does this satisfy an insurer or auditor?

Sometimes, and it depends on what they asked for. Many insurers and frameworks ask whether incident response is tested and want evidence — so keep a record of the date, participants, scenario summary, findings and remediation status, which an internally run exercise produces perfectly well. Where an independent assessment or formal report is specified, it will not substitute. Read the actual wording rather than assuming either way.

What do we do with the findings?

Convert each into an owned action with a date before anyone leaves the room, and review them at a fixed point rather than at the next exercise. Most are process fixes that cost time rather than money. Where a finding points at a structural gap — no tested recovery capability, no logging worth investigating — that belongs in a prioritised remediation plan rather than an action list.

Where to Start

Write down the four inputs — your systems by function, your material suppliers, the data that would hurt, and the entry point you would actually expect — and generate one ninety-minute ransomware scenario. Book the room before you write it: the exercise that gets scheduled is the one that happens. If the debrief surfaces gaps you cannot close with process alone, that is where a prioritised remediation plan is worth more than another exercise: get in touch.