How to Build an Incident Response Plan Before You Need One

Most businesses that get hit by a serious security incident already had monitoring, backups, and some form of antivirus or EDR running. What they didn't have was a plan for the specific ninety minutes after detection, when decisions have to be made fast, by specific people, in a specific order. Buying more security tools doesn't fix that gap. Writing the plan does, and it has to happen before the emergency, because nobody writes a good plan while they're also trying to contain an active breach.

A plan is a rehearsed playbook, not a binder

The version of an incident response plan that actually works during a real incident is the one that's been read, understood, and practiced by the people who'll execute it, not a fifteen-page document sitting in a shared drive that nobody has opened since it was written. If your plan couldn't be summarized out loud by the people responsible for it, it's a compliance artifact, not an operational one.

Step one: define severity levels before anything happens

Not every incident deserves the same response. A phishing email that got reported before anyone clicked it is different from ransomware actively encrypting file shares. Define three or four severity tiers in advance, what qualifies for each, and what response that tier triggers. Deciding severity in the moment, under pressure, is how a Tier-1 emergency gets treated like a Tier-3 annoyance for the first critical hour.

Step two: name names, not roles

"IT will handle it" is not a response plan. A real plan names the specific person who leads technical containment, the specific person with authority to take a system offline without waiting for a committee, and the specific person who owns external communication, customers, vendors, regulators if applicable. If any of those seats are empty or unclear, that's the first gap to close, before worrying about anything more technical.

The best incident response plan we've ever seen executed well wasn't the most detailed one. It was the one where every person involved already knew, without checking a document, exactly what their job was.

Step three: build the communication plan before you need it

Internal communication during an incident needs a channel that isn't dependent on systems that might be compromised, an out-of-band group chat or phone tree, not "we'll email everyone" when email might be exactly what's compromised. External communication needs a pre-approved holding statement and a clear decision-maker for when and how customers get notified, because the instinct to wait until "we know more" often costs more trust than an early, honest, brief update would have.

Step four: rehearse it with a tabletop exercise

A tabletop exercise is a scripted, low-stakes walkthrough: someone presents a realistic scenario, "it's Friday at 5pm and file shares are encrypting," and the response team talks through exactly what they'd do, in order, out loud. It reliably surfaces the gaps a written plan hides, someone doesn't have the on-call number memorized, nobody's sure who can actually authorize paying for emergency forensics, the "backup admin" left the company eight months ago. Running this once a year is common. Running it after any major change, a new backup system, a new cloud provider, is smarter.

Step five: know what "recovered" actually means before you're in recovery

Containing an incident and recovering from it are different phases with different finish lines. Recovery isn't done when systems come back online, it's done when you've confirmed backups are clean, access has been fully re-verified, and the entry point that caused the incident has actually been closed. This is where an incident response plan and a tested backup and disaster recovery strategy have to connect, a plan that assumes clean backups will exist is only as good as the backup strategy backing it.

What to have ready right now, before anything happens

• A current contact list for the response team, including personal phone numbers, not just work email
• Access to backups and admin credentials that doesn't depend entirely on the systems most likely to be compromised
• A pre-approved holding statement template for customer or partner communication
• A clear, written decision on who has authority to isolate systems without waiting for sign-off
• A relationship with a forensics or incident response resource established before you need one, not searched for during the incident

The plan you write in advance always beats the one you write during

Every part of this can be drafted calmly on a Tuesday afternoon. None of it can be drafted well at 2am while a ransomware note is on every screen. The businesses that come through a serious incident with the least damage aren't the ones with the most expensive tools, they're the ones where everyone already knew exactly what happens next.