PIPEDA's breach notification rules sit in Division 1.1 of the Act - Sections 10.1 through 10.3 - and they have been mandatory since 1 November 2018. Any organisation subject to PIPEDA that experiences a breach of security safeguards must decide whether the incident crosses a specific harm threshold and, if it does, report to the Office of the Privacy Commissioner of Canada (OPC), notify every affected individual, and alert any third party that could help reduce the damage. Separately, every breach - whether it crosses that threshold or not - must be logged in a record that the OPC can request at any time.
These are not suggestions. Under Section 28 of PIPEDA, knowingly failing to report, notify, or keep records is a criminal offence carrying fines of up to CAD 100,000 per violation.
What Counts as a Breach of Security Safeguards
Section 2(1) of PIPEDA defines a breach of security safeguards as the loss of, unauthorised access to, or unauthorised disclosure of personal information resulting from a failure of an organisation's security safeguards under Clause 4.7 of Schedule 1, or from a failure to establish those safeguards in the first place. That last part matters: if an organisation never implemented reasonable protections, the resulting exposure still counts as a breach.
The definition is broad. A ransomware attack that encrypts a customer database, an employee emailing a spreadsheet of client details to the wrong recipient, a stolen laptop containing unencrypted personnel files, a misconfigured cloud storage bucket exposing records to the public internet - all of these qualify. Even a system glitch that accidentally displays one customer's account details to another customer can constitute a breach, as the OPC confirmed in its 2024 investigation into Brinks Home (PIPEDA Findings #2024-002).
The Real Risk of Significant Harm Test
Not every breach triggers reporting and notification obligations. The threshold is whether the breach creates a real risk of significant harm (RROSH) to an individual. Section 10.1(7) defines significant harm broadly: bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on a credit record, and damage to or loss of property.
Section 10.1(8) sets out two mandatory factors for the RROSH assessment:
| Factor | What to consider |
|---|---|
| Sensitivity of the personal information | Medical records, financial data, government-issued identifiers (SIN, passport numbers), and biometric data are inherently sensitive. Context matters too - a home address becomes more sensitive when paired with alarm system details, as the OPC noted in the Brinks Home case. |
| Probability of misuse | Who accessed or could access the data? Was there malicious intent (e.g. a cyberattack) or was it accidental? How long was the information exposed? Has the data been recovered? Was it encrypted or otherwise protected? |
The OPC launched a new online Privacy Breach Risk Self-Assessment Tool in March 2025 that walks organisations through a guided questionnaire to evaluate whether a breach meets the RROSH threshold. The tool does not collect any identifying information and its results can be downloaded and included in internal breach records or attached to a formal report.
Alberta's experience is instructive here. That province's comparable regime has been interpreted very broadly, treating virtually any breach involving personal information as meeting the harm threshold. The OPC's approach under PIPEDA has been somewhat more nuanced - the Brinks Home investigation, for instance, found that accidental exposure to a small number of known customers with no malicious intent did not meet the RROSH standard - but organisations should err on the side of reporting when in doubt.
Reporting to the Privacy Commissioner
When a breach meets the RROSH threshold, Section 10.1(1) requires the organisation to report it to the OPC. The report must be made as soon as feasible after the organisation determines the breach has occurred. PIPEDA does not prescribe a hard deadline in hours or days, unlike the GDPR's 72-hour rule, but the OPC expects organisations to act without unreasonable delay.
The Breach of Security Safeguards Regulations (SOR/2018-64) specify exactly what the report must contain:
- A description of the circumstances and cause of the breach (if known)
- The date or period during which the breach occurred, or an approximation
- A description of the personal information involved, to the extent known
- The number of affected individuals, or an approximation
- Steps taken to reduce the risk of harm or mitigate it
- Steps taken or planned to notify affected individuals
- Contact information for a person who can answer the OPC's follow-up questions
Since May 2024, the OPC has offered a secure online breach reporting form that organisations can use to submit reports electronically. Organisations can also submit supplementary information if they learn new details after the initial report. The report may be sent by any secure means of communication.
Notifying Affected Individuals
Section 10.1(3) creates a parallel obligation: unless prohibited by another law, the organisation must notify each affected individual when the breach creates a real risk of significant harm to that individual. The notification must go out as soon as feasible after the organisation determines the breach has occurred.
The Regulations require individual notifications to include:
- A description of what happened
- The date or period of the breach
- A description of the personal information involved
- Steps the organisation has taken to reduce the risk
- Steps the individual can take to protect themselves (e.g. changing passwords, monitoring credit reports, placing fraud alerts)
- Contact information for someone who can answer further questions
Section 10.1(4) adds that the notification must contain enough information for the individual to understand what the breach means for them personally and what protective steps, if any, are available. This is not a box-ticking exercise - a vague, generic notice that omits known details will not satisfy the requirement.
The OPC's joint investigation with the UK Information Commissioner into the 23andMe breach (PIPEDA Findings #2025-001) illustrates the consequences of inadequate notification. The investigation found that 23andMe's notifications failed to include complete information about the types of personal information compromised and did not disclose that some data had been posted for sale online. Individuals whose accounts were directly accessed were not notified until more than a month after the forensic analysis concluded.
Direct vs Indirect Notification
The default is direct notification: in person, by telephone, mail, email, or any other form a reasonable person would consider appropriate. Indirect notification - through a public communication such as a website notice or newspaper advertisement - is permitted only in three circumstances: direct notification would cause further harm to the individual, it would cause undue hardship for the organisation, or the organisation does not have contact information for the affected person.
Notifying Third-Party Organisations
Section 10.2(1) adds a third notification duty. An organisation that notifies individuals must also notify any other organisation, government institution, or part of a government institution that it believes could help reduce or mitigate the harm. A company that suffers a payment card breach, for example, should notify the affected card networks and potentially law enforcement. This notification must also be given as soon as feasible.
Section 10.2(3) explicitly authorises the disclosure of personal information to those third parties without the individual's consent, provided the disclosure is made solely to reduce or mitigate harm from the breach. This removes what would otherwise be a significant barrier - organisations do not need to obtain valid consent before sharing breach-related details with entities that can help.
Maintaining Breach Records
Section 10.3 imposes a record-keeping obligation that applies to every breach, regardless of severity. Even if an organisation concludes that a breach does not create a real risk of significant harm, it must still document it.
The Regulations require these records to be maintained for 24 months from the date the organisation determined the breach occurred. The records must contain enough information to enable the OPC to verify compliance with the reporting and notification obligations under Section 10.1. In practice, this means including details of the RROSH assessment - what factors were considered and why the organisation concluded that reporting was or was not required.
For breaches that were not reported, the OPC guidance recommends including a brief explanation of why the organisation determined the RROSH threshold was not met. This protects the organisation if the OPC later requests access to its breach records under Section 10.3(2).
What a Strong Breach Record Looks Like
| Element | Detail |
|---|---|
| Date of discovery | When the breach was identified and by whom |
| Date(s) of breach | When the breach occurred or the approximate period |
| Description | What happened, what systems were involved, root cause if known |
| Personal information involved | Categories and volume of data affected |
| Number of individuals | Actual or estimated count |
| RROSH assessment | Sensitivity analysis, probability of misuse analysis, conclusion reached |
| Actions taken | Containment steps, remediation, notifications sent (or rationale for not sending) |
| Notification details | Who was notified (OPC, individuals, third parties), when, and how |
Penalties for Non-Compliance
Section 28 of PIPEDA makes it an offence to knowingly fail to comply with the breach reporting, notification, or record-keeping requirements. The word knowingly is critical - it means the offence requires intent, not mere negligence. But an organisation that is aware of a breach, assesses it as meeting the RROSH threshold, and deliberately chooses not to report is squarely within scope.
Fines can reach CAD 100,000 per violation. The government has stated that this could apply per individual not notified, meaning a breach affecting thousands of people could theoretically generate enormous exposure. The OPC itself does not prosecute offences or issue fines directly - it refers potential offences to the Attorney General of Canada, who may direct the Public Prosecution Service to proceed.
Beyond the criminal penalty, organisations face reputational damage, potential complaints to the OPC under Section 11, and civil proceedings before the Federal Court under Section 14. The Court can order organisations to correct their practices and award damages for humiliation suffered by complainants.
How This Compares to Other Breach Notification Regimes
PIPEDA's breach notification framework sits between the GDPR and various US state-level regimes in terms of strictness. The GDPR requires notification to the supervisory authority within 72 hours and to individuals without undue delay when the breach poses a high risk. PIPEDA uses the vaguer standard of "as soon as feasible" but pairs it with a criminal offence for non-compliance, something the GDPR handles through administrative fines instead.
Brazil's LGPD breach notification rules require reporting to the ANPD within a reasonable timeframe, with similar content requirements. The CPRA in California does not impose a general breach notification requirement on the privacy regulator but does require notification to affected consumers. Provincial Canadian laws add another layer - Quebec's Law 25, Alberta's PIPA, and British Columbia's PIPA each have their own breach reporting obligations that may apply alongside PIPEDA depending on the province and sector.
| Regime | Reporting deadline | Threshold | Record-keeping |
|---|---|---|---|
| PIPEDA (Canada) | As soon as feasible | Real risk of significant harm | All breaches, 24 months |
| GDPR (EU/EEA) | 72 hours to authority | Risk to rights and freedoms | All breaches, no fixed period |
| LGPD (Brazil) | Reasonable timeframe | Risk or relevant damage | Not explicitly mandated |
| POPIA (South Africa) | As soon as reasonably possible | Reasonable grounds to believe compromise | Not explicitly mandated |
Practical Steps for Your Organisation
If your website or business collects personal information from Canadian visitors - names, email addresses, payment details, cookie identifiers that can be linked to individuals - PIPEDA's breach notification rules likely apply to your operations. Here is a practical checklist:
Before a breach happens: Designate a breach response team. Draft a response plan that maps out who assesses the RROSH, who drafts notifications, and who contacts the OPC. Use the OPC's online self-assessment tool during tabletop exercises so your team is familiar with it before a real incident occurs.
When a breach is discovered: Contain first - isolate affected systems, revoke compromised credentials, preserve forensic evidence. Then assess the RROSH by examining the sensitivity of the exposed data and the probability of misuse. Document every step. If the threshold is met, report to the OPC and notify individuals as soon as feasible. Identify third parties that can help mitigate harm and notify them too.
After notification: Log the breach in your records with full details of the assessment and response. Retain those records for at least 24 months. Review what went wrong and update your security safeguards to prevent recurrence. Consider whether additional privacy impact assessments are warranted for the affected systems.
Frequently Asked Questions
Does PIPEDA require breach notification for every data breach?
No. Reporting to the OPC and notifying individuals is required only when a breach creates a real risk of significant harm. However, the organisation must keep a record of every breach - including those that do not meet the RROSH threshold - for 24 months.
How quickly must a PIPEDA breach be reported to the OPC?
The Act requires reporting "as soon as feasible" after the organisation determines a breach has occurred and meets the RROSH threshold. There is no fixed deadline in hours or days, but unreasonable delays will not be tolerated. Organisations should have a response plan ready so they can act within days of confirming a reportable breach.
What is the real risk of significant harm (RROSH) test?
The RROSH test requires assessing two factors: the sensitivity of the personal information involved in the breach and the probability that the information has been, is being, or will be misused. Significant harm includes financial loss, identity theft, humiliation, reputational damage, and bodily harm among other categories listed in Section 10.1(7).
Can an organisation be fined for failing to report a breach under PIPEDA?
Yes. Under Section 28, knowingly failing to report a breach, notify affected individuals, or maintain breach records is a criminal offence carrying fines of up to CAD 100,000 per violation. The OPC refers potential offences to the Attorney General of Canada for prosecution.
Who is responsible for reporting a breach when a third-party processor is involved?
The organisation that controls the personal information bears the reporting obligation, even if the breach occurred at a third-party processor. OPC guidance confirms that the principal organisation retains responsibility for breach reporting when it has transferred personal information to a processor.
Does PIPEDA's breach notification apply to small businesses?
Yes. All organisations subject to PIPEDA must comply with the breach reporting, notification, and record-keeping requirements regardless of size. There is no small business exemption for Division 1.1.
What should a breach record contain if the breach was not reported to the OPC?
The record must contain enough information for the OPC to verify compliance. For unreported breaches, this should include a description of the incident, the personal information involved, the RROSH assessment performed, and an explanation of why the organisation concluded the threshold was not met.
Stay Ahead of Your Breach Obligations
If your website uses cookies or tracking technologies that collect personal information from Canadian visitors, a cookie-related data breach could trigger PIPEDA's notification requirements. Kukie.io's cookie scanner identifies every cookie on your site - including third-party trackers you may not be aware of - so you know exactly what personal data is being collected and can plan your breach response accordingly.
