BLOG

The average cost of a data breach in Canada reached CA$6.98 million in 2025. The average attacker breakout time, the window between initial access and lateral movement across your systems, is now 29 minutes, with the fastest recorded case at 27 seconds. And yet only 26% of Canadian businesses have a written cybersecurity policy, let alone a tested incident response plan.

The gap between those two realities is where most of the damage happens. Organizations that know what to do in the first hour of a breach consistently contain the incident faster, spend less recovering, and satisfy regulators more cleanly than those making it up as they go. This guide walks through building an incident response plan that actually works, not a document that lives in a folder until the moment it is desperately needed and found to be useless.

What is an incident response plan and why does every Canadian organization need one?

An incident response plan (IRP) is a documented set of procedures that defines exactly what your organization does when a cybersecurity incident occurs, from the moment something is detected through containment, eradication, recovery, and post-incident review. It identifies who is responsible for what, who communicates with whom, and in what order decisions are made.

Without a plan, every incident becomes a crisis managed on instinct. People freeze. Communications break down. Evidence gets destroyed. Systems get wiped before forensics can capture what happened. Regulators ask for records that do not exist. Cyber insurers dispute claims because notification timelines were missed. A plan does not prevent breaches, it determines whether a breach becomes a recoverable event or a catastrophic one.

In Canada, the pressure to have a documented and tested plan is increasing on multiple fronts. PIPEDA requires breach notification when there is a real risk of significant harm to individuals. Quebec Law 25 carries penalties up to CA$25 million for privacy failures. Bill C-8 will require designated operators and their supply chains to demonstrate documented incident response capabilities. And cyber insurers are now requiring evidence of tested plans as a precondition for coverage.

Step 1: Assemble your incident response team and define roles

A cybersecurity incident is not a problem for the IT team to solve alone. Breaches have legal, regulatory, financial, reputational, and operational dimensions that require coordinated input from across your organization. Your incident response team should include, at minimum:

• Incident Response Lead, accountable for activating and running the plan; typically the CISO, IT Director, or most senior security-capable person
• IT / Security, responsible for technical containment, investigation, and remediation
• Legal Counsel, advises on regulatory notification obligations, manages legal privilege, and coordinates with law enforcement if required
• Communications, manages internal messaging, customer notifications, and media inquiries
• Executive Sponsor, a C-suite member with authority to approve decisions and resource allocation under pressure
• HR, involved when insider threats or employee-related incidents are suspected

Document the name, role, and contact information for each person. Establish a backup for every role. Define the escalation threshold, what type or severity of incident triggers full team activation versus a smaller initial response. These decisions need to be made before an incident, not during one.

Step 2: Define what counts as a cybersecurity incident

One of the most common failures in incident response is the absence of a clear definition of what triggers the plan. Teams waste critical time debating whether something ‘counts’ while an attacker moves laterally through the network. Your plan needs to define incident categories in advance.

A practical starting taxonomy for Canadian organizations:

• Confirmed breach, unauthorized access to or exfiltration of data has occurred
• Ransomware, systems have been encrypted or a ransom demand has been received
• Business email compromise (BEC), an executive or finance account has been compromised and used to redirect payments or request sensitive information
• Malware infection, malicious software has been detected on one or more systems
• Unauthorized access, a user account has been accessed without authorization, including through credential theft or MFA bypass
• Denial of service, systems or services are being disrupted by an external attack
• Suspected insider threat, evidence of deliberate data theft, sabotage, or policy violation by an employee or contractor

Each category should have a defined severity level (P1 through P3, for example), a corresponding response timeline, and a list of who gets notified at each level. The taxonomy does not need to be exhaustive, it needs to be clear enough that the person who first detects an anomaly knows what to do with it.

Step 3: Build your detection and alerting capabilities

A plan is only useful if you know something has happened. Many Canadian organizations run for weeks or months with an active compromise before anyone detects it. The 2025 Verizon Data Breach Investigations Report found that 22% of breaches were credential-based, meaning attackers often move through environments using legitimate accounts that generate no obvious alerts.

Detection capability does not require an enterprise security operations centre. For most Canadian SMBs and mid-market organizations, the baseline is:

• Endpoint detection and response (EDR), behavioural detection on all endpoints, replacing legacy antivirus
• Centralized log collection, aggregating logs from endpoints, servers, identity systems, and cloud services into a single searchable location
• Alert thresholds and monitoring, defined conditions that trigger automated alerts, whether handled internally or by a managed security provider
• Identity monitoring, alerts on impossible travel, failed MFA, privilege escalation, and new device registration

Step 4: Document your containment and eradication procedures

Containment is the act of stopping an incident from spreading further. Eradication is the act of removing the threat from your environment. These are two distinct phases, and confusing them is a common and costly mistake, organizations that rush to eradicate before fully containing an incident often find the attacker has left persistence mechanisms that allow re-entry.

Your containment procedures should define:

• Network isolation protocols, how to quarantine a compromised endpoint or segment without taking down business-critical systems
• Account lockdown procedures, how to disable compromised credentials while preserving forensic evidence
• Evidence preservation rules, what must be captured before systems are touched (memory dumps, log exports, disk images)
• Communication blackout protocol, decision framework for whether to take systems offline entirely versus maintaining limited operation to avoid tipping off an attacker who may still be active

Eradication procedures follow containment and include removing malware, closing the access vector the attacker used, patching the exploited vulnerability, and resetting all potentially compromised credentials. Document each step with enough specificity that a competent technician can execute it under pressure at 2am.

Step 5: Plan your communications, internal, legal, and regulatory

Communication failures are one of the most costly and preventable aspects of incident response. Your plan should establish communication protocols across three tracks simultaneously:

Internal communications: Who needs to know, in what order, and through what channel? If your email system is compromised, which is a realistic scenario in a business email compromise incident, you need an out-of-band communication method. Establish a secure messaging channel (an encrypted group chat on personal devices, for example) as your incident communication platform.

Customer and partner notifications: PIPEDA requires notification to affected individuals where there is a real risk of significant harm. Quebec Law 25 requires notification within 72 hours of becoming aware of a confidentiality incident to the Commission d’accès à l’information. Your plan should pre-draft notification templates and define who has authority to approve and send them.

Regulatory notifications: Identify the specific regulators relevant to your sector and the notification timelines that apply. If Bill C-8 applies to your organization or your clients, significant incidents must be reported promptly to the Communications Security Establishment. OSFI-regulated entities have separate notification obligations. Document these timelines explicitly in your plan.

Step 6: Establish your recovery and business continuity protocols

Recovery is the phase where your organization restores normal operations. Organizations without dedicated incident response services often experience longer recovery times and higher breach costs. The quality of your recovery depends almost entirely on decisions made before the incident: the integrity of your backups, the documentation of your systems, and the existence of alternative operating procedures for when primary systems are unavailable.

Your recovery plan should define:

• Recovery time objective (RTO), how long can your organization operate without each critical system before the impact becomes unacceptable
• Recovery point objective (RPO), how much data loss is acceptable; how frequently must backups be performed to meet that threshold
• Backup verification protocols, the schedule on which you test that backups can actually be restored, not just that the backup job completed
• Clean rebuild procedures, documented steps for rebuilding systems from a known-good baseline rather than restoring from a potentially compromised image
• Vendor and third-party escalation contacts, who to call at your cloud provider, your internet service provider, and your key technology vendors when you need emergency support

The single biggest predictor of whether a Canadian business pays a ransomware demand is whether its backups work when tested. An untested backup is not a backup, it is an assumption.

Step 7: Test your plan with simulation exercises

The first time you execute your incident response plan should not be during an actual incident. A plan that has never been tested will fail in ways you cannot anticipate: people will not know their role, communication channels will break down, the documented procedures will turn out to be incomplete or outdated, and the decisions that seemed obvious on paper will become paralysing under real pressure.

Testing takes two primary forms:

• Tabletop exercises, facilitated discussions where your response team walks through a realistic scenario step by step, without actually executing technical responses. Tabletops surface gaps in the plan, clarify role confusion, and build muscle memory for the decision points that matter. Run at minimum twice per year. Every tabletop exercise should identify process gaps, improve decision-making, and validate communication workflows before a real cyber incident occurs.
• Live simulations, controlled exercises where technical controls are actually tested: systems are isolated, alerts are triggered, and response procedures are executed in a sandboxed environment. More resource-intensive but significantly more revealing than tabletops alone.

Incident response plan checklist for Canadian organizations

Use this as a starting framework for evaluating your current plan’s completeness:

• Incident response team roster with primary and backup contacts documented
• Incident classification taxonomy with severity levels defined
• Escalation thresholds and notification trees for each severity level
• Out-of-band communication channel established and tested
• Containment procedures documented for each incident category
• Evidence preservation protocols defined before any remediation steps
• Eradication checklists for common incident types (ransomware, BEC, credential theft)
• Regulatory notification timelines documented (PIPEDA, Law 25, OSFI, CSE for Bill C-8)
• Customer notification templates drafted and pre-approved
• Backup restoration tested within the last 90 days
• Recovery time and recovery point objectives defined for critical systems
• Tabletop exercise conducted within the last six months
• Post-incident review process defined

How often should an incident response plan be updated?

At minimum, annually, and after any significant change to your technology environment, organizational structure, or regulatory obligations. In practice, your plan should be reviewed after every incident or tabletop exercise, since those events will surface gaps that need to be closed before the next one.

What is the difference between an incident response plan and a business continuity plan?

An incident response plan covers the immediate response to a cybersecurity event: detection, containment, eradication, and communication. A business continuity plan covers how your organization maintains operations during and after a disruptive event, including cyber incidents, but also natural disasters, power failures, and other disruptions. The two documents should be connected: your IRP should reference your BCP for the recovery and continuity phase, and your BCP should reference your IRP for cyber-specific incidents.

Do Canadian SMBs legally need an incident response plan?

There is no single Canadian law that requires every SMB to have a written incident response plan. However, PIPEDA’s accountability and safeguards principles effectively require organizations that handle personal information to have documented procedures for managing breaches. Quebec Law 25 adds explicit incident response obligations for businesses serving Quebec residents. Bill C-8 will require designated operators and, indirectly, their supply chains to demonstrate documented response capabilities. Cyber insurers are increasingly requiring tested plans as a precondition for coverage.

What should I do in the first 30 minutes of a breach?

Activate your incident response team through your out-of-band communication channel. Do not use email if your email system may be compromised. Isolate affected systems from the network without wiping them, preserve evidence first. Document everything you observe and every action you take, with timestamps. Contact your legal counsel and, where available, engage your breach coach immediately to coordinate legal, regulatory, and incident response activities. Do not communicate externally about the incident until your legal and communications team has been briefed. If you have an IR retainer with an external firm, activate it now.