Discussion-based, low-stress simulations during which IT, legal, and other key leadership stakeholders walk through theoretical scenarios to test their preparedness for cyber incidents is a popular and highly useful tool. Yet unless tabletop training is properly handled, the results can be misleading and potentially destructive.
When your organization’s incident response training consistently fails to meet its goals, it opens the way to an array of often unanticipated threats. Fortunately, running an effective tabletop isn’t as challenging as responding to the real deal. Here’s a rundown of the seven most common tabletop exercise mistakes to avoid.
No clear set of objectives
The biggest mistake is to run a tabletop without clear, measurable objectives tied to realistic business decisions, says Sharon Chand, Deloitte’s US cyber defense and resilience leader.
“In practice, this usually shows up as a generic ransomware or insider-threat scenario, accompanied by vague goals and no firm agreement on what ‘good’ actually looks like,” she explains. “This causes the exercise to drift, while rewarding confident improvisation over real process quality, and leaves leaders unable to tell whether the incident response plan actually works.”
Instead, Chand advises cyber and IT leaders to provide sharp guidelines and directives about what the tabletop seeks to accomplish.
“When leaders treat the session as ‘let’s walk through a breach scenario’ instead of ‘let’s test escalation, legal notification, executive decision rights, and recovery prioritization,’ the exercise quickly devolves into a discussion theater rather than a readiness test,” she says.
Testing scenarios you already know how to handle
Ayush Raj Jha, a senior software engineer at Oracle Health, recalls a time when he was involved in tabletops where every incident was a clean, well-defined ransomware event with obvious decision points.
“Everyone performed great, yet three months later we had a real partial failure in our multi-region DR setup, where the failure was ambiguous,” he says. Two systems reported conflicting health statuses, and nobody could agree on whether we had actually failed over or not. “That scenario,” Jha says, “had never been in any tabletop.”
The damage isn’t that people panic; it’s that they freeze because the real incident doesn’t look like the practice one, says Jha, who recommends making the scenario deliberately ambiguous from the start.
“Give people incomplete information and conflicting signals and see how they make decisions under uncertainty,” he advises. “Because that’s what real incidents actually look like.”
Failing to design business-relevant hazards
Many IT leaders view regular tabletop exercises as a routine obligation rather than as an essential security task, says Jason Stading, a director with technology research and advisory firm ISG. As they minimize the exercise’s importance, these individuals fail to design scenarios around their organization’s real risks, decision points, and people.
“In practice, this usually shows up in two ways: choosing a scenario that’s not realistic or relevant to the organization, and failing to include the right stakeholders in the exercise,” he says.
When an indifferent scenario fails to address to the organization’s real-world hazards, participants often get stuck on debating whether something could happen instead of focusing on what they should be doing next, Stading says. A better approach, he states, is thoughtful, collaborative planning conducted before the exercise starts.
“The scenario should be built around the organization’s actual environment, business priorities, past incidents, and realistic threats seen in the industry,” Stading recommends.
The participant list should include everyone who would be involved in a real event, such as security, IT, legal, communications, HR, operations, and perhaps even executive leaders.
“After each exercise, leaders should capture where decisions stalled, where ownership was unclear, and which voices were missing, and then use these lessons to improve the next scenario,” he says.
Losing stakeholder buy-in due to lack of technical detail
Essential stakeholders often don’t bother to participate in training simulations because they view the attack chain as either impractical or implausible given the project’s sub-par architecture and environment.
“The stakeholders simply view the activity as a waste of time,” observes Blake Cifelli, senior incident response advisory consultant at security services provider GuidePoint Security. “Everything presented in the simulation should make sense at a technical level and logically connect to one another,” he advises.
“For a tabletop, much like any other assessment, you get as much out of it as you put in,” Cifelli says. “If you view the exercise as a compliance checkbox and put in only a minimal amount of effort for customization and participation, you will hit the security baseline, but your response team and program won’t benefit much from it.”
Emphasizing recall over decision-making
A common mistake is treating tabletop exercises as scripted, compliance-driven activities instead of realistic, decision-driven simulations, says Ensar Seker, CISO at threat intelligence and digital risk monitoring software firm SOCRadar.
“Many organizations design scenarios with a predefined ‘happy path,’ in which participants are subtly guided toward expected answers instead of being forced to deal with the ambiguity, conflicting signals, and incomplete information, conditions that define real incidents,” he says.
Such an approach can create a false sense of readiness, Seker says. “Teams may appear coordinated during the exercise, but when a real incident occurs, they struggle with uncertainty, escalation timing, and cross-functional communication,” he notes. “In effect, the organization tests process recall instead of decision-making under pressure, which is where most failures actually occur.”
Favoring the conceptual over the practical
Michel Sahyoun, chief solutions architect at managed cybersecurity service provider NopalCyber, warns against creating tabletop scenarios that are too theoretical and devoid of rich, real-world detail.
“For example, an exercise might be framed around a ransomware incident, but provide very few concrete details,” he says. This often results in participants who tend to respond in abstract, high-level terms rather than engaging with the specific actions and decisions required in a real incident response.
Highly detailed scenarios can create the kind of friction points you want to test, Sahyoun says, noting that when the moderator introduces specifics, such as a compromised domain controller, encrypted file shares tied to finance, or an alert triggered at 2:00 a.m. on a holiday weekend, teams can become confused.
“When facing this type of situation, participants must grapple with incomplete information, competing priorities, and time pressure,” he advises. “This is where gaps in tooling, unclear ownership, and breakdowns in communication start to surface.”
The fundamental problem with a theory-driven approach is that it creates a false sense of preparedness, Sahyoun says. It’s possible for a team to arrive at a highly complex solution yet still get lost in the details. Which systems get isolated first? Who has the authority to take them offline? What happens if those systems support critical business functions? Who drafts the stakeholder communication, and how quickly can it be approved?
“Without these details, participants aren’t truly testing their readiness; they’re just validating that they understand the playbook at a conceptual level,” Sahyoun says.
Overlooking the interconnected nature of incident response
Aparna Himmatramka agrees that generic scenarios build false confidence. But the Amazon security engineering manager adds that false confidence also stems from not stress-testing the handoffs and interdependencies specific to your business.
“Your security team walks away thinking they can handle an incident, but they never actually get to practice navigating the specific dependencies, communication chains, and system interdependencies that would actually be in play during a real breach in your environment,” she says.
Then what happens when a real incident hits? “Well, the response plan falls apart at exactly the points the tabletop never touched — such as the handoff between your cloud team and your SOC, the escalation path when your M&A integration environment is compromised, or the decision tree when a third-party vendor is the entry point,” she says. “You’ve trained your team for a scenario that doesn’t exist at your company.”
Engineer the scenario from your actual risk register, Himmatramka advises. “Identify the top three to five threats specific to your organization, map them against your real architecture and team structure, and build the exercise around them,” she says.
More on tabletop exercises: