Analysis
How to run a tabletop exercise executives won't forget
A practical guide to security tabletop exercises: scenario design, who to include, how to inject pressure, and turning findings into fixes.
TL;DR: A good tabletop is a stress test of decisions, not a read-through of the plan. Design one hard scenario with escalating injects, put real decision-makers in the room, force choices with incomplete information, and end with three committed fixes. If nobody was uncomfortable, the exercise failed.
Why tabletops matter more than plans
Incident response plans fail at the seams: who can approve taking the revenue system offline, whether the ransom question is even discussable, who calls the regulator, what the CEO says in hour six. Documents don't answer those; rehearsal does. A tabletop is the cheapest way to discover that your 72-hour notification duty and your "we'll investigate for a week first" instinct are incompatible — before a real clock is running. Insurers, auditors, and regulators (Part 500, DORA) increasingly treat tested plans as the only kind that count.
How do you design the scenario?
Three rules. Make it yours: the scenario should attack your actual crown jewels through your plausible weakest door — a ransomware detonation via a third-party remote-access tool, a compromised build pipeline, an exec's phished mailbox. Generic scenarios produce generic complacency. Script the injects: 6–10 timed developments that escalate pressure — the attacker leaks proof, a journalist emails, the backup restore fails, the regulator's portal asks questions you can't yet answer, a customer's lawyer calls. Each inject should force a named decision. Plant the dilemmas: the best exercises engineer at least two genuinely hard calls — pay-or-don't-pay, disclose-now-or-verify-first, shut-down-revenue-or-contain-slowly — where reasonable executives disagree. The disagreement is the finding.
How do you run the room?
Ninety minutes to two hours; a facilitator who isn't the CISO (the CISO should play their real role, not referee); phones down; and one explicit ground rule — decisions must be made, "we'd assess" is not an answer. A scribe logs every decision, every assumption, and every "who owns this?" that gets silence. Resist the urge to rescue struggling participants with hints; the struggle is the data. End with fifteen minutes of structured debrief: what worked, what broke, what surprised you.
What happens after?
The exercise is worth exactly what changes because of it. Within a week, publish a short report: scenario, key decisions, three to five findings, each with an owner and a date — not twenty findings, which guarantees zero fixes. Typical first-exercise findings: no one knew the insurance carrier had to approve the IR firm; legal and security had different definitions of "material"; the communications draft took four hours nobody had. Fix those, then schedule the next exercise to test the fixes. Two cycles in, the room stops performing for each other and starts practicing — which is the point.
Frequently asked questions
- What is a tabletop exercise in cybersecurity?
- A discussion-based simulation of a security incident: participants walk through a scenario in a room, making the decisions they would make in a real event — no systems are touched. The output is a tested plan and a list of gaps.
- Who should participate in a security tabletop?
- For an executive tabletop: the CEO or a deputy, legal, communications, finance, HR, the CISO and incident lead, and IT/engineering leadership. The people who would decide in a real incident are the ones who need to practice deciding.
- How often should tabletop exercises be run?
- At least annually for the executive scenario, more often for technical teams. Regulated entities often face explicit expectations — incident response plan testing appears in NYDFS Part 500, DORA, and most cyber insurance underwriting.
CISO Tribune Editorial
Editorial Desk
The CISO Tribune editorial desk reports on security leadership: who holds the role, who is leaving it, and what the moves mean. Every appointment entry is verified against a primary source before publication.