Most organizations have accepted that a breach is a when, not an if. Fewer have thought through what that actually changes. If prevention alone isn't the strategy, the strategy has to include how well the organization operates once something goes wrong, and what shape it's in afterward.
That's the distinction between three things that get talked about as if they're one:
1. Preparedness: are you ready before something happens? 2. Incident management: can you make good decisions while it's happening? 3. Resilience: can you keep operating, and recover, once it's over?
I've already written about preparedness, the roles, authority, and escalation paths that need to exist before an incident starts. This piece is about the other two: what actually determines whether an organization manages an incident well, and comes out the other side intact.
A policy document doesn't manage an incident. People do.
Documentation satisfies an auditor. It doesn't tell you whether the organization can function when the network is down, communications are unreliable, and every decision has a business consequence attached to it. Six things consistently separate organizations that manage incidents well from ones that don't.
1. Executive ownership, not executive awareness
Cyber resilience is a business continuity problem, not an IT problem. If the executive team isn't involved in defining what counts as a critical service, how much downtime the business can absorb, and what tradeoffs are acceptable under pressure, the plan is guesswork dressed up as a document. Leadership has to own the risk decisions, not just get briefed on them after the fact.
2. Know what actually matters before you have to prioritize it live
You can't protect everything equally, and you can't recover everything at once. A real business impact analysis identifies which processes and systems matter most, before an incident forces that prioritization under pressure. Without it, recovery order gets decided in the moment, by whoever's loudest on the call.
3. Technical response and business response are not the same team
A common failure point is the gap between the technical team, focused on root cause, and business leadership, focused on restoring service. Both are necessary, and they need to run in parallel, not in sequence. While the technical team contains and remediates, someone needs to be handling legal obligations, communications, and customer-facing decisions at the same time, not after.
4. A plan that's never been tested is a theory
Writing a plan and testing a plan are different activities. Tabletop exercises and simulations surface the problems documentation can't, like a critical process that only one person knows how to run, or a decision point nobody actually has authority to make. Test before an attacker forces the test.
5. React less, anticipate more
Incident response that only starts once an alert fires is already behind. Feeding threat intelligence into the process, understanding what's actively targeting your industry, lets a team prepare detection and containment before the specific attack shows up, instead of building the response from scratch mid-incident.
6. Assume your normal communication tools are compromised
Attackers frequently take out email and standard collaboration tools first. A plan that depends on emailing the IT team when email might be the thing that's down isn't a plan. Out-of-band channels, pre-agreed phone numbers, secure messaging, an offline bridge line, need to exist before they're needed. External communication, to regulators, media, and clients, should be templated and pre-approved, so the first version anyone sees in a crisis isn't being drafted from scratch under pressure.
The distinction that actually matters
An organization that treats incident management as a compliance exercise will write the plan, check the box, and struggle the moment real pressure hits. An organization that treats it as an operating capability builds the muscle to make decisions, communicate clearly, and keep functioning while something is actively going wrong.
That's resilience. Not the absence of incidents, the ability to keep operating through one and recover from it without the organization coming apart in the process.
