Tabletop Exercises: Practice the Breach Before It Happens

Every business with an incident response plan believes something about itself that has never been tested: that when the bad morning comes, people will find the plan, understand it, and follow it. Then the bad morning comes, the plan turns out to name an employee who left last year, nobody knows who is allowed to shut down the server, and the cyber insurance number is in an email nobody can reach because email is what went down. A tabletop exercise exists to have that experience on purpose, around a conference table, where it costs ninety minutes instead of a business. This guide explains what tabletop exercises are, why untested plans fail so reliably, and exactly how a small business can run its first one without hiring anyone.

What a Tabletop Exercise Actually Is

A tabletop exercise is a structured discussion where your team walks through a realistic incident scenario, step by step, and answers one question at every step: what would we actually do right now? No systems are touched and nothing is simulated technically; the exercise runs on talk, which is precisely its power, because most incident response failures are not technical, they are human. Someone reads the scenario aloud, ransomware note on the office manager's screen at 7:40 a.m., and the room responds in real time: who gets called first, who decides whether to disconnect things, what do we tell the staff arriving at eight, do we pay attention to the plan or to the loudest voice. A facilitator injects complications as the story unfolds, the backup console will not load, a client is calling, a reporter emails, and someone writes down every hesitation, disagreement, and discovery. Ninety minutes later, the business knows things about itself it could otherwise only learn the expensive way.

Why Plans Fail Without Practice

Written plans decay silently, and rehearsal is the only instrument that detects it. People change roles and leave; the plan keeps naming them. Phone numbers, vendors, and insurance details drift; the plan keeps the old ones. Steps that read sensibly on paper turn out to depend on the exact system the incident took away, the contact list in the email that is down, the plan itself on the encrypted file server. And authority, the question of who may make the painful call, disconnect the network, close the office, notify clients, turns out never to have been actually assigned, only assumed. None of these flaws is visible when the document is written, and every one of them surfaces in the first twenty minutes of a decent tabletop, which is why experienced practitioners say an untested plan is a hypothesis, and treat the exercise as the moment the hypothesis meets data.

How to Run One in Ninety Minutes

A first exercise needs far less production than businesses fear. The working sequence:

• Pick one scenario: a single, plausible incident, written as a short story in three or four stages.
• Name a facilitator and a scribe: one person runs the story and injects complications; one captures every gap and decision.
• Gather the real decision-makers: the people who would actually be in the room that morning, not just IT.
• Walk the stages aloud: at each stage, the room answers what it does next, using the plan if it can.
• Let it be uncomfortable: do not rescue the discussion; the stumbles are the product.
• Debrief and assign: turn the scribe's notes into a fix list with owners and dates.

Two ground rules keep it honest. First, this is a blameless exercise: the goal is finding weaknesses in the plan, not in people, and a room that fears embarrassment will perform the plan instead of testing it. Second, answers must be specific: "we would restore from backup" is not an answer; who logs into what, using which credentials, stored where, and how long does the restore take, is an answer, and the difference between the two is where incidents are actually won or lost.

Choosing a Scenario That Earns Its Minutes

The best first scenario is the one your business privately worries about, told concretely. Ransomware is the classic for good reason, it tests backups, authority, communication, and nerve all at once, and the response fundamentals we cover in our ransomware incident response guide make a natural script to test against.

But the second-best scenarios are quieter and just as revealing: a finance employee reports they may have paid a fraudulent invoice, the pattern behind business email compromise; a laptop full of client files is gone from a car; a key vendor calls to say their breach may have exposed your data; the building loses power and internet on the busiest day of the month. Rotate scenario types over time, and write each with a detail that makes it land, the specific system, the specific morning, the specific client on the phone, because generic scenarios produce generic answers and the point is the opposite.

A First Scenario, Staged

To make this concrete, here is the shape of a first ransomware script, four stages, each a paragraph read aloud. Stage one, 7:40 a.m.: the office manager's screen shows a ransom note and the shared drive will not open; the room answers who gets the first call, who has authority to disconnect systems, and where the response plan physically is right now. Stage two, 8:15: staff are arriving and cannot work, a client meeting starts at nine, and your IT contact asks whether to shut everything down, a step that stops the spread and also stops the business; the room decides, and says who tells the staff what. Stage three, 10:00: backups exist, but the person who knows the restore procedure is on a plane, and the attackers' note names a deadline; the room answers who can actually perform the restore, how long it takes, and whether anyone knows the cyber insurer's incident line without opening email. Stage four, day two: a client asks directly whether their data was affected; the room drafts the honest sentence it would send. Every stumble between the stages goes on the scribe's list, and a first run of exactly this script reliably fills a page.

Who Should Be in the Room?

Smaller than a staff meeting, bigger than the IT corner. The owner or a decision-empowered leader must attend, because the hardest calls in any incident, spend the money, close the office, notify the clients, are theirs, and discovering during a real event that leadership has never thought about them is the most expensive lesson on the menu. Add whoever runs your technology, internal or your provider on a video call, whoever manages the office and would face staff and phones, and whoever touches money, since payment fraud scenarios live or die on finance's reflexes. Five to eight people is the sweet spot: enough perspectives to expose gaps, few enough that everyone actually speaks.

From Findings to Fixes

The exercise's real product is the scribe's list, and the pattern of what shows up on it is remarkably consistent: contact information that was wrong or unreachable, authority that was never assigned, dependencies nobody had noticed, the plan stored where the incident would take it, and restore steps nobody has personally performed. Sort the list into fixes for the plan, update names, numbers, and steps, and fixes for reality, print the contact card, assign the authority in writing, and, most commonly, actually test the recovery the plan leans on, because a tabletop that reveals nobody has ever performed a restore is politely pointing at the discipline covered by a proper backup and disaster recovery program. Give every fix an owner and a date, and schedule the follow-up exercise before the room empties, because a finding list without a next test is how tabletops become theater.

How Often, and What It Costs

For most small businesses, twice a year is the honest cadence: enough that the plan and the people stay current, infrequent enough to respect calendars, with an extra run after any big change, new systems, new leadership, a near miss, or a real incident elsewhere in your industry. The cost is a conference room, a prepared hour of the facilitator's time, and ninety minutes of the participants', which puts it among the cheapest security controls that exists; free scenario packages published by government cyber agencies can seed the story if writing one feels daunting. There is also an external payoff arriving whether you invite it or not: insurers, auditors, and client questionnaires increasingly ask whether your incident response plan is tested, and a dated exercise summary with a fix list is exactly the evidence that question wants. A practical calendar trick keeps the rhythm honest: book the next exercise as a recurring meeting before the current one ends, and attach the fix list to the invitation, so every session opens with the previous session's promises and whether they were kept. Six months is long enough for drift to accumulate and short enough that the muscle memory survives.

The Honest Limits

Keep the tool in proportion. A tabletop exercise tests decisions, knowledge, and coordination; it does not test whether the firewall holds or the backups restore, so it complements technical testing rather than replacing it, and it pairs naturally with the human-side preparation of ongoing security training, which builds the reflexes the exercise then examines under pressure. A tabletop also only measures the people in the room; if the person who would really matter that morning was not invited, the result flatters you. And one good exercise is a snapshot, not a certification: the value compounds only with the rhythm, each run finding the drift since the last. Used inside those limits, it is the highest ratio of insight to effort in small-business security.

Have the Bad Morning on Purpose

Every business will eventually run its incident response plan; the only choice is whether the first run happens in a conference room or during the real thing. A tabletop exercise buys the discoveries at the cheap price: the wrong phone number found over coffee instead of at dawn, the unassigned authority settled by discussion instead of by panic, the untested restore scheduled instead of prayed for. Pick the scenario your business quietly worries about, put the real decision-makers around the table for ninety minutes, write down everything that stumbles, and fix it. The next time that scenario stops being hypothetical, your team will be having its second bad morning, and second bad mornings go very differently.

For businesses in the region, a partner providing IT services in Ventura County can facilitate the exercise, play the technical seat, and turn the findings into fixes.

Companies in the Conejo Valley can get the same locally through IT support in Westlake Village, from writing the first scenario to running the follow-up that proves the fixes landed.

If your incident response plan has never been tested against a bad morning, GlobeVM can facilitate your first tabletop exercise, from a scenario built around your real systems to the fix list that makes the plan worth its paper.