You've built an incident response plan. You've documented escalation paths, drafted communication templates, and mapped regulatory notification timelines. Then a breach happens, and the plan falls apart in the first 90 minutes.
The problem isn't that teams skip incident response planning. It's that most plans are designed to satisfy auditors, not to function under pressure. When companies like Coca-Cola, Ernst & Young, Craneware, and Abbott disclosed cyber incidents, the quality of their responses varied dramatically. The difference wasn't resources or sophistication. It was whether their plans had been stress-tested against the three questions that matter during containment: Does the attacker still have access? How did they get in? What did they take?
Here's where incident response planning consistently breaks down, and how to fix it before your next audit or breach.
Why These Mistakes Keep Happening
Most incident response failures stem from treating the plan as a compliance artifact instead of an operational runbook. Your ISO/IEC 27001 certification requires documented incident management procedures (Clause 6.1.3, A.5.24, A.5.25, A.5.26), and SOC 2 Common Criteria CC7.3 through CC7.5 demand incident response and communication controls. But meeting those requirements doesn't mean your plan will work when systems are offline and your legal team is asking whether you need to notify regulators in the next six hours.
The UK GDPR's 72-hour breach notification requirement creates a forcing function. You don't get to wait for perfect information. You need to know enough to assess whether personal data was compromised, and you need that clarity while containment is still underway. Plans that look comprehensive on paper collapse when they assume linear progression through phases, unlimited time for analysis, or perfect visibility into what happened.
Mistake 1: Building the Plan Around IT, Not Cross-Functional Coordination
Why it happens: Security teams own the technical response, so they write the plan. It focuses on forensics, containment, and system recovery because those are the problems security knows how to solve.
The consequence: When an incident escalates, legal needs to assess notification obligations, communications needs to draft stakeholder messages, and executives need to understand business impact. None of those teams know their role because the plan treats them as recipients of information, not active participants. You end up with three parallel efforts that don't coordinate, and regulatory deadlines slip while teams argue over what can be disclosed.
The fix: Map decision points, not just technical steps. For each phase of response, document who makes which decision and what information they need. If your legal team needs to determine whether the GDPR 72-hour clock has started, they need to know what data types were potentially accessed, not just that "an unauthorized party gained access to systems." Build that specificity into your detection and analysis procedures. Run tabletop exercises where legal, communications, and security all participate, and watch where coordination breaks down. ISO/IEC 27035-1 provides incident management guidance that explicitly addresses organizational coordination, not just technical containment.
Mistake 2: Writing Communication Templates That Can't Be Used Under Pressure
Why it happens: Compliance frameworks require documented communication procedures, so teams create templates for regulatory notifications, customer disclosures, and internal updates. The templates are thorough, covering all possible scenarios with careful legal language.
The consequence: When an incident occurs, the templates are too generic to use without extensive customization. Your customer notification template says "we experienced a security incident affecting [DESCRIBE DATA TYPES]" but doesn't help you determine what constitutes a meaningful description when you're 18 hours into an investigation and still don't know the full scope. Teams spend hours wordsmithing messages while the 72-hour notification window closes.
The fix: Build decision trees, not just templates. Create a matrix that maps incident types (unauthorized access, ransomware, data exfiltration, denial of service) to required notifications, responsible parties, and maximum decision timelines. For each notification type, document the minimum information required to send it and the process for updating it as facts develop. Your initial GDPR notification doesn't need to be complete; it needs to be timely and accurate about what you know. Template the structure, but script the decision process for what goes into each section. Test this by running an exercise where you draft actual notifications based on an evolving scenario, not a complete fact pattern.
Mistake 3: Assuming You'll Have Visibility Into What Happened
Why it happens: Incident response plans describe investigation procedures: collect logs, analyze network traffic, review system access, identify indicators of compromise. These procedures assume your logging infrastructure is intact and comprehensive.
The consequence: Attackers disable logging, operate in environments where logging was never configured properly, or use legitimate administrative tools that don't trigger alerts. You're 48 hours into an incident and still can't answer whether the attacker maintains access, what data was accessed, or when the compromise began. Your plan says "determine scope of compromise" but doesn't address what to do when you lack the telemetry to make that determination with confidence.
The fix: Document your visibility gaps now, before an incident. For each critical system, identify what you can and cannot see. If you can't track privileged access to a database containing personal data, that's a control gap (ISO/IEC 27001 A.8.2 requires privileged access rights management). Address it or document it as a known limitation in your risk treatment plan. During incident response, your plan should include explicit procedures for operating with incomplete information: How do you scope notifications when you can't confirm what was accessed? What's your threshold for assuming compromise when you lack definitive evidence? Build these decision criteria into your plan, and make sure your legal and executive teams understand them. This prevents the paralysis that happens when technical teams wait for certainty that won't arrive within your notification window.
Mistake 4: Treating Regulatory Requirements as Separate Obligations
Why it happens: Different regulations have different notification timelines, definitions, and triggers. GDPR requires 72-hour notification for personal data breaches. SEC rules require disclosure of material cybersecurity incidents. NIS2 has separate timelines for early warnings and final reports. Teams track these separately and try to determine which apply after an incident occurs.
The consequence: You spend the first 24 hours of an incident researching notification requirements instead of executing notifications. Regulatory deadlines conflict, and you're not sure whether you can satisfy one notification requirement without triggering another. Your incident response plan references "applicable regulations" but doesn't map them to specific incident types or system categories.
The fix: Pre-map your regulatory obligations to your asset inventory. For each system or data category, document which regulations apply and what triggers notification. If you process EU personal data, that system falls under GDPR's 72-hour rule. If you're a publicly traded company, material incidents affecting that system may require SEC disclosure. Build this mapping into your incident classification procedure so that when you categorize an incident, you automatically know which notification timelines are in play. ISO/IEC 27001 A.5.5 requires you to identify and address information security requirements in agreements with relevant interested parties, including regulators. Extend that analysis into your incident procedures.
Mistake 5: Never Testing Whether Executives Can Actually Execute Their Role
Why it happens: Tabletop exercises focus on technical response. Security teams walk through detection, containment, and recovery. Executives get briefed on the scenario but don't practice making decisions with incomplete information under time pressure.
The consequence: When a real incident occurs, executives don't know what decisions are theirs to make, what trade-offs they're being asked to evaluate, or what "we need a decision in the next two hours" actually means. They ask for more analysis, request additional briefings, or defer to technical teams on questions that are fundamentally business decisions (Do we notify customers before we have complete information? Do we take systems offline during business hours?). Response stalls while everyone waits for executive direction that isn't coming.
The fix: Run exercises where executives make real decisions with consequences. Present them with an evolving scenario and force decision points: You're three hours from the GDPR notification deadline, forensics isn't complete, but you have enough information to know personal data was likely accessed. Do you notify now or wait for confirmation? You can contain the incident by taking your primary application offline for 12 hours, or you can monitor for 24 hours while trying to maintain service. Which do you choose? Don't let them defer or ask for more information that won't be available in the timeframe. This is uncomfortable, but it's the only way to identify where your governance structure breaks down under pressure. Document the decision criteria that emerge from these exercises and incorporate them into your plan.
Prevention Checklist
Before your next audit or your next incident, validate these elements:
- Cross-functional tabletop exercise completed in the last six months, with legal, communications, and executive participation
- Incident classification matrix maps each incident type to specific regulatory notification requirements and timelines
- Communication templates include decision trees for determining what information is required before sending
- Visibility assessment documents what you can and cannot see in each critical system
- Executive decision points explicitly identified in the plan, with criteria for making decisions under uncertainty
- Regulatory notification requirements mapped to specific asset categories, not referenced generically
- Post-exercise review identified at least three gaps in coordination or decision-making authority
- Plan tested against the three core questions: Does the attacker still have access? How did they get in? What did they take?
Your incident response plan isn't a compliance document. It's the runbook your team will follow when systems are compromised, regulators are waiting, and you don't have time to figure out who makes which decision. Build it for that reality, not for the audit.
