Ask any leadership team: "What would you do if ransomware hit your file server right now?" Often, the CFO looks at the CTO. The CTO looks at the IT director. Nobody knows who would make the call to shut things down.
That silence reveals everything about incident preparedness.
Discovering that gap in a meeting costs nothing. Discovering it during an actual ransomware attack can cost days of downtime and hundreds of thousands of dollars.
That's the power of a tabletop exercise—a low-stakes way to find high-stakes problems.
What We're Actually Talking About
A tabletop exercise is just a structured conversation. You gather the people who would respond to an incident, present a realistic scenario, and talk through what you'd actually do.
No systems get touched. No alerts fire. It's a meeting—but one where you discover whether your incident response plan exists anywhere outside of a dusty PDF.
Why This Matters More for Small Teams
Enterprise companies have dedicated incident response teams, 24/7 SOCs, and playbooks for everything. Most small businesses don't. And that's fine.
But every organization does have people who will need to respond when something goes wrong. The IT person. The office manager who handles vendor communications. The CEO who will need to decide whether to pay a ransom. (The answer should be no, by the way, but that's another post.)
The question is: do these people know their roles? Have they ever practiced together?
For most organizations, the answer is no. Not because anyone's negligent—just because nobody's ever asked.
Who Needs to Be in the Room
Keep it small. Five to seven people is ideal. Too many and you get spectators instead of participants.
You need:
- The technical person — IT director, sysadmin, or your MSP contact. Someone who understands the systems.
- A decision-maker — CEO, COO, or someone who can authorize spending, downtime, or external communications.
- Operations — Someone who knows how the business actually runs day-to-day.
- A note-taker — This is crucial. You need to capture gaps, not just discuss them.
Optional additions depending on your scenario: HR (for insider threats), legal (for breach notification), communications (for public-facing incidents).
Pick a Scenario That Could Actually Happen
Don't pick nation-state attacks or Hollywood-style hacks. Pick something boring and realistic.
Good first scenarios:
- Ransomware on a file share — An employee opens an attachment, and suddenly shared drive files are encrypted
- Business email compromise — Someone impersonates the CEO and requests a wire transfer
- Lost laptop — A device with customer data gets left in an Uber
- Vendor breach — Your payroll provider announces they were compromised
The best scenario is one that makes people slightly uncomfortable because they realize it could happen tomorrow.
Running the Exercise
Present the scenario in stages. Don't dump everything at once—real incidents unfold over time.
Stage 1: Detection "It's 2 PM on Tuesday. Your accounting manager reports that she can't open files on the shared drive. When she looks, the files have weird extensions she doesn't recognize."
Ask: Who does she call? What happens next?
Stage 2: Escalation "IT confirms that files are encrypted. The ransomware note demands 2 Bitcoin within 48 hours."
Ask: Who makes the call to involve leadership? Do you call law enforcement? Your insurance carrier?
Stage 3: Response "You need to determine what systems are affected and whether customer data was accessed."
Ask: Do you have the logs to answer that? Who would analyze them?
Stage 4: Recovery "Leadership decides not to pay. You need to restore from backup."
Ask: When was the last backup tested? How long until you're operational?
Every stage will reveal gaps. That's the point.
Document Everything
Your note-taker should capture:
| Question | Answer | Gap Found |
|---|---|---|
| Who gets called first? | "Probably IT... or maybe the CEO?" | Yes — no clear escalation path |
| Where's the incident response plan? | "I think it's on SharePoint somewhere" | Yes — nobody knows |
| When was the last backup tested? | Long silence | Yes — never tested |
You don't need fancy software. A shared Google Doc works fine. The document matters less than actually capturing the gaps.
After the Exercise: Make It Count
A tabletop that doesn't lead to action items is just a meeting.
Within a week of your exercise, you should have:
- A prioritized list of gaps discovered
- An owner assigned to each gap
- Target dates for remediation
Common action items I see:
- Create an emergency contact list (and put it somewhere accessible offline)
- Document the first three steps for common scenarios
- Schedule a backup restoration test
- Get cyber insurance quotes
- Establish a relationship with an incident response firm before you need them
How Often?
At minimum, annually. But also:
- After any significant system change
- After leadership turnover
- After an actual incident (even a minor one)
Your second tabletop will be better than your first. Your third will be even better. The team builds familiarity with each other's roles and comfort with the process.
The Real Value
I've seen organizations spend hundreds of thousands on security tools while having no idea who would make decisions during an incident. That's backwards.
A 60-minute tabletop exercise costs nothing but time—and it might be the highest-value hour your security program spends all year.
Want help facilitating your first tabletop, or need realistic scenarios tailored to your industry? Anchor Insight includes 12+ pre-built incident drill scenarios with timed injects, role-based participation, and compliance mapping. Let's talk.
