Almost every organization has an incident response plan. Far fewer have one that works at 2 a.m. on a Sunday, when the person who wrote it is unreachable and the file server is encrypted.

The failure is rarely dramatic. Plans don't collapse because the team lacks skill. They collapse because the document assumes knowledge that isn't there, assigns authority nobody actually holds, and goes quiet at the exact moment people need instructions. What follows are the mistakes that show up again and again in real plans, with fixes you can apply this week.

The plan is stored where the incident already broke

A plan living on the internal wiki, behind single sign-on, on the network segment that is currently unavailable, is not a plan. It's a document. The same goes for the version that has a link instead of a phone number, or that requires a laptop to read while everyone is standing in a hallway trying to decide whether to pull the plug on production.

Fix this with a one-page action card for the first hour: who to call, what to preserve, what not to do. Print it. Keep copies in the office, in the on-call bag, and on phones in an encrypted note or PDF. Then edit the full plan for a reader who has never seen it before. Short sentences, verbs first: "Disconnect the host from the network." "Call the on-call lead." "Do not reimage the machine."

Everyone has a role, nobody has authority

Many plans say something like "IT will coordinate with management"—which describes a meeting, not a decision. When ransomware spreads and the choice is between isolating a revenue-generating system and preserving a service, someone has to decide in minutes, and that person needs to be named before the incident, not discovered during it.

Define an incident commander, plus a deputy for every critical role. Spell out the authorities that usually cause delays:

• Who can isolate or shut down a production system without further approval
• Who can wake the chief executive or the board
• Who can authorize emergency spending with a vendor
• Who is permitted to speak publicly about the incident

Name individuals, but define the roles by function so the plan survives a resignation or a reorganization.

Severity levels that don't change anything

Plans often have severity tiers with definitions so vague that everything becomes a Sev1, or nothing does. A tier is only useful if it triggers a different response: different people paged, different timelines, different obligations.

Tie severity to observable conditions rather than adjectives. A single phished mailbox with no suspicious rules and no lateral movement is not the same event as a compromised domain controller. Ransomware on one isolated workstation is not the same as ransomware plus deleted backups. Write the examples into the plan, then attach the response to each level: who gets paged, how quickly, who declares the incident, and whether legal, communications, or executive leadership join the call.

Communications planned last, needed first

The escalation tree frequently lives in the email system or chat platform that is compromised or offline. Contact lists go stale after a single round of departures. Nobody has drafted a holding statement, so the first external message gets written under pressure by whoever is least busy.

Agree on an out-of-band channel in advance—a conference bridge, a separate messaging tool, a phone tree—and test it before you need it. Maintain after-hours numbers for critical roles and verify them quarterly; a list checked once a year is a guess. Pre-approve short templates for internal updates, customer notices, and a holding statement. Designate one spokesperson and a backup, and keep updates factual and brief rather than speculative. Where outside statements carry legal weight, route them through counsel before they go out.

Cleaning up before securing the evidence

Well-meaning administrators rebuild servers, delete malware, and run cleanup scripts—destroying the artifacts that would explain how the attacker got in and what they touched. Long before that, log retention measured in days makes the investigation impossible.

Preserve first. Capture volatile data, isolate rather than wipe when you can, and restrict access to affected systems. Keep a timestamped log of every action taken, including who did it and when, in a time zone you write down. Understand your notification obligations ahead of time—contractual notice windows, regulator requirements, and affected-party notifications differ by industry and jurisdiction—and involve legal counsel early instead of guessing at deadlines.

The plan stops at containment

Plenty of plans effectively end with "restore from backups." That line hides the hard part: which systems come back first, what evidence you need before rebuilding, how you know the attacker is gone, and how long it takes to get back to normal operations. A backup that has never been restored is a hypothesis, not a control.

Define recovery order by business function, set exit criteria for each phase of the response, and plan for the possibility that the attacker left a way back in. Then build in a post-incident review within two weeks, run without blame, producing a short list of actions with owners and dates. Reviews that generate a document but no changes are theater.

Testing that confirms what everyone already knows

The annual tabletop with the same five participants, working a scenario circulated a week in advance, tests almost nothing. It rarely includes the executives, legal counsel, or communications staff who would genuinely be on the call.

Rotate scenarios. Invite the people who would actually be involved. Inject friction—make the incident commander unreachable, or take the primary communication channel away. Measure the things that matter: time to detect, time to declare an incident, time to contain. Compare those numbers against the previous exercise, and treat small quarterly runs as more valuable than one large annual event.

A realistic starting point

You don't need to rewrite the whole document this month. Start narrow and iterate:

1. Pick the three scenarios most likely for your organization.
2. Write a one-page first-hour checklist for each.
3. Assign an incident commander and a deputy, with authority written down.
4. Verify every contact number, including after-hours.
5. Restore one backup to a test environment and time it.
6. Run a 90-minute exercise that includes at least one person from outside IT.

Then write down what went wrong, fix that one thing, and schedule the next exercise. Incident response plans improve the same way security programs do: in small, tested increments, with evidence that the change actually worked.

Photo: Christina Morillo / Pexels