Most organizations believe they have an incident response plan. What they actually have is a documented assumption that, in the middle of a serious incident, the right people will know what to do. That assumption is rarely tested in a way that reflects how incidents actually unfold. The existence of a plan, even one that has been reviewed annually or exercised in a tabletop, is often mistaken for readiness. In reality, it is closer to a theory about how the organization hopes it will behave under pressure.
Traditional IRP testing tends to focus on procedural familiarity. Participants confirm they know their roles, that notifications occur in the right order, and that the plan can be referenced when prompted. These exercises are useful for validating that the document is understandable and that teams recognize their place within it. They do not, however, test how the organization behaves when information is incomplete, time is compressed, and the consequences of a decision are uncertain. Real incidents do not fail because a step was missed in a checklist. They fail when decision ownership becomes unclear, authority fragments, and hesitation is reinforced by incentives that quietly reward delay.
Incident response is often framed as a technical discipline, but the most difficult moments of an incident are rarely technical. They are moments of judgment. Someone must decide when containment is sufficient, when risk is being accepted, when escalation is necessary, and when external disclosure becomes unavoidable. These decisions are made with imperfect information and under real organizational pressure. Policies cannot make them. Plans cannot resolve them. People do, and they do so within the constraints of culture, hierarchy, and accountability structures that are usually invisible until they are stressed.
When incident response plans are tested only through low-pressure tabletop discussions, leadership behavior is largely unexamined. Time is paused, questions are collaborative, and no decision truly closes off alternatives. In that environment, it is easy to believe that authority is clear and that alignment will naturally emerge. During a real incident, those assumptions often collapse. Leaders hesitate, over-consult, or disengage entirely, not because they are negligent, but because they have never practiced making consequential decisions inside the conditions that demand them.
Testing an IRP at a meaningful level requires acknowledging that discomfort is a feature, not a flaw. Exercises must introduce ambiguity instead of resolving it, apply pressure instead of relieving it, and force decisions that feel premature or risky. The goal is not to arrive at the “correct” outcome, but to observe how the organization actually responds when clarity is absent. Where does ownership drift? Where does authority break down? What incentives shape behavior in ways no policy ever described? These are the signals that determine whether an organization can function during a real incident.
The risk of avoiding this level of testing is subtle but significant. Executives experience their first true incident dynamics during an actual crisis. Post-incident reviews focus on technical remediation while decision failures quietly repeat. The organization may recover, but it does not become more capable. Readiness is assumed rather than earned.
A tested incident response plan is not one that survives an exercise without friction. It is one that reveals friction early enough to address it. The purpose of testing is not validation, but visibility — into how decisions are made, how authority is exercised, and how the organization behaves when it cannot wait for certainty. The worst time to learn those lessons is when the incident is already real.
Further Reading
For readers interested in exploring the ideas behind meaningful incident response testing and organizational behavior under pressure, the following works provide useful context.
The NIST Computer Security Incident Handling Guide (SP 800-61) remains the most widely accepted reference for incident response programs and acknowledges that incidents rarely unfold in a linear or predictable way. While often used as a compliance artifact, its underlying assumptions about uncertainty and iteration are frequently overlooked.
The Incident Command System (ICS) and the broader National Incident Management System (NIMS) offer a contrasting model from high-consequence environments outside of cybersecurity. These frameworks are explicitly designed to address authority, decision ownership, and coordination under stress — problems that frequently surface during cyber incidents but are rarely addressed directly.
In Sensemaking in Organizations, Karl E. Weick examines how individuals and groups attempt to construct meaning during ambiguous and high-pressure situations. His work helps explain why hesitation, misalignment, and breakdowns in coordination are common during incidents, even among experienced leaders.
Sidney Dekker’s The Field Guide to Understanding “Human Error” challenges the idea that failures are primarily the result of individual mistakes. Instead, it frames behavior as a product of system design, incentives, and organizational context — a perspective that aligns closely with how incident response failures actually occur.
Finally, the Verizon Data Breach Investigations Report (DBIR) provides an empirical reminder that most incidents are prolonged, unclear, and poorly understood in their early stages. The data reinforces the gap between how organizations expect incidents to unfold and how they actually do.