Key Takeaways
- Most tabletop exercises validate performance instead of exposing real gaps in incident response.
- For exercises to be effective, they must introduce friction, ambiguity, and pressure to reflect real-world incidents.
- Limiting the scope of the exercise to a few critical scenarios and defining success as finding problems rather than looking good can lead to more meaningful and actionable insights.
- Cross-functional participation, not just that of technical teams, is essential to accurately test organizational response.
- True resilience is proven through actual recovery testing, not just discussion-based scenarios.
There is a moment most security leaders recognize, even if they do not say it out loud. The tabletop just wrapped. The team is filing out. Everyone looks reasonably satisfied. And somewhere in the back of your mind, a quiet question surfaces: Did we actually learn anything?
If you are honest, the answer is often no.
That is not because tabletop exercises are a bad idea. They are one of the most valuable tools a security leader has. The problem is how most organizations run them – and what they are actually measuring when they do.
The Performance Trap
The most common mistake in tabletop exercises has nothing to do with the scenario. It has to do with the goal. Most teams, consciously or not, build exercises designed to demonstrate competence rather than discover gaps.
The scenario generally follows a clean arc. Information arrives in a logical sequence. The right people say the right things. Everyone feels prepared. And that feeling – confident, well-rehearsed, almost collegial – is exactly the problem.
Real incidents do not run on clean arcs. They arrive with incomplete information, conflicting signals, unavailable people, and a business demanding answers faster than the facts support. If your tabletop does not create that kind of friction, you have not tested incident response. You have practiced a conversation.
When the exercise is designed to validate rather than stress-test, a second problem follows: People stop being honest. Nobody says, “I don’t know who owns that decision” or “we have never actually tested that recovery path.” They say what sounds right. And the gaps that should surface in a controlled environment stay hidden until they surface in a real one.
What a Good Exercise Actually Tests
Before you build a scenario, you need to answer a simpler question: What do you actually want to learn? Not 20 things. Three or four.
Can your team make a shutdown decision fast enough, and does everyone know who has the authority to make it? When security, IT, legal, and communications are all in the room with conflicting priorities, can they actually reach decisions together? Can you explain the business impact of an incident clearly enough for leadership to act – not just understand? And if you had to restore a critical system in the next four hours, could you really do it?
Once you know what you are testing, build a scenario with real friction. Make a key person unavailable mid-exercise. Introduce a customer escalation. Have a regulator ask a question the team cannot answer from the runbook.
Give people incomplete information and see how they make decisions anyway. The value is not in watching people succeed under pressure. It is in finding the places where the process breaks down while the stakes are still low enough to fix it.
Say this out loud at the start: Success today means finding problems, not looking good. That one sentence changes what people are willing to say in the room.
The People Problem
A tabletop that only involves security and IT is a technical conversation, not an incident response exercise. If legal is not in the room, if communications is not in the room, if business owners and executive leadership are absent, you are not testing how your organization actually responds to a crisis. You are testing how a subset of smart people talk through a hypothetical.
Real incidents are handled across the business. The exercise should reflect that.
Talking Through It Is Not Enough
This is where most organizations stop short. A paper exercise is important – but it is not confidence.
Talking through a recovery scenario tells you something. Actually restoring a system tells you something different. Can you bring identity back to a clean point in time? Can you validate that what you are recovering is trustworthy? Can you restore a Tier 1 application and confirm it comes back cleanly, without carrying the infection with it?
Those are not questions you can answer in a conference room. At some point, the plan has to meet the environment – and you need to know whether they match.
After the Exercise Ends
The debrief tells you whether the exercise mattered. If the hot wash is quiet, vague, or full of “good reminders,” the exercise did not push hard enough. A well-run tabletop should leave you with a short list of real findings, clear owners, and deadlines. If you cannot answer what broke, who is fixing it, and by when, you ran an event, not an exercise.
The goal was never to pass the exercise. It was to learn something important while the cost of being wrong was still just time.
Watch our recent episode of the STRIVE podcast, where I join my colleague Chris Mierzwa, Senior Director, Portfolio Marketing, for an in-depth conversation about tabletop exercises.
FAQs
Q: Why do most tabletop exercises fail to deliver real value?
A: Many exercises are designed to make teams look prepared rather than uncover weaknesses. This leads to scripted discussions that miss the unpredictability and pressure of real incidents.
Q: What should a tabletop exercise aim to achieve?
A: It should focus on answering a small number of critical questions, such as decision-making speed, ownership clarity, and recovery capability. This focus helps teams uncover meaningful gaps instead of surface-level insights.
Q: How can organizations make exercises more realistic?
A: Introduce uncertainty, missing information, and unexpected disruptions during the scenario. These elements force teams to think critically and act under pressure, closer to real incident conditions.
Q: Who should be involved in a tabletop exercise?
A: Beyond security and IT, teams like legal and communications, business leaders, and executives should participate. This enables the exercise to reflect how real incidents are managed across the organization.
Q: Why is talking through recovery not enough?
A: Discussion can highlight plans, but only real testing proves whether systems actually can be restored cleanly and quickly. Practical validation is necessary to confirm recovery readiness.
Q: What defines a successful tabletop exercise outcome?
A: A strong exercise results in clear findings, assigned owners, and defined timelines for remediation. If these are missing, the exercise likely did not challenge the team enough.
Chris Bevil is Principal, Global Cyber Resilience & AI, at Commvault.
