The 72-Hour Breach Notification Clock: A Canadian Business Owner's Survival Guide

When the Clock Starts

You discover that personal information your organization holds has been accessed without authorization. Maybe it's a ransomware attack that encrypted your servers. Maybe it's a laptop left in a taxi that contains a client spreadsheet. Maybe it's an email sent to the wrong person with a list of customer names and payment histories. Maybe it's a former employee who accessed client records after their termination.

Whatever the mechanism, the clock has started. PIPEDA's breach of security safeguards regulations — which came into force in November 2018 — require organizations to respond to breaches that create a "real risk of significant harm" to individuals. The response has two components: reporting to the Office of the Privacy Commissioner of Canada and notifying affected individuals.

Neither PIPEDA nor the OPC specifies a 72-hour window. That's GDPR. PIPEDA's requirement is "as soon as feasible." In practice, the OPC interprets this as a short window measured in days, not weeks — and the factors that determine whether you're moving "as soon as feasible" include how quickly you discovered the breach, how quickly you assessed the risk of harm, and how quickly you acted on that assessment.

The organizations that get this wrong aren't usually the ones that delay intentionally. They're the ones that don't know what they're supposed to do.

The Risk of Significant Harm Assessment

Not every security incident is a reportable breach under PIPEDA. The trigger is a "real risk of significant harm." Significant harm is defined to include: humiliation, damage to reputation or relationships, financial loss, identity theft, negative effects on a credit record, and physical harm, among others.

The "real risk" assessment requires you to consider the sensitivity of the personal information involved, the probability that the information will be misused, and the potential severity of harm if it is. This isn't a legal determination — it's a judgment call that your organization makes based on the facts of the incident.

Practical examples that typically cross the threshold: a SIN or financial account number is accessed without authorization (high identity theft risk), health information is disclosed to an unauthorized party (humiliation and discrimination risk), a customer list with contact information is exposed in a cyberattack (the attacker is presumably going to use it for something). Examples that may not cross the threshold: a single encrypted email with a client name is misdirected to a wrong address where the recipient appears to have identified and deleted it, an internal document with employee names but no sensitive information is briefly accessible due to a misconfigured share setting.

The OPC's published guidance says: "when in doubt, report." Under-reporting has consequences; over-reporting does not.

What You Report to the OPC

The report to the OPC can be filed online through the Commissioner's website. It must include:

A description of the circumstances of the breach — what happened, how, and when you discovered it. The number and nature of individuals affected — an exact count if possible, an estimate if you don't know yet. The type of personal information involved — what data was exposed (names, financial details, health information, etc.). Steps taken to contain the breach — what you've done to stop ongoing exposure. Steps taken or planned to notify affected individuals.

You can file an initial report with incomplete information and supplement it as the investigation develops. The OPC understands that organizations often don't have complete information immediately. What matters is that you reported promptly with what you knew.

What You Tell Affected Individuals

Notification to affected individuals must be direct — meaning it goes directly to the affected person, not just a general website notice. The OPC specifies the content: a description of the breach, the type of personal information involved, a description of what the organization is doing to respond, steps the individual can take to protect themselves, and contact information for someone at your organization who can answer questions.

The notification must be provided "as soon as feasible" — and this is parallel to the OPC report, not sequential. You don't file with the OPC and then notify individuals. Both happen on the same timeline, as soon as the risk-of-significant-harm assessment confirms notification is required.

The content of individual notifications is where organizations often make a second mistake after the first mistake of the breach: they write vague, liability-minimizing notices that omit the details people actually need to protect themselves. A notification that says "we experienced a security incident that may have affected your information" without specifying what information was involved and what the concrete risk is does not satisfy PIPEDA and will generate more complaints than a direct notice.

The 24 Hours After Discovery

The first 24 hours matter most. The decisions made in the first day determine whether you're responding appropriately or compounding the problem.

Contain the breach first. Before anything else, stop the ongoing exposure. This might mean taking systems offline, revoking access credentials, or isolating affected devices. The breach notification obligations don't require you to notify before you contain — they run in parallel with containment.

Preserve evidence. Don't delete logs, overwrite systems, or destroy records in an attempt to clean up. Evidence of the breach is needed for your assessment, your OPC report, and potentially for law enforcement if the incident involves criminal conduct.

Assess the risk. Using the information you have, make an initial determination about whether the incident creates a real risk of significant harm. Document your reasoning.

Notify your legal counsel. Not because you're expecting litigation — because counsel can help you navigate the reporting obligations and draft appropriate individual notifications.

Start the OPC report. Don't wait until the investigation is complete. File the initial report with what you know.

The Real Risk of Significant Harm Assessment — In Detail

The risk of significant harm assessment is the pivot point of the entire breach response. Get it wrong in either direction and the consequences compound.

Underassessing risk — concluding no significant harm is possible when it is — means failing to report a breach you should have reported. When the OPC later finds out (through a complaint from an affected individual, through a pattern investigation, through your own disclosure), you face findings on both the breach and the failure to report. The OPC has been unequivocal that under-reporting is treated seriously.

Overassessing risk — reporting every minor incident as a significant harm breach — doesn't result in penalties. The OPC would rather receive over-reports than under-reports, and a report that the OPC assesses doesn't require further action is far better than a failure to report that the OPC discovers later.

The factors the OPC's regulations specify for the assessment:

Sensitivity of the information. The OPC considers SINs, financial account numbers, health information, and passwords to be among the highest-sensitivity categories. Exposure of these categories almost always satisfies the significant harm threshold. Names and email addresses alone typically don't, unless the context creates harm potential (exposing names from a health clinic's system implies the individuals are patients, which is itself sensitive).

Probability of misuse. A laptop stolen by someone who broke into a car is more likely to be wiped and resold than exploited for the data. A database accessed by a sophisticated threat actor targeting financial institutions is far more likely to result in fraud. The probability assessment should consider who likely had access to the information, what they could do with it, and whether there's evidence of actual misuse.

Severity of potential harm. Financial harm — identity theft, fraudulent account access, tax fraud using a stolen SIN — is both severe and measurable. Reputational harm — embarrassment from disclosure of sensitive personal information — can be severe even without financial loss. Physical harm is possible in domestic violence or stalking contexts where a home address is exposed. The OPC's definition of significant harm is explicitly non-exhaustive.

Nature of the organization. A breach at a financial institution has higher harm potential than the same breach at a retail business, because the individuals' relationship with a financial institution implies exposure of financial data. A breach at a healthcare provider has higher harm potential for health information specifically.

Hour-by-Hour: The First 48 Hours

Hours 0-2: Confirm and contain

Don't panic, but move immediately. Confirm that a breach has actually occurred — not every security alert is a breach. If confirmed, contain: revoke credentials, take systems offline if necessary, preserve logs. Do not delete anything. Notify your IT lead and your designated privacy person simultaneously.

Hours 2-6: Assemble the response team

Your breach response team should include: the privacy-designated person, your IT lead or security contact, your legal counsel (contact immediately — privilege attaches to communications made for legal advice), and your CEO or equivalent if not already involved. Brief them on what is known, what is uncertain, and what containment actions have been taken.

Hours 6-12: Initial scope assessment

Determine: What systems were involved? What personal information was potentially exposed? How many individuals are potentially affected? What is the likely cause? What is the status of containment? Document everything you know and everything you don't know yet.

Hours 12-24: Risk of significant harm assessment

With the scope assessment in hand, make an initial risk determination. Is this a breach that creates a real risk of significant harm? Document the reasoning — not just the conclusion. If yes, begin preparing the OPC report and individual notifications in parallel.

Hours 24-48: OPC notification (if required)

File an initial report with the OPC as soon as feasible after determining that the risk threshold is met. The OPC accepts preliminary reports with incomplete information — you can supplement as the investigation develops. Do not wait until you have complete information to report.

Hours 24-72: Individual notification (if required)

Begin notifying affected individuals directly. This means person-by-person notification, not a website banner. The notification must be in plain language, must explain specifically what happened, must identify what information was involved, and must tell individuals what they can do to protect themselves.

What the Individual Notification Must Say

The PIPEDA breach notification regulations specify the required content. Your notification must include:

A description of the circumstances of the breach — enough detail that the individual understands what happened without being so technical that the explanation is unintelligible.

The period during which the breach occurred, if known.

The type of personal information that was involved — be specific. "Your personal information may have been affected" is inadequate. "Your name, email address, and account balance as of March 15 were potentially accessed" is adequate.

The number of individuals affected — this goes in the OPC report. Individual notifications don't require this figure.

A description of what the organization is doing to mitigate or investigate — "we have engaged a cybersecurity firm to investigate and have taken the affected system offline."

Steps the individual can take to protect themselves — this is the section most organizations write poorly. Specific steps: place a fraud alert with Equifax Canada and TransUnion Canada (provide phone numbers), monitor your credit report for unusual activity, consider a credit freeze, watch for phishing attempts that may use your information, review your financial accounts for unauthorized transactions. Generic "please remain vigilant" language doesn't satisfy this requirement.

Contact information for someone at your organization who can answer questions — a real person or a designated phone line, not a general inbox.

Law 25 and PHIPA: Different Requirements in the Same Organization

If you have Quebec customers, Law 25's breach notification requirements apply alongside PIPEDA. Law 25 requires notification to the Commission d'accès à l'information (CAI) and to affected individuals. The CAI notification requirement is triggered by a confidentiality incident that presents a risk of serious injury — a standard comparable to PIPEDA's "real risk of significant harm."

Law 25's individual notification must include additional elements not explicitly required under PIPEDA: the circumstances of the incident, the date or period of occurrence, a description of the personal information involved, measures taken to reduce the risk of injury, and any measures the individual can take to reduce the risk or mitigate injury.

Ontario's PHIPA has yet another set of requirements for health information custodians. A PHIPA breach must be reported to the IPC if the breach involves health information and meets the statutory threshold. PHIPA notification requirements have additional specificity requirements for healthcare contexts.

Organizations subject to multiple frameworks — which includes most national Canadian businesses — need breach response plans that address all applicable frameworks simultaneously, not sequentially.

What Happens If You Don't Report

Failure to report a reportable breach is a violation under PIPEDA. The OPC can investigate the failure to report as a separate compliance issue from the breach itself. The consequences are reputational and regulatory rather than primarily financial — PIPEDA doesn't have a fine structure for failure to report the way GDPR does — but the reputational damage of a finding that you had a breach and concealed it is significant.

More practically: breaches that aren't reported tend to come to light anyway. Affected individuals discover fraud or identity theft and trace it. A journalist receives a tip. A former employee discloses. A security researcher finds exposed data. When the breach comes to light through external discovery rather than your own report, the OPC investigation examines not just the breach but why you didn't report it.

The organizations that handle breaches well — that emerge with relationships intact and no lasting regulatory damage — are the ones that know these obligations before the breach happens and execute on them clearly when it does. The ones that do it poorly are the ones that improvise, delay, minimize, and underestimate both the harm and the OPC's interest in how they respond.