Your Tabletop Exercise Isn't Testing What You Think It Is

May 18, 2026 • 6 min read

incident-response tabletop-exercises security-leadership

There’s a version of the tabletop exercise I’ve seen at almost every company I’ve assessed. Someone reads a scenario out loud. The IR lead walks the runbook. Department heads nod and confirm they would do the thing the runbook says they would do. Everyone leaves feeling pretty good about themselves.

That tabletop is theater.

It’s not useless. It checks a box for examiners. It confirms the runbook exists. But it does not test response capability, and it does not find the cracks. A useful tabletop is supposed to be uncomfortable. If yours isn’t, you are not testing the right things.

What scripted tabletops actually test

When you run a scripted tabletop, you are testing whether people can follow a runbook when they already know the scenario, the role they’re playing, and the expected outcome. That’s a reading exercise.

Real incidents don’t show up labeled. You get a Slack ping from a vendor saying “we noticed something unusual.” You get a customer asking why an account email got changed. You get a SIEM alert with three possible root causes and a tier-1 analyst who hasn’t seen this pattern before. The runbook cannot tell you which one is the start of an incident. A person has to. And that person is making decisions with partial information, under pressure, while their inbox is filling up.

Walking the runbook in a conference room does not test that skill at all. It tests memory.

The four things that actually break

These are the things I see fall apart during real incidents that almost never come up in a scripted tabletop:

Decision rights. Who is authorized to take a production system offline? Who decides legal needs a heads-up? Who can speak to a customer? In a real incident the org chart goes useless fast, because the person who normally makes that call is in a meeting, on PTO, or hasn’t been pulled into the channel yet. Someone has to decide right now, and most teams haven’t decided in advance who that someone is.

Information asymmetry. The IR team has the technical detail. Legal has half a picture. Comms is still waiting for someone to brief them. Customer support is taking calls with no script. Real response is the constant work of keeping enough people informed to make decisions, without burning the responders’ time on briefings every twenty minutes.

Communication when nothing is confirmed. Customers, regulators, employees, the board. Each one needs a different message at a different time. Most companies have no draft language for the first 24 hours, when the only honest message is some version of “we are still figuring this out.”

Time. Real incidents take days. Tabletops take an hour. The team gets fresh coffee. The real test isn’t whether your team can stay sharp for 60 minutes. It’s whether they can stay sharp at hour 22 of a five-day incident, when the third shift change has happened and someone on the comms team is starting to cry in the kitchen.

How to run one that actually hurts

You don’t need a vendor or a 40-page scenario document to run a useful tabletop. You need a few uncomfortable design choices.

Do not tell people what is happening. Tell the IR lead they have to figure it out. Don’t drop the whole scenario at once. Feed it in fragments, in the same shape a real incident comes in.

Pull people out. Halfway through, tell the IR lead the CISO is on a flight and unreachable. Tell legal their lead is at a doctor’s appointment. Force the team to find the backup decision-maker in real time, because they will be doing that during a real incident.

Make people write what they would actually send. Not a description of what they would send. The actual customer email. The actual board update. The actual regulatory notice. Have someone read it back to the room. You will find problems immediately.

Run part of it asynchronously. The world does not pause for your team. Run a piece of the exercise over Slack on a normal workday, with normal meeting load. See what attention looks like when people aren’t sitting around a table.

Time-box decisions. If the team cannot agree on a course of action in ten minutes, force them to pick one and move. Real incidents do not wait for consensus. Your response capability is partly your team’s ability to decide and adjust, not their ability to decide perfectly.

The part nobody wants to admit

Most teams don’t run tabletops that hurt because the people sponsoring them don’t want them to hurt. Boards want to hear the team did well. Examiners want to see the exercise was held. Executives want a tidy report with a green checkmark on it.

A good tabletop should produce a list of things that didn’t work, and it should be uncomfortable to share. If the after-action report reads like a success story, the tabletop was wrong. The exercise that finds nothing isn’t a sign your team is ready. It’s a sign your scenario was too easy or too predictable, and you wrote it that way on purpose.

That is a culture problem, not an IR problem. But it’s worth naming, because it is the reason the same companies keep running the same exercises and getting the same clean reports right up until the day they have a real incident and realize none of it stuck.

What to do this week

You don’t need a perfect tabletop. You need one that finds the next thing your team cannot do yet. Pick one assumption you have made about how response works at your company. Maybe it’s that the right people will always be reachable. Maybe it’s that legal will be in the room within an hour. Maybe it’s that comms knows what to say. Build a scenario that breaks that assumption. Watch what happens.

That’s the exercise worth running.

If you want help designing a tabletop that actually tests your team, or running one for you, reach out to Vaughn Cyber Group. We build IR exercises to find the cracks before someone else does.