Your organization has an incident response plan. It covers detection, containment, eradication, recovery, and post-incident review. The escalation paths are documented. The communication templates are ready. The contact list for external counsel and forensics firms is current.
The first alert comes in at 2:47 AM on a Saturday. The on-call engineer can’t reach the security lead. The runbook assumes access to a logging platform that’s been down for maintenance since Friday. The “initial assessment” checklist asks the responder to categorize the incident by type, but the alert is ambiguous — it could be a misconfiguration, a compromised credential, or a false positive from a noisy detection rule.
The plan that took four months to write does not cover any of this.
What Plans Are Written For
Incident response plans are written for incidents that closely resemble the examples in the templates those plans are based on. The NIST 800-61 framework. The SANS incident handling guide. The tabletop exercise scenario your team ran last quarter, which was a ransomware simulation with clean initial indicators.
Real incidents are messier in two consistent ways: they start ambiguously, and they surface organizational problems that the plan assumed away.
The ambiguity problem is structural. An incident that announces itself clearly — a ransom note on every screen, a confirmed breach notification from a third party — is an incident that’s already well past initial response. The earliest detection signals are ambiguous by nature. They could be incidents. They’re often not. The plan’s “confirm this is actually an incident” step collapses in practice because there is no reliable way to confirm it without doing containment work that affects production systems, which requires approval, which requires waking people up, which requires judgment calls the plan says to escalate but doesn’t say how to make.
The Organizational Reality Gap
The organizational problems that surface during incidents are the ones that existed before the incident and were never the incident response team’s job to solve.
Unclear ownership of systems. The alert fired on an IP address in a network segment that was migrated to a new team three months ago. The old team thinks the new team owns it. The new team thinks it’s still being transitioned. Nobody is sure whether the system is in scope for the production security controls.
Access that doesn’t exist when needed. The forensic investigation requires access to a logging system that requires a change request ticket, which requires a manager approval, which requires the manager who is on vacation. There is an emergency access procedure. Nobody has tested it.
Communication that doesn’t go where it should. The plan says to notify legal counsel when data exfiltration is suspected. Legal counsel’s contact in the plan is an individual attorney who changed firms. The backup contact is the general counsel’s main line, which goes to a reception system during off-hours.
None of these problems are incident response problems. They are pre-existing organizational conditions that the incident response plan implicitly assumed were solved. They weren’t.
Why Tabletops Don’t Find This
Tabletop exercises are valuable for testing decision-making logic and communication patterns. They are poorly suited to surfacing operational dependencies that don’t exist.
A tabletop runs in a conference room with the people who are supposed to be in the response. The facilitator presents scenarios. Participants walk through what they would do. Nobody discovers that the logging system doesn’t have the API endpoint the plan assumes, because nobody is actually querying the logging system.
Full simulation exercises — red team versus live response, or purple team exercises with real system interaction — find operational dependencies. They are more expensive and disruptive, which is why most organizations run tabletops and call their exercise program complete.
The gap between what tabletops test and what real incidents expose is where most incident response failures originate.
The First Hour Problem
Incident response outcomes are disproportionately determined in the first hour. The initial containment decision — isolate this system now, or keep it running and watch it — shapes everything that follows. Getting that decision wrong is recoverable. Getting it wrong while also losing thirty minutes to confusion about who is authorized to make it is less recoverable.
Most incident response plans treat the first hour as a classification and escalation problem. Confirm it’s an incident, categorize it, escalate to the right people. This logic is correct in principle. In practice, the first hour is a chaos management problem, and the plans that help in chaos are short, specific, and pre-validated against the actual tools and systems that will be used.
The thirty-page incident response plan, carefully approved and stored in the document management system, is not the thing that helps in the first hour. The two-page quick reference card, the pre-authorized emergency access procedures, the validated contact list — these are what help.
Bottom Line
Incident response plans are useful documents. The process of writing them surfaces organizational assumptions that should be tested. The final artifact is rarely what matters when an incident is in progress.
What matters is whether the organization has resolved the dependencies the plan assumes, whether the people who will respond have practiced the real tools under realistic conditions, and whether someone with authority to make hard calls is actually reachable when the alert fires at 2:47 AM on a Saturday.
Test your plan against the worst time to have an incident. That’s when you’ll find out whether it works.