Seven Ways Tabletop Exercises Lie to You About Your Incident Response

Tabletop exercises have a reputation problem. Not because they're useless, but because a badly run tabletop can leave leadership convinced they're ready when they're not. That's arguably worse than skipping the drill entirely.

The most foundational error is starting without measurable objectives. Sharon Chand, Deloitte's US cyber defense and resilience leader, puts it plainly: generic ransomware scenarios with vague goals don't tell you whether your incident response plan works. They tell you whether your people can improvise confidently. Those are different things. Chand recommends treating each session as a test of specific capabilities — escalation paths, legal notification triggers, executive decision authority — rather than a loose walk-through of "what if we got breached."

The second trap is testing scenarios your team already handles well. Ayush Raj Jha, a senior software engineer at Oracle Health, describes participating in clean, well-structured ransomware tabletops where everyone performed perfectly. Months later, a real multi-region DR failure produced conflicting health statuses from two systems simultaneously, and no one could agree whether failover had actually occurred. That scenario had never appeared in any exercise. The failure mode wasn't panic — it was paralysis, because the real incident looked nothing like the practice one.

Give people incomplete information and conflicting signals. That's not cruelty; that's fidelity.

Jason Stading, a director at ISG, identifies a related problem: scenarios built around hypothetical threats rather than the organization's actual risk profile. When a scenario feels irrelevant, participants spend the session debating whether the attack vector is realistic instead of working through their response. The participant list matters here too. Stading notes that security and IT are obvious inclusions, but legal, communications, HR, and operations all belong in the room.

Blake Cifelli, senior incident response advisory consultant at GuidePoint Security, flags a subtler failure: stakeholders who disengage because the technical architecture in the scenario doesn't hold together. If the attack chain isn't plausible given the organization's actual environment, key participants write the whole exercise off as a compliance checkbox. Which, fair.

Ensar Seker, CISO at SOCRadar, describes what he calls the "happy path" problem — scenarios with a predefined correct answer that participants are gently steered toward. That tests process recall. It does not test decision-making under pressure, which is where real incidents break down.

Michel Sahyoun, chief solutions architect at NopalCyber, pushes for granular detail: a compromised domain controller, encrypted file shares tied to finance, an alert that triggers at 2:00 a.m. on a holiday weekend. Specificity creates friction. Friction surfaces gaps in tooling, unclear ownership, and broken communication chains — exactly the things worth finding before an actual incident.

Finally, Aparna Himmatramka, a security engineering manager at Amazon, warns that even well-designed scenarios build false confidence when they ignore the handoffs between teams. Interdependencies are where real incidents metastasize. A tabletop that treats each function in isolation is rehearsing a version of reality that doesn't exist.

The common thread: exercises optimized to feel good over exercises optimized to find gaps. Fix the objective first; everything else follows.