March 7, 2026 Best Practices 14 min read

Building an Incident Response Plan for Your Canadian Business

By Cybersecurity Canada Editorial Team | Published March 7, 2026

When the City of Hamilton was hit by ransomware in February 2024, the attack disrupted roughly 80% of the city's network — taking down business licensing, property tax systems, and city phone lines. Recovery cost $18.3 million. The city's cyber insurance claim was denied because multi-factor authentication had not been fully implemented. When the Toronto Public Library was struck by Black Basta ransomware in October 2023, it took nearly five months to fully restore digital services across 100 branches.

Both organizations eventually recovered. But the speed, cost, and effectiveness of any recovery depends heavily on what was planned before the incident occurred.

The Canadian Centre for Cyber Security's Baseline Cyber Security Controls designate incident response planning as BC.1 — the very first of the 13 control areas. It comes before patch management, before authentication, before backups. The positioning is deliberate: when an incident hits, everything else depends on having a plan to follow.

The Current State of Preparedness

Statistics Canada's 2023 Canadian Survey of Cyber Security and Cybercrime found that only 26% of Canadian businesses had written cybersecurity policies in place — unchanged from 2021. Meanwhile, 1 in 6 Canadian businesses (16%) were impacted by a cybersecurity incident in 2023, and total spending on recovery doubled from $600 million in 2021 to $1.2 billion in 2023.

IBM's Cost of a Data Breach report has consistently found that organizations with a formal, tested incident response plan spend significantly less on breach recovery than those without one. The 2023 report found that the cost difference was $1.49 million — organizations that conducted regular incident response testing reduced their average breach cost by that amount compared to those that did not.

The gap between the frequency of incidents and the level of preparedness among Canadian businesses remains wide.

What the Canadian Government Publishes

Two government resources are directly relevant to Canadian SMBs building an incident response plan:

ITSAP.40.003 — Developing Your Incident Response Plan

The Canadian Centre for Cyber Security publishes Developing Your Incident Response Plan (ITSAP.40.003), a guidance document that outlines the structure, phases, and considerations for building an IRP. It defines the plan as covering "the processes, procedures, and documentation related to how your organization detects, responds to, and recovers from a specific incident."

The document covers:

• Asset identification — Before creating a plan, identify what information and systems are of value to your organization and what types of incidents you might face
• Team composition — Build a response team with cross-functional representation whose purpose is to assess, document, and respond to incidents
• Policy alignment — Incident response activities need to align with organizational policies and compliance requirements, including roles, responsibilities, and authorities
• Training — Employees need to understand the plan, their role in it, and how to report suspected incidents
• Communications — The plan should detail how, when, and with whom the response team communicates, including a central point of contact for employees and notification procedures for internal and external stakeholders
• Outsourcing decisions — Determine which response actions can be handled internally and which will require external support, keeping in mind that specialized incident response services — particularly for operational technology environments — can be costly

CyberSecure Canada IRP Template

Innovation, Science and Economic Development Canada (ISED) publishes a fillable incident response plan template as part of the CyberSecure Canada certification program. The template is available as a downloadable Word document and includes section-by-section instructions.

The template covers:

• Purpose statement — Why the plan exists and what it applies to
• Definitions — Key terms including indicators of compromise (IOCs), maximum tolerable downtime, and incident classification
• Cyber Security Incident Response Team (CSIRT) — Roles, responsibilities, and contact information
• Incident severity matrix — How to classify incidents by impact level
• Response phases — Detailed procedures for each stage of the response
• Document control — Version history and review schedule
• Testing plan — How and when the plan will be exercised

This template was designed specifically to help small and medium organizations meet the CyberSecure Canada certification requirements, but it is freely available and useful regardless of whether certification is being pursued.

The Incident Response Lifecycle

Both the CCCS guidance and the CyberSecure Canada framework describe incident response as a lifecycle — a continuous process, not a one-time document. The phases are consistent with the widely adopted NIST framework (SP 800-61) and are adapted for Canadian organizations.

Phase 1: Preparation

Preparation is everything that happens before an incident occurs. The CCCS guidance (ITSAP.40.003) begins here: perform a risk assessment, identify your most valuable assets, define the types of incidents your organization is most likely to face, and create response steps for each.

For a Canadian SMB, preparation includes:

• Naming the response team. At minimum, this means identifying a primary person responsible for leading the response and a backup. In a small business, the team might be two or three people — the owner, the IT lead or managed service provider, and someone who handles communications. The CyberSecure Canada template refers to this as the Cyber Security Incident Response Team (CSIRT).

• Listing contact information. The plan should include current contact details for: your IT support or managed service provider, your cyber insurance carrier (if applicable), legal counsel, the Canadian Centre for Cyber Security (1-833-CYBER-88), local police, and the Canadian Anti-Fraud Centre.

• Identifying critical systems. Know which systems must come back first — email, financial systems, customer-facing services — and what data they depend on. The CyberSecure Canada template uses the concept of maximum tolerable downtime: the longest period a given business process can be inoperative before the organization's survival is at risk. Defining this for each critical system helps prioritize recovery efforts.

• Defining what constitutes an incident. The CyberSecure Canada template defines an incident as "any event or set of circumstances that threatens the confidentiality, integrity, or availability of information, data or services." Not every anomaly is an incident. Having clear criteria prevents both under-reaction and over-reaction.

• Keeping the plan accessible. If your network is encrypted by ransomware, a plan stored only on the network is useless. Print the plan. Keep a copy offsite. Store it somewhere the team can access without relying on the systems that may be compromised.

Phase 2: Detection and Analysis

An incident that is not detected cannot be responded to. The CCCS guidance notes that attacks can go unnoticed before there is an opportunity to apply a patch or update, and that the plan should provide instructions for mitigating active exploitation.

Detection sources vary by organization size and capability:

• Employee reports — An employee notices a suspicious email, an unexpected login prompt, or files they cannot open. The plan should make it clear how and where to report these observations.
• Alerts from security tools — Anti-malware software, endpoint detection and response (EDR) tools, or firewall logs flag unusual activity
• External notification — A customer, vendor, law enforcement agency, or the CCCS itself notifies you of a compromise. In 2024-2025, the Cyber Centre issued 336 pre-ransomware notifications to Canadian organizations, generating an estimated $6 to $18 million in economic savings.

Once a potential incident is detected, the analysis phase involves determining whether it is real, assessing its scope and severity, and classifying it using the severity matrix defined during preparation. The CyberSecure Canada template includes a severity classification framework for this purpose.

Phase 3: Containment

Containment is about stopping the spread. The CCCS guidance describes it as "crucial for your organization's recovery" with the primary goal of minimizing business impact.

The CCCS guidance is clear that containment strategies depend on the type of incident, the degree of damage it can cause, and the organization's operational requirements. There is no single containment procedure that applies to every incident. The risk assessment completed in the preparation phase informs what level of disruption is acceptable during containment.

Practical containment actions for an SMB might include:

• Disconnecting affected devices from the network — wired and wireless
• Disabling compromised user accounts
• Blocking specific IP addresses or domains at the firewall
• Temporarily suspending remote access or VPN connections
• Isolating network segments if segmentation is in place

The CCCS guidance also notes that it may be necessary to isolate all systems and suspend employee access temporarily to detect and stop further intrusions. This is a significant operational decision — one that is much harder to make under pressure without a plan that pre-authorizes it.

Phase 4: Eradication

Once contained, the root cause must be identified and removed. This means finding how the attacker got in, what tools or malware they deployed, and eliminating all elements of the compromise from affected systems.

For many Canadian SMBs, this phase involves external expertise — a managed service provider, an incident response consultant, or a forensic specialist. The CCCS guidance notes that outsourcing incident response for specialized environments can be costly, and that planning for this in advance is important. Having a relationship with an incident response provider — or at least knowing who to call — before an incident occurs saves critical time.

Phase 5: Recovery

Recovery means restoring affected systems and returning to normal operations. The CCCS guidance emphasizes: ensure any malware is removed before restoring backups, and test, verify, monitor, and validate affected systems to ensure they are running effectively.

Recovery follows the priorities set during preparation. Systems identified as critical — with the shortest maximum tolerable downtime — come back first. The vulnerability or access method the attacker used must be patched or closed before restored systems are reconnected to the network, or the same attack can succeed again immediately.

Recovery takes longer than most businesses expect. For small businesses without documented recovery procedures and tested backups, restoration typically takes days to weeks. The Toronto Public Library took nearly five months.

Phase 6: Post-Incident Review

The CyberSecure Canada template calls this the "Learning" phase. The CCCS guidance frames it as developing exercises to test the plan and using results to revise and improve it.

A post-incident review asks:

• How did the attacker get in?
• How was the incident detected, and how long did detection take?
• What worked in the response? What did not?
• Were the right people contacted? Did communication flow as planned?
• Were there gaps in tools, training, or procedures?
• What specific changes are needed before the next incident?

This review feeds directly back into Phase 1, updating the plan based on real experience. The CCCS guidance recommends testing, revisiting, and revising the incident response plan annually at minimum.

PIPEDA: The Legal Obligation That Runs Parallel

If a cyber incident involves personal information — employee records, customer data, financial details — it almost certainly triggers mandatory breach reporting under PIPEDA.

PIPEDA requires organizations to report a breach to the Office of the Privacy Commissioner of Canada when it creates a "real risk of significant harm" to individuals. "Significant harm" includes financial loss, identity theft, damage to reputation, and loss of employment or business opportunities. Given the nature of most cyber incidents — particularly ransomware, where data exfiltration is increasingly common — the threshold is met in the majority of cases.

Three obligations apply:

1. Report to the Privacy Commissioner — "As soon as feasible" after determining the breach has occurred. PIPEDA does not prescribe a specific number of days, but the expectation is that organizations do not wait for a complete investigation before reporting.
2. Notify affected individuals — Inform them of what happened, what information was involved, and what steps they can take to protect themselves.
3. Maintain records — Keep records of all breaches of security safeguards for 24 months, regardless of whether they meet the reporting threshold. The Commissioner can request access to these records at any time.

Failure to report, notify, or maintain records is an offence under PIPEDA, with fines of up to $100,000 per violation.

An incident response plan that does not account for PIPEDA's breach notification requirements leaves a significant legal and operational gap. The plan should include: who determines whether the RROSH threshold is met, who drafts the report to the Privacy Commissioner, who handles individual notification, and what records are kept.

Testing the Plan

A plan that has never been tested is a plan that might not work. The CyberSecure Canada template explicitly includes a testing section, noting that "unless real incidents occur which test the full functionality of the process, this can be achieved using walkthroughs and practical simulations of potential incidents."

The CCCS guidance similarly recommends developing exercises to test the plan and using results to improve it.

Testing does not require a full-scale simulation. For a small business, it can be as straightforward as:

• Tabletop exercise — Gather the response team around a table (or a video call) and walk through a scenario: "It's Monday morning. An employee reports that all shared drive files are encrypted and there's a ransom note on their screen. What do we do?" Walk through every step of the plan and note where it breaks down.
• Communication test — Verify that every phone number and email address in the plan still works. Confirm that the person listed as the primary contact is still in that role.
• Backup restoration test — Attempt a full restore of a critical system from backup. Measure how long it takes. Confirm the data is intact. This tests both the incident response plan and backup procedures simultaneously.

IBM's data indicates that organizations conducting incident response testing at least twice a year reduce breach costs by an average of $1.49 million compared to those that do not test. The CCCS recommends at minimum an annual review and revision cycle.

The Insurance Connection

Cyber insurers increasingly ask whether the policyholder has a written, tested incident response plan. Many applications specifically ask when the plan was last reviewed and whether tabletop exercises have been conducted.

Beyond the application, the plan itself affects claims. Most cyber insurance policies require prompt notification — typically within 24 to 72 hours of discovering an incident. An incident response plan that includes the insurer's claims number, the notification timeline, and the steps to preserve evidence makes the difference between a smooth claim process and a disputed one.

Free Government Resources

The Canadian government provides several free resources directly relevant to building an incident response plan:

• Developing Your Incident Response Plan (ITSAP.40.003) — The CCCS's primary guidance document on IRP development
• CyberSecure Canada IRP Template — A fillable Word document template with section-by-section instructions from ISED
• Ransomware Playbook (ITSM.00.099) — A detailed operational framework for ransomware prevention, response, and recovery
• Get Cyber Safe — The Government of Canada's public awareness campaign, including resources for small businesses
• Developing Your IT Recovery Plan (ITSAP.40.004) — Companion guidance on recovery planning that works alongside your IRP
• Canadian Centre for Cyber Security contact: 1-833-CYBER-88 (1-833-292-3788) or via My Cyber Portal

The Baseline Controls Connection

Incident response planning is BC.1 — the first of the Canadian Centre for Cyber Security's Baseline Controls — but it does not exist in isolation. An effective incident response plan depends on controls from across the framework:

• BC.2 — Patch Management: The post-incident review may reveal that an unpatched vulnerability was the entry point
• BC.3 — Anti-Malware: Detection tools generate the alerts that trigger the response
• BC.5 — Authentication: Compromised credentials are a leading cause of incidents — MFA reduces this risk and is increasingly required by insurers
• BC.6 — Security Awareness: Trained employees are often the first to detect an incident by recognizing something unusual
• BC.7 — Data Backup: Recovery depends entirely on having reliable, tested, offline backups
• BC.9 — Network Security: Network segmentation limits lateral movement during containment
• BC.12 — Access Control: Least-privilege access reduces the blast radius when an account is compromised

The plan is the thread that connects these controls when it matters most.

Our free assessment evaluates your organization across all 13 Baseline Control areas, including incident response readiness. It takes under 10 minutes and shows where your current posture stands — and where the gaps are that a plan needs to account for.