Written by Mike Pearlstein, CISSP, CEO of Fusion Computing Limited, securing Canadian business IT since 2012 across Toronto, Hamilton and Metro Vancouver.
KEY TAKEAWAYS
- An incident response plan is a documented playbook covering who decides, who acts and which regulator gets called.
- NIST SP 800-61 Rev. 3 superseded the 2012 Rev. 2 guide in April 2025 and folds response into the Cybersecurity Framework 2.0 functions.
- PIPEDA sets no hour count. Its s.10.1 standard is “as soon as feasible”, and every breach goes in a register kept 24 months.
- Statistics Canada put business spending on recovery from cyber incidents at CA$1.2 billion in 2023, double the 2021 figure.
- Across our 47 Canadian SMB engagements through Q1 2026 we measured how many after-hours contact lists survived a cold call. Six did.
Book an IT Business Consultation
What is an incident response plan, and why every Canadian SMB needs one in 2026?
An incident response plan (IRP) is a documented playbook that defines who does what when a cybersecurity incident hits a Canadian small business. According to Statistics Canada, 16% of Canadian businesses were struck by a cyber security incident in 2023, and only 26% held any documented cyber security policy at all.
Every organization handling customer data, employee records or payment information needs one. The same release put Canadian business spending on recovery from cyber incidents at CA$1.2 billion in 2023, double the roughly CA$600 million spent in 2021.
For a 30-person firm, a week of downtime plus a notification mail-out to 4,000 customers runs six figures before anyone counts lost trust. A tested plan compresses that timeline. Pair it with managed detection and response and median time-to-isolation drops from weeks to hours. A workable SMB plan is 8 to 15 pages, scoped through managed cybersecurity services.
The 6 phases of incident response (NIST SP 800-61 framing)
According to NIST SP 800-61 Rev. 3, published in April 2025, the revision supersedes the 2012 Rev. 2 guide and folds incident handling into the Cybersecurity Framework 2.0 functions of Govern, Identify, Protect, Detect, Respond and Recover. The six operational steps below are the working sequence a Canadian SMB team executes under that framing.
Each step has a clear exit criterion, which is what stops a 3 a.m. response from drifting into improvisation. Rev. 2 set out four life-cycle phases; splitting the middle one into three discrete steps is how I get a 40-seat team to hand work off cleanly. The table below is the version I put in front of Ontario and British Columbia clients.
| Phase | Activities | Owner | Output |
|---|---|---|---|
| 1. Preparation | Define team, draft playbook, deploy EDR, MFA and backups, run drills. | IT manager and MSP. | Approved IRP, drill log. |
| 2. Detection & Analysis | Confirm alert, classify severity, scope affected systems, open ticket. | Technical lead. | Severity rating, scope memo. |
| 3. Containment | Isolate hosts, disable accounts, preserve evidence, hold communications. | Incident commander. | Containment timestamp, evidence chain. |
| 4. Eradication | Remove malware, kill persistence, rotate credentials, patch root cause. | Technical lead and MSP. | Clean-system attestation. |
| 5. Recovery | Restore from clean backups, monitor, validate, resume operations. | IT manager. | Restored services, RTO and RPO log. |
| 6. Post-Incident Review | Document timeline, capture lessons, update plan within 30 days. | Executive sponsor. | After-action report, plan v.next. |
Roles and responsibilities to define before an incident
According to the Baseline Cyber Security Controls for Small and Medium Organizations, a small organization must hold a plan that says who handles incidents. The Canadian Centre for Cyber Security also wants contact information for external parties, stakeholders and regulators, plus an up-to-date hard copy for when soft copies are unavailable.
An effective IRP covers 4 to 5 response roles, each with a primary owner plus a backup, and writes the decision rights into the document. Without an owner on every role, the first hour of a PIPEDA-reportable breach goes to a meeting instead of to isolation.
| Role | Typical SMB owner | Decision rights |
|---|---|---|
| Incident commander | IT manager or CEO. | Declares severity, authorizes isolation, owns the timeline. |
| Technical lead | Senior systems engineer or MSP on-call. | Executes containment, eradication and restore. |
| Communications lead | COO or marketing director. | Approves customer, staff and media messages. |
| Legal & privacy lead | External counsel or fractional DPO. | Calls the real-risk-of-significant-harm test, signs OPC filings. |
| Executive sponsor | CEO or owner. | Approves ransom posture, insurance notice, board update. |
The contact list lives beside the role table: phone, email and after-hours numbers for the response team, the MSP, legal counsel, the insurance broker, the OPC and the local RCMP cybercrime unit. Print it, because the baseline asks for a hard copy. Want a second pair of eyes on yours? Send us the role table and a CISSP-led engineer will pressure-test it.
The Canadian regulatory clock (PIPEDA, Bill C-8 cyber security incident reporting, IPC Ontario for PHI)
According to PIPEDA section 10.1, no hour count applies. An organization reports a breach to the Privacy Commissioner “as soon as feasible after the organization determines that the breach has occurred”. Canada has no single breach clock, so the plan should pre-classify incidents against each regime before the legal lead needs an answer.
| Regime | Trigger | Statutory standard | Recipient |
|---|---|---|---|
| PIPEDA s.10.1 | Breach with real risk of significant harm. | As soon as feasible. No fixed hours. | OPC and affected individuals. |
| Bill C-8 (CCSPA) | Cyber security incident at a designated operator. | Immediately, with a written report to follow. | Canadian Centre for Cyber Security and sector regulator. |
| PHIPA s.12(2)(a) | Theft, loss or unauthorized use of PHI. | At the first reasonable opportunity. | The individual, plus the IPC on the O. Reg. 329/04 triggers. |
| OSFI advisory | Technology or cyber security incident at a federally regulated institution. | Within 24 hours, or sooner if possible. | OSFI Technology Risk Division and lead supervisor. |
| Cyber insurance | Suspected covered event. | Per policy, commonly 24 to 72 hours. | Broker and carrier breach hotline. |
Two foreign deadlines get quoted at me constantly. The 72-hour rule is GDPR Article 33, and the 60-day one is HIPAA. Quebec’s Law 25 requires prompt notification without naming an hour count, and British Columbia’s PIPA runs its own duty. Fusion Computing works to a 72-hour internal target because insurers expect it, which is an operating standard rather than a Canadian statutory one.
Logging is the duty people forget. Under s.6(1) of the Breach of Security Safeguards Regulations, every breach goes in an internal register kept 24 months, reportable or not. Failure to log can itself become the violation. Our PIPEDA compliance guide carries the template.
Communication templates: customers, regulators, insurer, media
According to the federal baseline controls published at cyber.gc.ca, the plan should carry contact information for communicating with external parties, stakeholders and regulators. Pre-written, counsel-reviewed templates are how a 40-seat firm meets that without a 1 a.m. drafting session. Each template leaves only the variable fields blank: date, system, scope, remediation.
Customer notice. What happened, what data was involved, what you are doing, what they should do. Counsel signs before send, because PIPEDA expects the notice to let an individual grasp the significance of the breach.
Regulator filing. The OPC breach report form, an IPC Ontario report, the OSFI incident notification and a Bill C-8 submission to the Cyber Centre, pre-mapped to your severity matrix.
Insurance claim. Broker hotline, policy number, factual summary, request for panel lawyers. Reporting late is the most common reason claims get reduced, and most policies want it inside 72 hours.
Staff updates. A daily bulletin plus an executive briefing, sent out of band when Microsoft 365 is the tenant under attack. Security awareness training keeps people aligned. I have never seen a quiet channel end well.
Tabletop exercises: how often and what to test
A Canadian SMB should run a tabletop at least twice a year, plus 1 functional test in every 12-month cycle: a live restore from immutable backup. Plans never tested are fiction. Underwriters now ask for the most recent tabletop date on the renewal questionnaire, and a blank answer raises the premium.
A working tabletop runs 90 minutes. A facilitator presents a scenario, say a managed detection service flagging credential theft on a finance laptop. The team executes the IRP out loud while a scribe captures every gap. Output is a one-page after-action report with 3 to 5 corrective actions, each with an owner and a 14-day deadline.
Functional tests are heavier. Pull a non-production server, simulate compromise, restore, then time it against the documented Recovery Time Objective. In our practice the first one almost always exposes a backup that has been silently failing for months.
Cyber insurance requirements for IR plans
Most Canadian carriers now want a documented IRP, evidence of a recent tabletop and proof of immutable backup as underwriting conditions. A carrier may still write the policy without them, and then the premium climbs while ransomware sub-limits widen until the coverage is mostly cosmetic.
Underwriters typically check 5 controls. MFA on email and remote access. EDR or XDR on every endpoint, whether Microsoft Defender XDR or an equivalent behavioural platform. Immutable or air-gapped backups tested inside 12 months. A documented IRP. A tabletop inside 12 months.
Pair the plan with our cyber insurance coverage checklist before the questionnaire lands, and see best practices for disaster recovery for the continuity side. If renewal is inside 60 days, book a call and we will work it with you.
“A 2025 client had a 14-page IRP that named every role correctly. When ransomware hit on a Saturday, nobody could log in to read it. The document lived on SharePoint, behind the same Entra ID tenant the attacker was holding. We rebuilt response from a printed copy I had in my truck. Every Fusion Computing IRP now ships with a printed binder and a phone-cached PDF.”
Mike Pearlstein, CISSP, CEO, Fusion Computing.
IRP versus business continuity plan: which a Canadian SMB builds first
According to the Cyber Centre baseline, a small organization needs a basic plan covering incidents of varying severity before anything more elaborate. An IRP handles a cyber incident end to end. A business continuity plan spans any disruption at all: fire, flood, power, vendor failure. The IRP sits inside the BCP as its cyber chapter.
Build the IRP first. Cyber incidents are the most frequent disruption a Canadian SMB faces, and the only category carrying a statutory notification duty under PIPEDA, PHIPA or Bill C-8. A burst pipe triggers no OPC report. A stolen mailbox does.
The sequencing I use with a 25 to 150 seat client is a 12-page IRP in month one, a tabletop in month two, then the continuity plan.
Common IR plan mistakes Canadian SMBs make
Most failed IRPs fail for 5 reasons. The plan is unreachable mid-incident. It has never been tested. The contact list is stale. The approval chain is undefined. Backups have not been restored from in a year.
Unreachable plan. The IRP lives on SharePoint behind the Entra ID tenant under attack. Print copies. Store an offline PDF on a phone or a thumb drive, which is exactly what the Cyber Centre baseline asks for.
Never tested. The plan reads cleanly and nobody has walked it. Schedule a tabletop inside 30 days.
Stale contact list. MSP managers change. Lawyers retire. The broker moves firms. Re-verify every quarter.
Undefined approval chain. Marketing emails customers before the lawyers have signed the wording off, and the correction costs more trust than the breach did. It is the mistake I see most in the first 24 hours.
Untested backups. Backups show green for 18 months, then fail on the one restore that matters. Restore a critical workload quarterly and log it.
How Fusion Computing builds and tests IR plans
We build and test incident response plans for Canadian businesses with 15 to 200+ users out of Toronto, Hamilton and Metro Vancouver. The work is CISSP-led, aligned to NIST SP 800-61 Rev. 3, and delivered with a printed binder, a phone-cached PDF and a recorded tabletop. Our engineers found the average client closes 11 of 13 gap-assessment findings within 60 days of that first tabletop. Start with a 30-minute scoping session.
Frequently asked questions
Does a small business really need a formal incident response plan?
Yes. PIPEDA expects every Canadian organization handling personal information to demonstrate breach detection, response and notification capability, and the Cyber Centre baseline asks small organizations for a written plan outright. Most carriers now require a documented IRP and a recent tabletop as conditions of coverage. A 6-page plan tested once beats a 60-page plan never opened.
How often should the IRP be updated?
Update the plan after every tabletop, after every real incident and on a fixed annual review. Other triggers include staff turnover, a new core system, a carrier change and regulatory shifts such as Bill C-8 designations. A practical cadence is light updates twice a year plus a full review annually.
What is a tabletop exercise and how is one run?
A tabletop is a facilitated 90-minute walkthrough of a realistic scenario that never touches production systems. The facilitator presents it, the team executes the IRP out loud, and a scribe captures every gap. Output is a one-page after-action report with 3 to 5 corrective actions, each with an owner and a 14-day deadline. A first tabletop usually surfaces 8 to 12 issues.
What is the difference between an IRP and a business continuity plan?
An IRP handles a cyber incident: detection, containment, eradication, recovery, notification. A BCP spans any disruption, including fire, water damage, power outage and vendor failure. The IRP is the cyber chapter of the BCP. Build the IRP first, because a cyber breach carries a statutory notification duty under PIPEDA that a power outage does not.
What does PIPEDA require during a breach?
PIPEDA requires three actions. Determine whether the breach creates a real risk of significant harm using a sensitivity-times-probability test. If the threshold is met, report to the OPC and notify affected individuals as soon as feasible under s.10.1. Log every incident in an internal register kept 24 months under s.6(1) of the Breach of Security Safeguards Regulations.
Who should be on the incident response team?
A Canadian SMB response team typically has 4 roles plus backups. An incident commander, usually the IT manager or CEO. A technical lead, a senior systems person or the MSP on-call engineer. A communications lead, often the COO. A legal and privacy lead, external counsel or a fractional DPO. An executive sponsor approves ransom posture.
How fast must a Canadian SMB notify the OPC under PIPEDA?
PIPEDA s.10.1 sets the standard as “as soon as feasible after the organization determines that the breach has occurred”. No hour count appears in the Act. The widely quoted 72 hours is GDPR Article 33, and Quebec’s Law 25 requires prompt notification without naming a deadline either. Fusion Computing works to a 72-hour internal target because carriers expect it.
Does your Canadian business have a tested incident response plan?
Book a call with a CISSP-led Fusion Computing engineer. We map your gaps against NIST SP 800-61 Rev. 3, PIPEDA and Bill C-8, then outline the IRP your carrier and the OPC expect to see.
Related reading: Ransomware Recovery Cost in Canada: a 2026 downtime and recovery benchmark, with sourced figures for ransom, downtime and recovery cost at Canadian SMBs.

