Updated: October 2026
When a server dies, people know who to call. When the finance inbox starts sending new bank details to your suppliers, the questions get harder: who calls the bank, who can shut off email, who tells the client. A cybersecurity tabletop exercise answers those questions in a meeting room, before an attacker forces the answers in real time.
What a Tabletop Exercise Is, and What It Isn't
A tabletop exercise is a guided conversation about an incident that hasn't happened. A facilitator describes a scenario, adds new facts every few minutes, and asks the people in the room what they would do next.
NIST's guide to test, training and exercise programs (SP 800-84, September 2006) puts the boundary plainly: a tabletop exercise "is discussion-based only and does not involve deploying equipment or other resources." Nobody touches a keyboard. Nobody restores a server.
That makes it cheap, and it also defines what it can't prove. A tabletop won't tell you whether last night's backup restores. That's the job of disaster recovery testing, where you run the restore for real. It won't find an open port either, which is what a penetration test is for. What it finds is the gap between the plan on paper and the people who are supposed to follow it.
The output is a short list of those gaps. A missing phone number, an approval nobody owns, a plan stored on the server that the scenario just encrypted.
Who Should Be in the Room
Invite the people named in your incident plan, not everyone who might be curious. For a small company or a single MSP client, that's usually six to ten people:
- Facilitator. Runs the clock, reads the injects, asks the follow-up questions. Ideally someone who won't be making the decisions.
- Scribe. NIST calls this role the data collector. Writes down every decision, every "I don't know" and every name that comes up.
- Decision maker. The owner or an executive who can approve shutting systems down, spending money and calling lawyers.
- IT lead. Internal IT, the MSP, or both. On a co-managed account, invite both sides.
- Finance. Essential for any scenario that involves payments.
- Communications. Whoever would talk to staff, clients and, if it came to it, the press.
The same NIST guide recommends running senior and operational teams separately at first, then together once each group knows its part. For a small team, one combined session is fine. Just keep the executive questions and the technical questions in separate rounds so neither group waits through the other's details.
A 90-Minute Run Sheet
NIST puts a typical tabletop at two to eight hours. That fits a large organization exercising a whole plan. A small team running its first one gets more from 90 minutes on a single scenario than from a day that exhausts everyone by lunch.
| Time | Segment | What happens |
|---|---|---|
| 0:00 | Ground rules | No-fault discussion, phones down, the facilitator owns the clock. Read the two or three objectives aloud. |
| 0:10 | Scenario setup | The starting situation: day, time, who is in the office, what just happened. |
| 0:20 | Inject 1 | The first new fact. Each role says what they would do in the next 30 minutes. |
| 0:35 | Inject 2 | Things get worse. Decisions now cost money or downtime. |
| 0:50 | Inject 3 | The curveball: a key person is unreachable, a journalist calls, the attacker makes contact. |
| 1:05 | Hotwash | What went well, where people hesitated, which parts of the plan failed. |
| 1:20 | Actions | Every gap gets an owner and a due date before anyone leaves. |
The last ten minutes matter most. A tabletop that ends with "good discussion, everyone" and no owners produces nothing you can check next quarter.
In this r/cybersecurity thread, people who have sat through ransomware tabletops argue about whether they change anything. One reply sums up the case for running them: you don't want the first time you practice to be while everything is on fire.
Four Tabletop Exercise Scenarios With Injects
Each scenario below has a starting situation and three injects. Pick one per session. The question under each is the one that tends to expose the gap.
Ransomware on a Monday Morning
Setup: 7:40 on Monday. Staff report that files on the shared drive have strange extensions and won't open.
Inject 1: The file server and two laptops show the same extension. A text file named "README" sits in every folder.
Inject 2: The backup console shows the backup server was also reached. Last night's job failed. The last good copy is eight days old.
Inject 3: The attackers email the owner directly. They claim they copied client files and give a 72-hour deadline.
The question: who can authorize disconnecting the whole network, and where is the printed copy of the plan and the contact list? If the answer is "on the file server," you've found your first action item. Our breakdown of a ransomware attack walks through how these hours tend to unfold.
Business Email Compromise and a Wire Transfer
Setup: Monday afternoon. A regular supplier calls to ask why last month's invoice is unpaid.
Inject 1: Finance says it was paid on Friday, to the new bank details the supplier emailed two weeks ago.
Inject 2: The supplier never changed banks. The email came from a lookalike domain, and the thread shows your own staff member's replies.
Inject 3: The staff member's mailbox has a rule forwarding every message containing "invoice" to an outside address.
The question: who calls your bank's fraud line, and how fast? Speed decides this one. The FBI's 2025 IC3 report (April 2026) counted 24,768 business email compromise complaints and $3.05 billion in reported losses. Its Recovery Asset Team froze $679 million of $1.16 billion in attempted theft, a 58% success rate, and the report stresses that time is of the essence.
Cloud Account Takeover
Setup: Tuesday. An employee mentions they approved a sign-in prompt on their phone last night that they didn't expect.
Inject 1: Their Microsoft 365 account shows sign-ins from another country, and a new app has been granted access to their mailbox.
Inject 2: Three colleagues received messages from that account with a link to a shared document.
Inject 3: One of those colleagues is the finance manager, and they clicked.
The question: who can revoke sessions, reset credentials and remove the app consent, and do you keep sign-in logs long enough to see where it started?
Your Own Remote Management Tool Turns on You
Setup: Thursday, 16:00. Your RMM or remote access vendor posts a security advisory about an actively exploited flaw.
Inject 1: Your console shows a script you didn't write, queued to every managed device.
Inject 2: Two clients call. Their machines are rebooting.
Inject 3: The vendor recommends taking the server offline. That also removes your main way to reach and fix those machines.
The question: can you shut the tool off and still work, and who tells each client what? The 2021 attack on Kaseya VSA is the real-world model for this one. Our guide to RMM security covers hardening the tool itself.
How to Facilitate Without Turning It Into Theater
A tabletop fails when it becomes a performance for an auditor or a quiz for the IT team. A few habits keep it useful:
- Keep it no-fault. You're testing the plan, not the people. The moment someone gets blamed, everyone else stops admitting what they don't know.
- Ask "who" and "how," not "would you." "Would you call the bank?" gets a yes. "Who calls, and what number do they dial?" gets the truth.
- Hold the clock. If a discussion runs long, note it as an action item and move on.
- Throw one curveball. The IT lead is on a flight. The owner says "can't we just pay?" A client's lawyer calls. Those are the moments that test a plan.
- Record decisions, not transcripts. The scribe needs the decision, who made it and what was missing.
You don't have to write scenarios from scratch. CISA publishes Tabletop Exercise Packages (CTEPs) with more than 100 scenarios, including ransomware, insider threat and phishing. Each package comes with objectives, discussion questions, feedback forms and an after-action report template.
For a lighter format, the Backdoors & Breaches card game turns an incident into a round of cards a small team can play in one sitting. This RSAC session plays one live:
Scoring and the After-Action Report
Straight after the last inject, run the hotwash. NIST describes it as a facilitated debrief where participants say what went well, where they need more training and which parts of the plan should change.
Then write it up within a week. The after-action report doesn't need to be long. NIST SP 800-84 asks for background (purpose, objectives, participants, scenario), the observations from the facilitator and scribe, and recommendations for the plan. FEMA's Homeland Security Exercise and Evaluation Program pairs the report with an improvement plan, so every weakness becomes a corrective action.
A simple way to score it: rate each objective as met, partially met or not met, and attach the evidence from the scribe's notes. Then list every action with an owner and a date. Next quarter, check the list before you plan the next scenario.
This r/grc thread asks how to keep tabletops from turning into a box to tick for auditors.
The answer is in the action list. If the same gap shows up two exercises in a row, the tabletop worked and the follow-through didn't.
How Often to Run One
NIST's guidance is to run tabletops periodically, and again after organizational changes, plan updates or new guidance. In practice that means once a year as a floor, plus a session after any of these:
A new MSP or internal IT lead takes over. A key tool changes, such as email, backup or remote management. The person who holds the plan leaves. The company opens a new site or buys another business.
Rotate the scenario each time. Three years of ransomware rehearsals leave a wire fraud call untested. If you carry cyber insurance, check whether the renewal questionnaire asks about exercises, and keep the after-action reports where you can find them. Our overview of cyber insurance requirements covers what carriers look at.
The Short Version
A cybersecurity tabletop exercise is 90 minutes, one scenario, three injects and a list of owners at the end. It tests decisions and the written plan, not systems. Start with ransomware or business email compromise, borrow a CISA package if you'd rather not write your own, and score it against the actions it produces.
If you're still building the plan the exercise will test, our guide to the BC, DR and IR plans explains which one covers what. A full incident response guide for small IT teams is coming next.
Dmytro Koval
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
