Most mid-market companies have some version of an incident response plan sitting in a shared drive. Fewer have ever actually tested it. The gap between “we have a plan” and “we know our plan works” only gets exposed one way: by running it, deliberately, before a real attacker does it for you.
That’s what a tabletop exercise is for. It’s a structured, discussion-based simulation, no systems get touched, nothing goes offline, where your actual response team works through a realistic incident scenario in a room (or a call) and finds out, in a low-stakes setting, where the plan holds up and where it falls apart. For a mid-market company without a large dedicated security operations team, this is often the single highest-leverage hour a security budget can buy.
Why Mid-Market Companies Need This More, Not Less
Enterprise security teams tend to run tabletop exercises as a matter of course, it’s baked into compliance cycles and dedicated staff own it. Mid-market companies skip it more often, usually for understandable reasons: there’s no dedicated CISO, the IT lead is already stretched thin, and a tabletop exercise sounds like a project nobody has four hours to run.
That reasoning has it backwards. Mid-market companies are exactly the profile ransomware operators target most consistently, big enough to have something worth taking, small enough to lack a 24/7 SOC watching for it. And when an incident hits a company that size, there usually isn’t a large team to absorb the confusion; the same five or six people who’d normally be doing their day jobs are suddenly also running the response, often for the first time, often under real pressure. A tabletop exercise is the cheapest possible way to make sure that first real incident isn’t also the first time those people have looked at the plan.
Before You Run One: You Need an Actual Plan to Test
A tabletop exercise tests a plan, it doesn’t create one from scratch. If your organization doesn’t have a written incident response plan yet, that’s the actual first step, and it doesn’t need to be elaborate to be useful. A workable incident response plan template for a mid-market company generally covers four phases, following the same structure security teams have used for years (formalized in NIST’s incident handling guidance):
Preparation: who’s on the response team, how they’re reached (including if email and Slack are down), what tools and backups exist, and who has authority to make containment decisions.
Detection and analysis: how an incident gets identified and escalated, and who makes the call on severity.
Containment, eradication, and recovery: the decision tree for isolating systems, removing the threat, and restoring operations, including who can authorize taking production systems offline.
Post-incident activity: how the incident gets documented, reported (to insurers, regulators, customers where required), and turned into lessons that update the plan itself.
If that document doesn’t exist yet, block time to draft it before scheduling a tabletop, even a rough first version is enough to exercise. If it exists but hasn’t been touched in over a year, treat the tabletop as the forcing function to update it.
Running the Exercise: Step by Step
1. Set a specific objective and scope: “Test our incident response” is too broad to actually run. Pick one realistic scenario and a narrow set of questions you want answered: Can we detect this in time? Do we know who has authority to take a system offline? Does our cyber insurance require anything we’re not currently doing? A two-hour session that answers three real questions well beats a half-day session that tries to cover everything and answers none of them clearly.
2. Choose a scenario that matches your actual risk: Ransomware is the standard starting scenario for good reason, it’s the most statistically likely serious incident most mid-market companies will face, and it forces decisions across every part of the business, not just IT. A workable structure: start with a single, ambiguous signal (a user reports a slow machine, an odd login alert fires), and introduce new information every 15–20 minutes as the exercise progresses, a second system going down, a ransom note appearing, a call from a journalist, a deadline from your cyber insurer’s breach coach. CISA’s public Tabletop Exercise Packages are a solid, free starting point for structuring these scenario “injects” if you’re building your first one from scratch.
3. Get the right people in the room, not just IT: This is where most first-time tabletop exercises fall short. A ransomware incident isn’t an IT problem with side effects; it’s a business crisis that happens to start in IT. The room needs: IT/security leadership, an executive sponsor with real decision authority, legal or outside counsel (ransom payment decisions carry real legal exposure, see our post on ransom payment data for why that matters), communications or marketing (customers and press will need to be handled), HR if employee data is involved, and finance (ransom negotiation, unbudgeted recovery costs, and cyber insurance all intersect here). If your cyber insurance broker or incident response retainer offers a facilitator, this is the exercise to invite them to.
4. Assign a facilitator and a scribe before you start: The facilitator runs the scenario and introduces each new inject, they should not also be playing a role in the response, or the exercise loses its structure. The scribe’s only job is capturing what actually happens: every decision made, every question that stalled the room, every “we should check on that” that never got resolved. That document becomes the entire value of the exercise afterward.
5. Run it as discussion, not theater: The team talks through what they’d actually do at each stage, who they’d call, what they’d check, what they’d decide, rather than literally acting it out. When the facilitator introduces a new inject (“IT now confirms three more servers are encrypted”), the room pauses and works through the response in real time. Resist the urge to let it turn into a lecture from whoever’s most senior; the goal is to see what the team does with the information, not what they’d do in theory if asked cold.
6. Debrief immediately, while it’s fresh: Before anyone leaves the room, spend 20–30 minutes on what worked, what didn’t, and what was unclear. Ask directly: was there a moment nobody knew who was in charge? A step where the plan said one thing and the room did another? A contact number that turned out to be wrong? These are usually the most valuable findings of the entire exercise, and they evaporate fast if not captured immediately.
7. Turn findings into plan updates, this is the step most companies skip: A tabletop exercise that doesn’t change anything afterward wasn’t worth running. Every gap identified in the debrief should become a specific, owned action item with a deadline: update the call tree, clarify who has containment authority, get a signed retainer with an incident response firm instead of a “we’ll figure it out” plan, confirm backups are actually tested and offline. Write a short after-action report, even a one-page version, and put a date on the calendar for the next exercise.
A Simple Tabletop Exercise Template to Start From
If you’re building your first one, a working tabletop exercise template doesn’t need to be more than this:
Objective: What specific question(s) this exercise answers.
Scenario summary: One paragraph describing the starting incident.
Injects: 4–6 new pieces of information, timed roughly 15–20 minutes apart, each escalating the situation or introducing a new decision point.
Participants and roles: Who’s in the room and what role they’re playing (their real one, not a hypothetical).
Discussion questions per inject: What would we do right now? Who decides? Who do we need to notify? What don’t we know that we need to?
Debrief template: What worked, what didn’t, what’s unclear, what changes as a result, each with an owner and a deadline.
How Often to Run One
Once a year is the reasonable minimum for most mid-market companies, and more often, every six months, if you’ve had leadership turnover, a significant infrastructure change, or your last exercise surfaced major gaps. The exercise doesn’t need to be identical each time; alternating scenarios (ransomware one year, a business email compromise or vendor breach the next) tests different parts of the plan and keeps the team from just memorizing the last scenario’s answers.
The Real Point of the Exercise
The goal of a tabletop exercise was never to pass it. It’s to find the gaps in a conference room on a Tuesday afternoon, when the cost of discovering them is a slightly awkward debrief, instead of finding them at 2 AM during a live ransomware incident, when the cost is measured in downtime, dollars, and decisions made by people who are improvising under pressure for the first time. Companies with a retained incident response partner already have a natural extension of this: the same team that would run point during a real event can help design and facilitate the exercise that tests whether your organization is actually ready for them to.
Not sure where to start with a Tabletop Exercise Template?
You can download this one as a starting point:
CyberClan Tabletop Exercise Template →
Ready for a Program That Actually Covers Every Angle?
Piecemeal security leaves gaps, and gaps are exactly what attackers look for. Talk to our team and find out what a complete, tailored cybersecurity program looks like for your business.
