Cybersecurity Tabletop Exercises: Scenarios and How to Run One

A cybersecurity tabletop exercise is a facilitated rehearsal of a security incident. The people who would handle a real breach walk through a realistic scenario, inject by inject, and make the decisions the incident would demand, in a conference room instead of at 2 a.m. A good exercise produces three artifacts: a decision log, a findings register with owners and due dates, and updated runbooks. A weak one produces reassurance and a certificate of completion. The difference comes down to five choices: who is in the room, how the scenario is built, how injects are timed, whether the facilitator forces named decisions, and whether findings are tracked to closure afterward. This article covers each choice, plus six scenario outlines worth running this year.

Who must be in the room

Security and IT operations attend by default, and they are rarely the problem. The gaps that surface in real incidents sit with everyone else. Legal decides when privilege attaches, which notification statutes start their clocks, and what can be written down. Communications owns the holding statement, the customer notice, and the answer when a reporter calls before you are ready. Finance moves money, recalls wires, and talks to the cyber insurance carrier. HR owns any scenario involving an employee. And at least one executive with real authority must attend, because "would you approve a ransom payment" is not a question a security analyst can answer.

The selection rule is simple: if the real incident would need a person's signature, that person participates in the exercise. Send the people who would actually do the work, since a delegate who cannot commit their department turns every decision point into "we would have to check."

Two roles make the session function. A facilitator runs the clock, delivers injects, and pushes past comfortable answers. A scribe records every decision, open question, and gap as it happens. One person cannot do both jobs, and skipping the scribe converts the whole session into a pleasant memory. Keep the room to somewhere between eight and fourteen people, because beyond that, participants become an audience.

Build the scenario from your own environment

Generic scenarios produce generic conversation. The scenario should name your actual systems: the ERP, the identity provider, the backup platform, the vendor that runs payroll. When the facilitator says "Veeam reports the last four weekly backups failed verification" to a team that runs Veeam, the room behaves differently than it does for "your backups are unavailable."

Structurally, a scenario is a ground situation plus four to seven injects. The ground situation establishes what is known at the start: an alert, a phone call, a vendor email. Injects are timed updates that raise the pressure or remove a capability everyone assumed they had. The craft is in the removals. Backups fail their restore test. The incident commander is unreachable on a flight for six hours. The attacker emails a journalist. The ransom deadline halves. Each inject should force a specific decision, and the planner should know in advance which decision it is meant to force, because that intent is what turns discussion into findings.

Build the scenario with one technical insider who checks it for realism and then keeps the details confidential. A scenario the participants have already read tests nothing.

Facilitation mechanics

Open with ground rules: this is a no-fault session, and everything stays in the room except the findings. Then hold three disciplines for the length of the exercise.

First, refuse the runbook answer. When someone says "we would follow the incident response plan," the facilitator asks who opens it, where it is stored, and whether that location is encrypted in this scenario. That one follow-up question produces more findings than any other technique, because plans that exist in the abstract routinely fail on specifics: the plan lives on the SharePoint that is down, the out-of-band contact list is eighteen months stale, and nobody present knows who can approve an emergency firewall change.

Second, timebox and record. Each inject gets ten to twenty minutes. The scribe logs decisions with the name of the person who made each one, plus every question the room could not answer. Unanswerable questions are findings, and they are usually the best ones.

Third, end with a hot wash. Go around the table once, and each participant names the single gap that worried them most. Close by reading the decision log back so the room agrees on what it decided. Ninety minutes is right for an executive session, while technical sessions can run two to four hours.

Executive and technical tabletops are different exercises

An executive tabletop tests decisions: whether to pay, when the disclosure clock starts, what the CEO says publicly, when to invoke privilege, and whether to notify the insurance carrier before forensics confirm scope. The scenario detail stays thin and the decision weight stays heavy. A technical tabletop tests execution: containment order, whether to preserve forensic images before restoring, the sequence of identity resets, which systems restore first, and who decides.

Run them as separate sessions and connect them with a shared scenario spine, where the executive session picks up the consequences of what the technical team decided. Combining the audiences fails both of them: executives disengage while engineers debate containment, and engineers go quiet while lawyers discuss notification language. For a first exercise, start technical, because it generates the concrete failures that make the executive session real.

Six scenarios worth running

Each of these maps to an incident class we see in practice, and each carries a built-in twist that removes an assumed capability.

• Ransomware with backup failure. Encryption plus data theft across file servers and a domain controller. Mid-exercise, the restore test fails: the immutable copies were misconfigured ten months ago and full recovery is estimated at three weeks. Forces the payment evaluation, restore priority, and disclosure decisions everyone hoped to avoid.
• Business email compromise and wire fraud. Finance receives a convincing vendor bank-change request and wires $840,000 on a Friday afternoon. The recall window is closing, a second altered invoice surfaces, and the insurer asks what controls existed. Forces the recall call, the FBI IC3 report, and the question of who else was targeted.
• Third-party breach notification. Your payroll vendor discloses a breach affecting your employees' data, in vague language, eleven days after discovering it. Forces the analysis of your own notification obligations as the data owner, what your contract's breach notification clause actually requires, and who calls the vendor's CISO.
• Insider data exfiltration. A departing sales director syncs a full CRM export to a personal cloud account during their notice period. HR has already accepted the resignation, counsel raises limits on searching personal accounts, and the export includes customer PII. Forces evidence preservation, interview timing, and the notification analysis.
• Cloud credential compromise. An attacker replays a stolen session token into Microsoft 365, satisfies MFA without triggering it, and registers a rogue OAuth application for persistence. Sign-in logs only cover thirty days, and the application has held consent for eight of them. Forces mass session revocation, tenant-wide credential resets, and the forensics scoping decision.
• AI agent misuse. An internal AI agent with connector access to email and file storage is prompt-injected by a crafted inbound message and begins forwarding documents outside the company. The traffic looks like normal API activity, and no runbook mentions agents. Forces the kill-switch question, the logging adequacy question, and a policy gap most organizations currently have.

CISA packages are a free starting point

The Cybersecurity and Infrastructure Security Agency publishes CISA Tabletop Exercise Packages, or CTEPs. As of mid-2026 there are more than 100 downloadable situation manuals covering ransomware, insider threat, phishing, industrial control system compromise, and a range of physical and hybrid scenarios. Each package includes sample objectives, a scenario narrative, and discussion questions, and the cybersecurity packages align to the NIST Cybersecurity Framework in a roughly three-hour format. For a team that has never run an exercise, they are the fastest legitimate way to avoid starting from a blank page.

They fall short in three predictable places. They are written for any organization, so they name no system you own, and an unedited CTEP produces exactly the generic conversation described above. Their discussion questions invite reflection rather than force decisions, so a passive room can complete one without deciding anything. And they end at the discussion, with nothing that converts what the room learned into tracked remediation. Treat a CTEP as scaffolding: swap in your systems and your org chart, convert the discussion questions into decision points with named owners, and add the inject that removes the capability your team is most confident about.

Findings become fixes, or it was theater

The test of an exercise is what exists 90 days later. Within a week, the scribe's notes should become a findings register: each finding stated in one sentence, the moment in the exercise that produced it, an owner, a due date, and a severity. Run it with the same discipline you would apply to security audit findings, because that is what these are: findings against your incident response capability, generated at a fraction of an incident's cost.

Fixes land in four places. The incident response plan and runbooks get corrected where they failed on specifics. Contracts get amended where the exercise exposed them, most often vendor breach notification clauses. Contact lists, escalation paths, and out-of-band channels get rebuilt and then tested. And unresolved questions of authority, such as who can approve a payment or take a revenue system offline, get decided by leadership in daylight rather than mid-incident. The next exercise retests the register, and a finding that appears on two consecutive registers has become a decision not to fix something.

On cadence: SOC 2, ISO 27001, HIPAA, and CMMC all expect incident response testing, and an annual tabletop satisfies that expectation. Twice a year, alternating executive and technical sessions, is the cadence that actually changes behavior.

We design and facilitate these through our tabletop exercise service, including the scenario build, the injects, and the findings register. One finding recurs across engagements more than any other: the moment the room realizes no external responder is on standby and nobody knows who to call first. That is the gap an incident response retainer closes, with rates and response times negotiated before you need them.