Your Incident Response Tabletop Should Make People Uncomfortable

I've seen enough security plans to know that a document can look reassuring right up until someone has to use it. The problem isn't always that the plan is wrong. More often, the plan assumes that the right people will be available, that somebody will know who can authorize a disruptive action, and that the facts will arrive in a useful order. An actual incident is rarely that considerate. A tabletop exercise ought to expose those assumptions while the cost of getting something wrong is still a conversation rather than a prolonged outage.

A tabletop isn't a theatrical reading of a ransomware scenario. It's a controlled way to discover whether the organization can make decisions under uncertainty. NIST's longstanding exercise guidance distinguishes discussions, exercises, and tests and emphasizes defined objectives and evaluation, rather than treating participation as proof of readiness (Grance et al., 2006). Its newer incident-response guidance places response inside the broader system of governance, preparation, detection, recovery, and improvement (Nelson et al., 2025). Put those ideas together and you get a fairly demanding question: can the people, authorities, systems, and vendors named in your plan actually work together when the situation changes?

A good scenario has enough technical detail to create a plausible operational problem, but the attacker's fictional biography isn't the point. I would rather spend fifteen minutes on whether a team can isolate a critical identity service than forty-five minutes admiring a beautifully illustrated kill chain. The exercise needs an explicit decision that someone in the room owns. If nobody can name that person, we've found our first gap.

Take a simple case. Security operations has credible evidence that an administrative identity has been abused. Several systems may be affected. Disabling the account could interrupt production, but leaving it active may allow the attacker to keep moving. Who has authority to disable it? Who can assess the business consequence? Can the team distinguish a suspected compromise from a confirmed one? Does the person who approves the action understand what evidence is still missing? The point isn't to reward the fastest answer. It's to discover whether the decision can be made at all, and whether its assumptions survive challenge.

The NIST Cybersecurity Framework 2.0 gives organizations a useful language for connecting operational response with governance and risk decisions. Its Govern function matters here because authority, accountability, and risk tolerance are not details the SOC can invent in the middle of a crisis (Pascoe et al., 2024). A tabletop should make those responsibilities visible.

Incident response is full of handoffs: the analyst to the incident commander, security to infrastructure, infrastructure to a cloud provider, legal to communications, and the executive team to a board that wants a coherent answer. Every handoff creates an opportunity for delay, distortion, or an unauthorized action. The federal incident and vulnerability response playbooks provide a useful example of why standardized phases, roles, and escalation paths matter, even when a private organization will implement them differently (Cybersecurity and Infrastructure Security Agency [CISA], 2021).

I would give participants incomplete but realistic information. Perhaps the endpoint team sees suspicious activity, the identity team sees token use from an unexpected location, and a vendor reports an outage that might be unrelated. Nobody gets the entire picture immediately. Ask each group what it knows, what it believes, and what would change its assessment. That distinction is more valuable than forcing an early declaration that the company has been breached.

Then introduce a real constraint. The person who can authorize emergency network segmentation is unreachable. The outside counsel listed in the plan has changed firms. The backup contact number works, but the contract doesn't cover the service everyone assumes it does. These are hypothetical exercise injects, not claims about any particular organization. Their value is that they reveal dependencies the organization can correct before they become emergencies.

A tabletop that lets the security team shut down anything it wants is almost useless. Containment has consequences. Isolation can interrupt payroll, manufacturing, patient services, logistics, or customer access. On the other hand, delaying containment can widen the damage. The hard question is how the organization decides between imperfect options with limited evidence.