Your Incident Response Plan Is Probably Missing These 3 Things
A few months ago, I sat in a boardroom with a company that had just been breached. They had an incident response plan. It was in a binder. On a shelf. In the IT manager’s office.
Nobody could find it for the first two hours.
When they finally did, half the contact information was outdated, the procedures referenced tools they no longer used. The Office of the Privacy Commissioner requires breach notification within specific timelines — a stale plan makes compliance nearly impossible, and the “communication plan” was a single bullet point that said “notify management.”
They had a plan. It just wasn’t a useful one.
This is more common than you’d think. Most businesses I work with have some version of an incident response plan. On paper, they’re covered. In practice, they’re flying blind the moment something goes wrong.
Here are the three things almost every incident response plan is missing.
1. A Tested Communication Chain That Actually Works
When a breach happens, communication becomes your most important tool. And most plans treat it as an afterthought.
Here’s what I typically see: a vague reference to “notify the IT team and leadership.” No specific names. No phone numbers. No backup contacts. No guidance on what to say to employees, clients, or regulators.
Now imagine it’s 11 PM on a Friday. Your systems are encrypted. You need to reach your IT lead, your legal counsel, your insurance broker, your managed security provider, and your CEO. Can you do that in under 15 minutes?
If you have to dig through emails to find someone’s phone number, you’ve already lost critical time.
What your plan actually needs:
A tiered contact list with primary and backup contacts for every role. Cell phone numbers, not just office numbers. A designated incident commander who has the authority to make decisions without waiting for committee approval. Pre-drafted communication templates for employees, clients, regulators, and media. A tested escalation path, meaning you’ve actually run through it in a drill, not just written it down.
The word “tested” is doing heavy lifting there. A communication plan you’ve never practiced is just a wish list.
2. Clear Containment Procedures for the First 60 Minutes
The first hour of a security incident determines everything. It determines whether the attacker gains access to one system or your entire network. It determines whether you’re recovering for a day or a month. It determines whether you keep your clients’ trust or lose it.
Most incident response plans skip this part entirely. They go straight from “detect the incident” to “investigate and remediate” as if there’s nothing critical happening in between.
In reality, the first 60 minutes are chaos. People are panicking. Nobody knows the full scope yet. Someone is about to make a decision that either contains the damage or makes it exponentially worse.
Your plan needs specific, step-by-step containment procedures that anyone on the response team can follow under pressure. Not high-level concepts. Actual instructions.
What your plan actually needs:
Decision trees for common scenarios: ransomware, credential compromise, data exfiltration, insider threat. Clear guidance on when to isolate systems versus when to leave them running for forensic purposes. Predefined authority for the incident commander to take systems offline without executive approval. Instructions for preserving evidence, because your first instinct to “just shut everything down” can destroy the forensic data you’ll need later.
If your team has to debate what to do during an active breach, your plan has failed. The time for debate is before the incident, not during it.
3. A Post-Incident Review Process That Drives Real Change
Here’s the dirty secret of incident response: most businesses that survive a breach don’t learn from it.
They patch the immediate vulnerability. They restore from backup. They update a few passwords. And they go right back to operating the same way they did before, until it happens again.
Your incident response plan needs a mandatory post-incident review process. Not a finger-pointing session. Not a checkbox exercise for compliance. A genuine, structured review that answers specific questions.
What your plan actually needs:
A scheduled review within 72 hours of incident closure, while details are still fresh. A structured format covering: What happened? How did we detect it? How long did detection take? What worked in our response? What didn’t? What changes do we need to make? Assigned owners for every action item that comes out of the review, with deadlines. A follow-up mechanism to verify those changes actually got implemented.
The companies that take post-incident reviews seriously are the ones that don’t get hit the same way twice. Everyone else is just waiting for the rerun.
The Bigger Problem: Plans That Exist but Don’t Live
Here’s what ties all three of these together. The real issue isn’t that businesses don’t have incident response plans. It’s that the plans are static documents that nobody maintains, nobody practices, and nobody can actually execute when the pressure is on.
An incident response plan is not a compliance document. It’s an operational playbook. And like any playbook, it’s only as good as the practice behind it.
You should be testing your plan at least twice a year. Running tabletop exercises where your team walks through realistic scenarios. Updating contact information quarterly. Reviewing and revising procedures whenever your environment changes.
If the last time anyone looked at your IR plan was when it was written, you don’t have a plan. You have a document.
Where to Start
Pull out your current incident response plan. If you don’t have one, that’s your first priority, but let’s assume you do.
Ask yourself three questions:
1. If a breach happened right now, could I reach every person on the response team within 15 minutes?
2. Does my team know exactly what to do in the first 60 minutes without having to ask anyone?
3. After our last security incident (or our last drill), did we make specific, documented changes based on what we learned?
If you answered “no” to any of those, you know where the gaps are.
We help businesses build incident response plans that actually work, not binder-shelf plans, but tested, practiced, living playbooks. If you want help closing those gaps, reach out. We’ll start with a conversation about where you are and where you need to be.
Protecting your business from cybersecurity threats starts with preparation. And having the right recovery and restoration capabilities in place is just as critical as the plan itself.
Frequently Asked Questions
What are the most common gaps in incident response plans?
Three things: an untested communication chain with outdated contacts, missing containment procedures for the critical first 60 minutes, and no post-incident review process to drive improvements. Most plans exist on paper but have never been practiced.
How often should you update your incident response plan?
Review and update at least every six months, and immediately after any personnel change, tool change, or actual security incident. Run a tabletop exercise at least twice a year to verify the plan works in practice, not just on paper.
What is the difference between an incident response plan and a disaster recovery plan?
An incident response plan covers the immediate actions during and after a security event: containment, investigation, notification. A disaster recovery plan covers getting your business back to normal operations: restoring systems, data, and services. You need both, and they should reference each other.
Does PIPEDA require an incident response plan?
PIPEDA requires organizations to report breaches involving personal information to the Privacy Commissioner and affected individuals. While it doesn’t mandate a specific plan format, having a documented and tested incident response plan is the only practical way to meet these notification obligations within the required timelines.
Related: Learn more about incident response planning, the importance of a cybersecurity audit, and cyber liability insurance.
When was the last time your incident response plan was actually tested? We’ll review your plan, identify what’s missing, and help you build one that works when it matters.
Share This Post
