Your first tabletop exercise: practicing the incident you haven't had yet

The drill you run before the incident runs you

The first time your team decides who shuts off a compromised account should not be at 2am during a real attack. That decision is hard enough when everyone is calm, awake, and in the same room. It gets much worse when the account in question is the CEO's, the money may have already moved, and nobody is sure who is allowed to do what.

Most companies your size do have an incident response plan. It is usually a document somebody wrote for the SOC 2 audit, saved to a shared drive, and never opened again. A clean audit and a plan that actually works are two different things. A plan that has never been tested is a guess about how your team will behave under pressure, and guesses tend to fall apart at the worst moment. A tabletop exercise is how you find out whether the plan holds, cheaply, before anything is on the line.

What a tabletop exercise actually is

A tabletop exercise is a facilitated, discussion-based walkthrough of a realistic scenario. The people who would actually respond sit down together, someone presents an attack as it unfolds, and the room talks through the decisions they would have to make at each step. It is a conversation about roles, responsibilities, and decision-making, not a live technical drill.

Nothing in production gets touched. No accounts get locked, no systems get pulled offline, no real money is at risk. You are practicing the thinking and the coordination, not running the actual response. That is the whole point: you get to make the mistakes on paper, where they cost nothing, instead of making them for the first time during a real incident.

It costs time, not money. Your first one needs a couple of hours, the right people in a room, and a scenario worth working through, not a new tool. The free government resources below give you the scenario and the structure to run it yourself, and what that first run surfaces is exactly where an experienced partner earns their place.

Why the team that's never been hit needs this most

There is a quiet assumption inside most companies that have never had an incident: we would figure it out. The team is smart, the people are capable, and surely when something goes wrong everyone would rally and handle it. That assumption is exactly the thing a tabletop tests, and it is usually the thing that does not survive contact.

It matters more for a smaller team, not less. Attackers tend to go after the organizations with weaker incident response, slower patching, and fewer people watching, and smaller companies take the brunt of it. In the Verizon 2025 Data Breach Investigations Report, ransomware or extortion showed up in 88% of breaches at small businesses, compared with 39% at large organizations. The companies with the least practice are the ones getting hit most.

An untested plan is not really a plan. It is a hypothesis about who does what, and the only honest way to check a hypothesis is to run it. A tabletop is the cheapest test you will ever run, and the cheapest place to discover that the plan has a hole in it.

Who's in the room

The right people for a tabletop are the people who would actually be involved in the real thing. Not the people who own security on paper, the people who would actually get a call at 9pm if an account were taken over.

For a company your size, that usually means a small group:

• A facilitator to present the scenario and keep the discussion moving. This can be someone internal or your security partner.
• The founder or CTO, because the hard calls (whether to pull a system, what to tell customers) tend to land on them.
• Finance, since money movement is where attackers aim and where the damage is done.
• Whoever owns email and identity, in Microsoft 365 or Google Workspace. This is the person who would actually go change settings or lock an account.
• Comms or outside counsel, even informally, for the question of what you say and to whom.
• Your MDR or incident response partner, if you have one, because they are part of the real response.

A small team wearing several hats is completely normal. One person might cover finance and operations, another might own both email and the rest of IT. That is fine. The goal is not a big room, it is the right room: the people who would really be called when it happens.

Pick one realistic scenario

The temptation on a first tabletop is to reach for something dramatic: a nation-state attacker, a zero-day, a full ransomware shutdown. Skip the exotic one. Start with the threat that actually hits companies your size, because a scenario the room can picture produces a real discussion, and a far-fetched one produces shrugs.

For a SaaS or tech company, business email compromise is the most relatable place to start. An attacker gets into a mailbox, watches the conversation, and steps in to redirect a payment. It is common, it is expensive, and everyone on the team can imagine it happening on a Tuesday afternoon. If you want to see what the real version looks like under the hood, we walked through it in detail in the first hour of a business email compromise. For the tabletop, you can keep it higher level and focus on the decisions.

A walkthrough: the wire-transfer email

The scenario plays out at the table in beats. The facilitator presents each one, and the room works the questions before moving on.

It starts with an email. Finance receives a message that looks like it is from the CEO. It is urgent and confidential, and it asks them to approve a wire to a new vendor before the end of the day. The first question is the simplest and the most important: does finance act on it? If they want to check, who do they check with, and how? Is there an agreed rule that any change to payment details gets verified out of band, by a phone call to a known number, before money moves?

Then something looks off. Someone notices the message does not appear in the CEO's sent items, and there is a new inbox rule quietly forwarding invoice emails to an outside address. Now the questions get sharper. Who can even see the mailbox rules? Who has the authority to remove that rule and lock the account, right now, not after a meeting and a round of approvals?

Now it gets tense. It is unclear whether the wire already went out. The CEO is unreachable, because the CEO's account is the one that has been taken over. So who decides what happens next? Who calls the bank, and does anyone have the after-hours number? Where is the contact list if you cannot trust email, which is the very thing that is compromised?

Then it goes public. A customer emails asking why they received a payment-detail change that supposedly came from you. Who talks to that customer? Who decides what you actually say? Is legal or outside counsel in the loop? And quietly underneath all of it: who is writing any of this down as it happens?

The questions that expose the real gaps

Run the scenario honestly and the same handful of gaps tend to surface, regardless of how the specifics play out.

The first is authority. Who can act without waiting for sign-off? Most small teams discover that the honest answer is "we're not sure," or worse, "only one person, and it happens to be whoever's account just got taken over." When the person with the access is also the person who is compromised or unreachable, the response stalls exactly when speed matters most.

The second is visibility. How would you even know? The attack in the walkthrough hid itself with a forwarding rule. If nobody is watching for that, the first sign of trouble is a customer asking why their bank details changed, which is far too late.

The third is communication. Who talks to the bank, and who talks to customers? And where does that contact list live when email is the thing you cannot trust? This is the out-of-band problem: your normal way of reaching people may be the channel the attacker is sitting in.

That authority gap is the one worth sitting with. Detecting the attack is only half the job. Someone has to be watching at the moment it happens and be allowed to act before the money clears. That is the difference between a plan that contains an incident and one that merely documents it.

Write down what broke

A tabletop that ends when everyone leaves the room did not accomplish much. The real output is a short after-action note, written while the discussion is fresh: what worked, what did not, what surprised you, and a single owner and a date for each gap you found.

Keep it short and specific. "Nobody knew the bank's after-hours number" becomes "Finance to add the bank fraud line to the out-of-band contact list by month-end." "Only the CTO can lock an account" becomes a decision about who else gets that authority and how. You do not need a formal report. You need a list of fixes with names next to them. CISA's packages even include an after-action report template if you want a starting structure.

Then run it again in a few months, ideally with a different scenario. The first tabletop tells you where the plan breaks. Re-running it tells you whether you actually fixed anything. A finding that dies in a document did not fix a thing.

Where this connects to the rest of your security

A tabletop is valuable on its own, and you can organize your first one this week with the free resources above. But the gaps it surfaces are not abstract. They point straight at the two things that make a response actually work.

The first is authority to act. The recurring question in the walkthrough, who is allowed to do that right now, is the gap that pre-arranged response is built to close. Real response means the access and the go-ahead are agreed before anything goes wrong, so when an account is taken over at 2am, someone can revoke the sessions, delete the rules, and lock the account without waiting for a person who is asleep or compromised. That is the work our Managed Detection and Response team does.

The second is the plan itself. A tabletop pressure-tests your incident response plan, and a documented, tested plan is exactly what an auditor asks to see for SOC 2 and similar frameworks. Keeping that plan current, mapped to owners, and actually exercised is the managed compliance work we do.

Running the drill is step one, and you can do that now. Having a team that can act on what the drill finds, and a plan that survives both a real incident and an audit, is step two.