Rehearsed for the Wrong Disaster: How Enterprise Incident Response Programs Miss the Threats That Actually Strike

Every year, enterprise security teams across the United States run through carefully choreographed incident response exercises. Red teams attack, blue teams defend, and after-action reports are filed with a degree of procedural satisfaction that reassures leadership and satisfies compliance frameworks. What these exercises rarely produce, however, is genuine readiness for the incidents that will actually unfold.

The distinction is not a matter of effort or investment. Many organizations dedicate substantial time and budget to these programs. The problem is architectural: the scenarios being rehearsed are optimized for auditability rather than authenticity. When the real incident arrives — and it will — it rarely resembles the scripted version.

The Compliance Incentive and Its Unintended Consequences

Incident response programs exist, in large part, because regulatory frameworks require them. Standards such as SOC 2, HIPAA, PCI-DSS, and various state-level data protection statutes mandate documented response procedures and, in many cases, evidence of regular testing. This creates a powerful incentive to design exercises that produce clean documentation rather than uncomfortable findings.

The result is what might be called procedural theater: drills built around known variables, predictable timelines, and attack vectors that security teams are already equipped to handle. Tabletop exercises simulate ransomware scenarios that mirror last year's headlines. Penetration tests probe the perimeter infrastructure that was hardened after the last engagement. The unknown unknowns — the lateral movement paths through a legacy ERP system, the undocumented API endpoint connecting a third-party marketing platform to core customer data — go untested because they are difficult to script and uncomfortable to surface.

Compliance, in this context, becomes a ceiling rather than a floor.

Where the Real Attack Surface Lives

Enterprise digital environments are rarely the clean, well-documented architectures that appear in network diagrams. They are the product of years of acquisition, departmental initiative, shadow IT, and vendor relationships that evolved faster than governance could follow. The actual attack surface of a large enterprise frequently includes:

• Legacy systems running on unsupported software stacks, often integrated into core workflows because migration costs were repeatedly deferred.
• Third-party SaaS platforms with privileged access to enterprise data, governed by vendor security policies that may not align with internal standards.
• Undocumented API integrations established by individual business units without formal security review.
• Contractor and partner access credentials that were provisioned for a specific project and never decommissioned.
• Content delivery and digital experience platforms that sit at the intersection of public-facing infrastructure and internal data systems.

None of these appear prominently in standard incident response playbooks. They are, however, precisely the entry points that sophisticated threat actors have learned to target. The 2023 MOVEit breach, which affected hundreds of organizations across the US, exploited a file transfer tool that existed at the periphery of many enterprises' formal security perimeters — known to operations teams, unknown to incident response planners.

The Scenario Design Problem

Effective incident response requires not only knowing what to do when an attack occurs, but understanding the actual conditions under which the organization will be operating when it does. Most enterprise drills fail on this second dimension.

Scenarios are typically designed by internal security teams or external consultants who have access to the same documentation that the organization's defenders use. This creates a closed loop: the people building the test know what the defenders know, and the exercise confirms existing knowledge rather than probing its limits.

Real adversaries operate with different information. They conduct reconnaissance across the organization's external footprint — job postings that reveal technology stacks, GitHub repositories that expose internal tooling, vendor directories that map third-party relationships. They identify the seams between systems rather than attacking hardened surfaces directly. An incident response program that does not account for this reconnaissance-driven approach is preparing for a fundamentally different kind of attack than the one it will face.

Building Response Frameworks That Reflect Reality

Correcting this gap requires a deliberate shift in how incident response programs are designed, measured, and governed. Several principles are worth considering:

Expand the threat model beyond the perimeter. Modern incident response planning must account for the full ecosystem of systems, vendors, and integrations that constitute the enterprise's operational environment. This means conducting honest asset inventories — including the systems that were inherited through acquisitions or built outside formal IT channels — and ensuring that response procedures address failures within those environments.

Introduce genuine uncertainty into exercises. The most valuable drills are those that surface information the security team did not already possess. This requires engaging external parties — threat intelligence firms, specialized red teams, or sector-specific information sharing organizations — who can introduce attack vectors drawn from actual threat actor behavior rather than internal assumptions.

Test the human and process dimensions, not just the technical ones. A significant proportion of incident response failures occur not because the technical playbook was wrong, but because the communication and decision-making processes broke down under pressure. Exercises should stress-test the escalation chain, the vendor notification process, and the coordination between technical teams and legal, communications, and executive leadership.

Measure response quality, not response completion. Current metrics tend to reward organizations for completing drills and documenting findings. More meaningful measurement focuses on mean time to detect, mean time to contain, and — critically — the accuracy of initial threat characterization. An organization that correctly identifies the nature of an attack within the first hour is in a fundamentally better position than one that completes a drill on schedule but misclassifies the incident type.

Revisit third-party risk continuously, not periodically. Vendor security assessments conducted at contract signing or annual review cycles do not reflect the dynamic nature of third-party risk. Integration architectures change, vendor platforms are updated, and the access privileges established for one use case frequently persist long after that use case has evolved. Continuous monitoring of third-party access and integration behavior is no longer optional for organizations operating at enterprise scale.

The Organizational Will to Be Uncomfortable

Perhaps the most significant obstacle to effective incident response is not technical but cultural. Exercises that surface genuine vulnerabilities — particularly in systems owned by influential business units or in vendor relationships managed at the executive level — create organizational friction. The path of least resistance is to design drills that confirm existing capabilities rather than challenge existing assumptions.

Enterprise leadership that is serious about security readiness must actively create space for uncomfortable findings. This means decoupling incident response evaluation from compliance reporting, protecting the teams that surface difficult findings from political consequences, and treating the discovery of an unknown vulnerability as a program success rather than a program failure.

The organizations that emerge from real incidents with their operations and reputations intact are rarely those with the most elaborate drill programs. They are the ones that built response capabilities against the threats they were actually facing — and had the institutional honesty to acknowledge the difference.