Most organizations that get breached already had an incident response plan. That fact alone should tell you something: the plan was never the hard part.
Having a document that describes phases of response, containment, eradication, recovery, is table stakes. It satisfies an auditor. It does not tell you whether your organization can actually execute under pressure, at 2 a.m., when half the people named in the plan are unreachable and the ones who are reachable are not sure they have the authority to do what needs doing.
Preparedness is a different question than response. Response asks what you do once something has happened. Preparedness asks whether the organization is actually capable of doing it.
The questions a plan doesn't answer
I've spent the past several months working through incident preparedness for a healthcare-adjacent organization handling regulated data, and the gaps that show up are rarely technical. They're organizational.
1. Who has the authority to declare an incident, and do they know it's them? 2. Who makes the call to take a system offline, and what happens if they're on a plane? 3. Who contacts legal, and at what point? 4. Who contacts the cyber insurer, and before or after outside counsel is engaged? 5. Who communicates internally, to whom, and on what cadence? 6. Who communicates externally, to regulators, partners, or the public, and who has final sign-off on that language? 7. What happens when the normal IT team is unavailable, on vacation, or is itself the group under investigation? 8. Have the third parties who would need to be involved, forensics, breach counsel, PR, actually been identified in advance, or is that a scramble that starts after the incident? 9. Have contact information and escalation paths been validated recently, or are they the same list from two reorgs ago? 10. Has anyone actually practiced the plan, or has it only ever been read? 11. Does leadership understand what decisions may fall to them, and have they thought through how they'd make those decisions under time pressure?
None of these are answered by the plan itself. They're answered by governance, by rehearsal, and by clarity about who owns what before the pressure is on.
Why this matters more in regulated environments
Organizations handling protected health information face a particular version of this problem. The HIPAA Security Rule already requires a security incident procedures standard, and that requirement hasn't changed. What has generated attention this year is a proposed update to the Security Rule, one that would tighten documentation requirements, remove the required-versus-addressable distinction that's given organizations wiggle room for two decades, and set firmer timelines for things like risk analysis and response testing.
There's been a lot of noise about the timeline for that rule. Comment periods, pushback, delays. It's easy to read that as "we have more time." That's the wrong takeaway.
The proposed rule doesn't invent new expectations out of nothing. It formalizes practices that a well-run security program should already have in place: documented procedures, defined roles, tested response capability, real evidence that the organization can execute rather than just describe what it would do. Whether the rule is finalized in its current form, delayed, or revised, the underlying operational bar isn't moving. Organizations that wait for the final rule to discover their incident preparedness has gaps are solving the wrong problem at the wrong time.
What good preparedness actually looks like
A tested incident response capability has a few consistent features regardless of industry:
- Roles are assigned to people, not just titles, and those people know it.
- Severity is defined in advance, so the first ten minutes of an incident aren't spent arguing about how bad it is.
- Third-party contacts, forensics, counsel, insurer, are identified and current, not discovered mid-incident.
- The plan has been rehearsed through a tabletop exercise recently enough that people remember it.
- Leadership has thought through the decisions that would land on them, before they're making those decisions in real time.
None of this requires a bigger document. It requires an organization willing to test its own assumptions before an attacker does.
That's the actual work of preparedness. The plan is where it starts. It is not where it ends.
