Most Canadian small businesses don’t have an incident response plan. If you’re reading this, you probably know that’s a problem, but you’re not sure where to start. This guide walks you through what an IRP is, what goes in one, what Canadian law actually requires, and how to build one without spending months on it.
Why most small businesses don’t have an incident response plan (and why that’s a problem)
The assumption is usually wrong: IRPs are for enterprises with dedicated security teams. They aren’t. An incident response plan is just a documented decision-making process. Who calls whom when something breaks. What you do in the first hour. How you communicate with customers, regulators, and your team. That applies to any business that handles customer data, employee records, or financial information.
The real cost of not having one is substantial. According to IBM’s 2024 Cost of a Data Breach report, the global average breach costs $4.4M USD. The average time to identify a breach is 194 days. The average time to contain it after identification is 64 days. Every day you’re not responding is a day attackers have access to your systems.
Without a plan, your response is chaos: people don’t know who to call, your IT team is making decisions they’re not authorized to make, nobody knows what to document for legal, and your customers find out about the breach before you tell them. With a plan, you move fast. You contain damage. You protect yourself legally. You keep your business running.
The 6 phases of incident response (NIST framework, simplified for SMBs)
The National Institute of Standards and Technology (NIST) defines incident response in six phases. These are the actual sequence of decisions and actions you take when something happens.
1. Preparation
Before the incident, you build the tools, people, and processes you need to respond fast. Your IRP document exists. Your team knows their roles. You have monitoring in place so you can detect problems. You have backups. You have a contact list. You’ve run at least one tabletop exercise so people know what to do under pressure. Multi-factor authentication (MFA) should be deployed on critical systems as part of your preparation phase.
2. Identification
Something breaks or looks wrong. A security tool fires an alert, a customer reports suspicious activity, or your MSP notices unusual traffic. Your job is to confirm what happened. Is this actually a security incident or a false alarm? What systems are affected? How long has it been happening? Document everything. Start your incident log now.
3. Containment
Stop the bleeding. If an account is compromised, reset the password and lock the account. If malware is running, isolate the machine from the network. Containment buys time to understand what happened without the attacker causing more damage. This is where escalation thresholds matter: you need to know whether to take a system offline immediately or gather forensic evidence first.
4. Eradication
Remove the attacker and their tools from your environment. Patch the vulnerability they exploited. Change credentials. Remove malware. Scan systems to confirm nothing else is hiding in your network. Until eradication is complete, the incident isn’t over. Enterprise-grade antivirus is essential during this phase.
5. Recovery
Bring systems and data back online, carefully. Restore from clean backups. Monitor closely for signs of reinfection. Gradually return affected systems to normal operations. Recovery can take longer than containment, especially if you have to rebuild systems from scratch. This is where disaster recovery procedures prove their value.
6. Lessons Learned
After the incident, while it’s still fresh, your team meets to discuss what happened, what you did right, what broke down, and what changes you need to make. This isn’t about blame. It’s how your plan gets better over time.
What goes in your incident response plan
An IRP document doesn’t have to be long. It does have to be specific. Here are the five components every SMB IRP needs.
1. Response team and roles
Who is on the incident response team? What is each person’s role? Who can make critical decisions, like taking a system offline or notifying customers? Who escalates to legal, insurance, or law enforcement?
Example: Your incident response team includes your IT manager, one senior technician, the CFO (to authorize spending and decisions), and the owner (for final approval on customer notification). If the incident involves suspected criminal activity, the IT manager contacts your lawyer within 2 hours.
2. Contact list
Build a contact sheet with phone numbers and email addresses for everyone you’d need to reach. Don’t rely on memory or Google. Print it and post it in the server room. Keep a digital copy in a shared location your team can access if email is down.
Example: Your list includes your MSP (with after-hours emergency number), your IT vendors, your insurance broker, your legal counsel, law enforcement, the Privacy Commissioner of Canada, and personal cell phone numbers for your incident response team.
3. Asset inventory and classification
You can’t protect what you don’t know you have. Catalog your systems, applications, databases, and where critical data lives. Classify assets by criticality: critical (business stops without it), important (business is slowed), or low-priority.
Example: Your asset inventory lists your file server, customer database, email system, website, and accounting software. Your customer database is marked critical. Your website is important. During an incident, you know which systems to recover first.
4. Escalation thresholds
Define what situations require immediate response versus what can wait until business hours. What triggers calling your MSP at 3am? What requires law enforcement? What requires customer notification?
Example: If a customer reports their credentials are stolen, that’s immediate: reset the password and notify that customer. If ransomware is detected actively encrypting files, that’s a 3am call to your MSP and an immediate decision about taking systems offline.
5. Communication templates
When an incident happens, you don’t have time to write from scratch. Prepare templates for internal notification, customer notification, and regulatory notification.
Example: Your internal template tells your team what happened, what you’re doing about it, and what you need from them. Your customer notification template explains what happened, what data was affected, what you’re doing to fix it, and what customers should do. Your regulatory template addresses the OPC with a breach description, the number of individuals affected, and the steps you’ve taken to contain and notify.
PIPEDA and breach notification: what Canadian businesses need to know
PIPEDA (Personal Information Protection and Electronic Documents Act) is Canada’s federal privacy law. It applies to any business that collects personal information about customers or employees, with limited exceptions.
What triggers mandatory notification: You must notify the Privacy Commissioner of Canada and affected individuals when a breach creates a “real risk of significant harm.” Practically, that means physical injury, humiliation, identity theft, financial loss, or loss of employment opportunity. If a customer’s email address was exposed but nothing else, that usually doesn’t meet the threshold. If their name, home address, and payment card number were exposed, it does.
Who you notify: You notify the Office of the Privacy Commissioner of Canada and the affected individuals. PIPEDA doesn’t define a hard notification deadline, but guidance says “promptly.” In practice, delay is bad. The longer you wait, the harder it is to defend your response.
What you have to document: Keep a breach log. For each incident, document the date, a description of what happened, the number of individuals affected, what personal information was involved, what steps you took to contain and recover, and how you notified people. This log is essential. It shows regulators you have processes in place and take privacy seriously.
What happens if you don’t comply: The OPC can launch an investigation, order corrective action, and issue a public report about your negligence. While PIPEDA currently lacks direct financial penalties for organizations, your business reputation takes a serious hit. More importantly, this is changing.
Bill C-11 (Consumer Privacy Protection Act, CPPA): The proposed replacement for PIPEDA includes financial penalties up to 3% of global revenue or $15 million, whichever is higher. It requires stronger consent for data collection and gives individuals broader rights. It’s not yet law, but it is coming. Your IRP needs to be ready for this stricter environment.
Common mistakes in incident response plans that exist but never get used
A lot of small businesses have written an IRP. Many of those plans never help when an incident actually happens. Here’s why.
Mistake 1: The plan lives in a document nobody can access during the incident
The IRP is saved on the CFO’s laptop or in a shared drive behind a forgotten password. When an incident starts, people scramble to find the document instead of executing it. If your office is physically inaccessible or your email is down, digital-only access doesn’t work.
Fix: Print the IRP. Post it in the server room and your operations area. Keep a digital copy in a highly accessible location, not buried in a folder structure.
Mistake 2: No test or tabletop exercise has ever been run
The plan looks good on paper. But your team has never practiced it. When a real incident happens, roles conflict, communication breaks down, and decisions take ten times longer than they should.
Fix: Run at least one tabletop exercise per year. Walk through a realistic scenario and execute your IRP. Time it. Document what works and what breaks. Update the plan accordingly.
Mistake 3: The contact list is outdated
Your IT person left two years ago. Your insurance broker changed. Your lawyer retired. The contact list still has old numbers. When you need to call, you’re calling disconnected extensions.
Fix: Update your contact list twice per year. Assign someone to own this. Verify numbers work. Test it during your tabletop exercise.
Mistake 4: No defined communication approval process
When a breach happens, the IT team sends a message to customers without legal review. Legal then tells you something in that message creates new liability. You send a corrective message that contradicts the first one. Customers lose trust and regulators get suspicious.
Fix: Define who approves each type of communication before it goes out. Customer notification requires both legal and leadership approval. Write this into your IRP so nobody improvises under pressure.
Mistake 5: Backups have never been tested
Your backups are running and look good on the monitoring dashboard. But nobody has actually restored from them in years. When you need to recover, you discover the backups are corrupted or incompatible with your current systems.
Fix: Test backup restoration at least twice per year. Pick a non-critical system, wipe it, and restore from backup. Time the recovery. Document how long it takes. Fix what breaks.
IRP starter checklist
| Phase | Action Item | Done |
|---|---|---|
| Preparation | Define incident response team and assign roles | ☐ |
| Preparation | Build and test contact list (IT, legal, insurance, law enforcement, OPC) | ☐ |
| Preparation | Create asset inventory and classify by criticality | ☐ |
| Preparation | Set escalation thresholds (what triggers 3am calls vs. morning decisions) | ☐ |
| Preparation | Draft communication templates (internal, customer, regulatory) | ☐ |
| Preparation | Deploy or verify security monitoring on critical systems | ☐ |
| Preparation | Test backup and recovery process (restore a non-critical system from backup) | ☐ |
| Preparation | Schedule and run a tabletop exercise with the response team | ☐ |
| Identification | Enable detailed logging on file servers, email, and databases | ☐ |
| Identification | Create incident log template and make it accessible offline | ☐ |
| Containment | Document decision rights (who can take systems offline, who authorizes isolation) | ☐ |
| Eradication | Confirm patch management process is documented and current | ☐ |
| Recovery | Document RTO and RPO for each critical system | ☐ |
| Lessons Learned | Schedule post-incident review within one week of incident closure | ☐ |
How Fusion helps businesses build and test their IRP
Building an incident response plan doesn’t require six months and an expensive consultant. But it does require expertise to make it practical and defensible under pressure.
IRP development is included in Fusion’s cybersecurity assessment. Here’s what that looks like.
Discovery: We map your systems, data flows, and critical assets. We understand what you’re protecting and where your current gaps are.
Gap analysis: We compare your current state against the NIST framework and PIPEDA requirements. We identify what’s missing: usually contact lists, communication templates, and documented decision-making processes.
Plan drafting: We work with you to build an IRP specific to your business, your systems, and your risk profile. We write it in plain language. We make it actionable.
Tabletop exercise: We run a tabletop scenario with your team so everyone knows their role before it matters. We capture what works and what breaks. We update the plan based on what we learn.
Fusion Computing has been working with Canadian organizations since 2012. Our CEO Mike Pearlstein holds the CISSP and has led our cybersecurity practice through real incidents affecting real clients. We’re Canadian-owned, PIPEDA-aligned, and we build IRPs that are designed to work when you actually need them.
Mike Pearlstein is CEO of Fusion Computing and holds the CISSP, the gold standard in cybersecurity certification. He has led Fusion’s managed IT and cybersecurity practice since 2012, serving Canadian businesses across Toronto, Hamilton, and Metro Vancouver.
Frequently Asked Questions
Does a small business really need a formal incident response plan?
Yes. An IRP is a practical requirement under PIPEDA and a standard condition for most cyber insurance policies. Beyond compliance, it’s a business continuity tool. When something breaks, you need to know who to call and what to do. That shouldn’t be improvised under pressure. Even a one-page document is better than nothing. A tested, specific plan is meaningfully better than either.
How often should we update our IRP?
Review and update your IRP at least once per year, or whenever major changes happen: new systems, staff turnover, significant incidents, or regulatory changes. Always update it after a real incident or tabletop exercise. Schedule the review in advance so it doesn’t slip.
What is a tabletop exercise and how do we run one?
A tabletop exercise is a walkthrough of an incident scenario without any real systems involved. You gather your response team, describe a realistic scenario (ransomware detected, customer data breach, credential theft), and talk through what you would do, following your IRP step by step. You note what works and what breaks. A good tabletop takes 60 to 90 minutes. It’s the single best way to test your plan and train your team before a real incident happens.
Does cyber insurance require an incident response plan?
Most cyber insurance policies either require an IRP or heavily incentivize one through premium discounts. Insurers know that businesses with formal plans recover faster and contain damage better. Even if your policy doesn’t explicitly require one, having a plan improves your likelihood of a favorable claims decision because it demonstrates you took reasonable precautions.
What is the difference between an IRP and a business continuity plan?
An incident response plan is focused on security incidents: how you detect, respond to, and recover from a breach or attack. A business continuity plan is broader: how you keep critical business functions running when anything goes wrong, including natural disasters, power outages, or pandemics. IRPs are a subset of business continuity. A complete risk management strategy includes both, but if you have neither, start with the IRP.
Related Services & Resources
Does your business have an incident response plan?
Book a free cybersecurity assessment. We will help you understand your exposure and build a plan that actually works when you need it.
