Nobody wants to find out how their incident response plan performs for the first time during an actual attack.
That sounds obvious. But most organizations haven’t practiced their response even once. They have a plan — or something that resembles one — sitting in a shared drive somewhere. Leadership has seen it. Maybe IT reviewed it. But the people who would actually be in the room at 2 am during a ransomware attack have never walked through what they’d do.
That gap is where real damage happens. Not the breach itself, necessarily. The damage comes from the confusion, the miscommunication, the wrong decisions made under pressure because nobody had ever rehearsed what “right” looks like.
Tabletop exercises fix that.
What a Tabletop Exercise Actually Is
A tabletop exercise is a facilitated, discussion-based session where your team walks through a simulated security incident in real time. No systems are touched. Nothing is live. Everyone sits around a table — or a video call — and works through a realistic scenario together, making the decisions they’d make if it were real.
The point isn’t to catch people out. It’s to surface what your organization doesn’t know about its own response before a real attacker does.
A well-designed exercise puts a specific, realistic threat in front of your team. Ransomware has spread across your network. A data breach involving employee records. A phishing attack that’s compromised an executive’s email account. The facilitator introduces the scenario and injects new information as the exercise unfolds — the attacker has moved laterally, a third vendor is also affected, and the CEO wants a statement in 30 minutes. Your team responds to each development the way they would in reality.
What comes out of that conversation is almost always more valuable than what anyone expected going in.
What You Find Out That You Didn’t Know
The organizations that do tabletop exercises for the first time are rarely prepared for what they discover. Not because their security is terrible — often it isn’t — but because the gaps that exercises expose are rarely the technical ones. They’re the human and process ones.
You find out that two people both think they’re responsible for notifying clients, which means neither of them has a clear process for doing it. You find out that your incident response plan references a contact list that hasn’t been updated in two years. You find out that your legal team and your IT team have completely different assumptions about what the timeline looks like. You find out that the executive who would be approving public statements during an incident has never actually read the communication protocol.
None of those are things you’d find in a vulnerability scan. None of them shows up in a penetration test report. They only come out when people are actually talking through what they’d do — under the simulated pressure of a real scenario.
That’s why the NIST framework, ISO 27001, SOC 2, HIPAA, CMMC, and most cyber insurance policies either require or strongly expect evidence of incident response testing. A plan that has never been tested is not really a plan. It’s a document.
The Specific Gaps Exercises Tend to Uncover
After running through dozens of exercises with organizations of different sizes and industries, the same types of gaps come up repeatedly.
Communication breakdowns.
Who calls whom? Who has everyone’s personal cell numbers when corporate systems might be down? Who talks to the press? Who talks to clients? Who talks to regulators? Most plans have vague language about “notifying stakeholders.” Exercises force you to figure out exactly what that means in practice — and whether the people responsible have what they need to do it.
Decision authority that nobody has claimed.
During a ransomware incident, someone has to decide whether to pay. Someone has to decide when to bring systems back online. Someone has to decide whether to notify law enforcement. These aren’t IT decisions — they’re business decisions. But until you run through the scenario with leadership in the room, it’s often unclear who actually has the authority to make them.
Third-party dependencies nobody had mapped.
Your incident affects a vendor who has access to your systems. Or a vendor discovers they’ve been breached, and your data was in scope. Your plan probably doesn’t account for this specifically. Exercises are where you figure out what your contract with that vendor actually requires you to do — and whether anyone knows who to call there.
Regulatory timelines that aren’t built into the plan.
HIPAA gives you 60 days to notify affected individuals after discovering a breach. CMMC contracts require reporting to the DoD within 72 hours. Some state breach notification laws require notification within 72 hours of discovery. Most teams, when they run through an exercise, realize their existing procedures don’t account for these timelines specifically. That’s a problem to solve in a tabletop exercise, not in the middle of an actual incident.
Backup and recovery assumptions that haven’t been tested.
Teams often assume their backups are clean and restoration will take a predictable amount of time. Exercises surface the questions: when were backups last tested? How long does full restoration actually take? Is there a clean backup that predates the compromise? The answers are sometimes different from what leadership expects.
Who Needs to Be in the Room
This is one of the most important decisions you’ll make when designing an exercise, and it’s also one of the most commonly mishandled.
Incident response is not just an IT problem. A tabletop exercise that only involves your technical team will only test your technical response. It won’t test your communications response, your legal response, your executive decision-making, or your client notification process.
The most valuable exercises include representation from IT and security, legal counsel, communications or PR, finance (because ransomware payments and insurance claims involve them), HR (because insider threats and employee data breaches require them), and at least one executive who would be involved in major decisions.
For nonprofits, that might mean your Executive Director or COO rather than a C-suite full of executives. The point is that the people making decisions during a real incident are the same people practicing in the exercise — not delegates who’ll have to brief someone else after the fact.
How Often Should You Run Exercises
At a minimum, once a year. Most security frameworks and cyber insurance carriers expect annual evidence of incident response testing.
In practice, the organizations with genuinely strong response capabilities run them more frequently than that. Twice a year gives you the chance to test a different scenario each time and see whether improvements from the last exercise have actually taken hold. After any significant infrastructure change, acquisition, or major staffing shift, an additional exercise is worth scheduling — your response plan may need updating, and an exercise will tell you where.
The first exercise is always the most revealing. The second one, after you’ve addressed what you learned, shows whether your team has actually improved.
Getting Leadership to Prioritize It
The common obstacle isn’t that organizations don’t understand why tabletop exercises matter. It’s that getting two hours of everyone’s calendar — including legal, communications, and executive leadership — feels like a bigger lift than it is.
The case is straightforward. An exercise costs a few hours and some planning time. An actual incident without a tested response plan costs weeks of disruption, potential regulatory fines, client attrition, and reputational damage. The cyber insurance premiums you’re paying almost certainly assume you have a tested response capability. If your incident response plan has never been tested, your organization isn’t actually prepared — it has a document that suggests it is.
Most leadership teams, once they’ve been through even one well-run tabletop exercise, schedule the next one before the debrief is over.
How CISOSHARE Runs Tabletop Exercises
CISOSHARE builds and facilitates tabletop exercises as part of its incident response management services. Their approach starts with understanding your organization’s specific environment — your industry, your data, your vendor relationships, and the threats most relevant to your situation. The scenarios they design aren’t pulled from generic templates. They’re built to mimic threats your organization would actually face.
As part of their incident response program, CISOSHARE develops two separate playbooks for each engagement: one for the technical incident response team, and a second for stakeholders and the executive team. Tabletop exercises test both. Technical responders practice their containment and eradication procedures while executives practice the decisions they’d make about communications, payments, regulatory reporting, and business continuity.
Exercises identify capability gaps and highlight areas for improvement in response plans and procedures. After each session, CISOSHARE provides a debrief with specific, prioritized recommendations — not a general observation that communication could be better, but concrete changes to your plan, your playbooks, and your contact protocols.
For a foundational guide to building the response plan your exercises will test, see our Incident Response Planning guide. If you’re building your security program from the ground up and want to understand how incident response fits into the bigger picture, the security program guide covers the full framework. And for organizations worried about specific threats like ransomware, CISOSHARE’s ransomware preparedness program is designed specifically for that scenario.
FAQ
How long does a tabletop exercise take?
Most tabletop exercises run two to four hours for a focused scenario. More comprehensive exercises covering multiple scenarios or involving large teams can take a full day. The preparation and debrief add time, but the exercise itself is typically a half-day commitment.
Do we need an outside facilitator?
You can run a basic exercise internally, but an outside facilitator adds significant value. They bring realistic scenarios your team isn’t expecting, they inject complications that force genuine decision-making, and they observe dynamics that internal facilitators often miss. They also provide an objective debrief that internal teams can’t.
What scenarios should we test first?
Start with the threat most likely to affect your organization. For most organizations, ransomware is the right first scenario — it’s the most common and the most disruptive. From there, branch into scenarios specific to your industry and data types.
