Canada — Breach Notification

Canada's federal mandatory breach notification regime came into force on November 1, 2018, when the Digital Privacy Act amendments to the Personal Information Protection and Electronic Documents Act (PIPEDA) took effect alongside the Breach of Security Safeguards Regulations, SOR/2018-64. Organizations subject to PIPEDA must now report certain breaches to the Office of the Privacy Commissioner of Canada (OPC), notify affected individuals, and maintain records of every breach—whether or not it crossed the notification threshold.

## Scope — Who is covered

PIPEDA applies to private-sector organizations engaged in commercial activities in provinces without substantially similar provincial privacy legislation (everywhere except British Columbia, Alberta, and Quebec for most purposes), and to federally regulated works, undertakings, and businesses (banks, telecommunications carriers, interprovincial transportation companies, broadcasters) across Canada, regardless of province. When PIPEDA applies, its breach notification rules apply—there are no exemptions by organization size, sector, or data volume.

## The triggering standard — "Real risk of significant harm" (RROSH)

Under subsection 10.1(1) of PIPEDA, an organization must report a "breach of security safeguards" to the OPC if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual. The same RROSH threshold triggers the obligation to notify affected individuals under subsection 10.1(3) and to notify other organizations or government institutions that may be able to reduce or mitigate harm under section 10.2.

PIPEDA defines a "breach of security safeguards" (often called a data breach) as "the loss of, unauthorized access to or unauthorized disclosure of personal information resulting from a breach of an organization's security safeguards that are referred to in clause 4.7 of Schedule 1 or from a failure to establish those safeguards." This covers loss (e.g., a laptop stolen), unauthorized access (e.g., an employee accessing customer files without business need, or a cyberattack), and unauthorized disclosure (e.g., emailing personal information to the wrong recipient).

Subsection 10.1(7) sets out a non-exhaustive statutory definition of "significant harm": it includes bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record and damage to or loss of property.

Subsection 10.1(8) lists two mandatory factors for assessing whether a breach creates a real risk of significant harm:

• (a) the sensitivity of the personal information involved in the breach; and
• (b) the probability that the personal information has been, is being or will be misused.

The OPC's October 2018 guidance, What you need to know about mandatory reporting of breaches of security safeguards, emphasizes that the assessment is contextual and fact-specific. The RROSH standard is drawn from Alberta's Personal Information Protection Act (Alberta PIPA), which came into effect in 2010, and OPC enforcement practice has applied it broadly: in the first year of mandatory reporting (November 2018–October 2019), the OPC received 680 breach reports covering over 28 million Canadians, a six-fold increase over the prior voluntary-reporting period. A 2019 OPC breach record inspection found that 20 percent of the sample records where organizations had concluded there was no RROSH either met the threshold in the OPC's view or lacked sufficient detail for the OPC to verify the determination—signaling that the threshold is lower in practice than many organizations initially assessed.

## Timeline — "As soon as feasible"

PIPEDA does not impose a fixed deadline (unlike GDPR's 72-hour rule). Subsection 10.1(2) requires that the report to the OPC "shall be made in the prescribed form and manner as soon as feasible after the organization determines that the breach has occurred." The same "as soon as feasible" language governs notification to individuals (subsection 10.1(6)) and notification to third parties (subsection 10.2(2)). The OPC has clarified that "as soon as feasible" means as soon as is reasonably possible in the circumstances—organizations need not wait until every detail (cause, full scope) is confirmed before reporting, and should submit the initial report promptly and supplement it as facts develop.

## Enforcing authority and penalties

The Office of the Privacy Commissioner of Canada (OPC) receives breach reports, may request access to breach records under subsection 10.3(2), and may initiate a complaint or investigation under section 11. The OPC does not issue administrative fines directly. However, knowingly contravening PIPEDA's reporting, notification, or record-keeping requirements is a quasi-criminal offence under the Act. The OPC may refer suspected offences to the Attorney General of Canada, which may lead to prosecution by the Director of Public Prosecutions and a fine of up to $100,000 per violation. This criminal-penalty structure differs sharply from GDPR's administrative fine regime and is rarely invoked in practice, but it underscores the mandatory nature of the obligation.

## Record-keeping for all breaches

Section 10.3(1) requires organizations to "keep and maintain a record of every breach of security safeguards involving personal information under its control," whether or not the RROSH threshold was met. Under section 6(1) of the Breach of Security Safeguards Regulations, records must be maintained for 24 months after the organization determines the breach occurred. Section 6(2) requires that records contain "any information that enables the Commissioner to verify compliance with subsections 10.1(1) and (3)"—including, for sub-threshold breaches, a brief explanation of why the organization concluded there was no RROSH.

Source: Personal Information Protection and Electronic Documents Act, sections 10.1–10.3 Source: Breach of Security Safeguards Regulations, SOR/2018-64 Source: Digital Privacy Act, S.C. 2015, c. 32 Source: Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (October 2018) Source: Office of the Privacy Commissioner of Canada, The Digital Privacy Act and PIPEDA (November 1, 2018 effective date)

The Breach of Security Safeguards Regulations, SOR/2018-64, prescribe specific mandatory content for both the breach report to the Office of the Privacy Commissioner of Canada (OPC) under subsection 10.1(2) of PIPEDA and the notification to affected individuals under subsection 10.1(3). These requirements are distinct: the report to the OPC serves an oversight and enforcement function, while the notification to individuals must enable them to understand the significance of the breach and take steps to reduce or mitigate harm.

## Report to the OPC — section 2 content requirements

Under section 2(1) of the Breach of Security Safeguards Regulations, a report to the OPC must be in writing and must contain all of the following prescribed elements:

• (a) a description of the circumstances of the breach and the cause, if known;
• (b) the date or time period when the breach occurred (or if unknown, the approximate date or period);
• (c) a description of the personal information involved in the breach;
• (d) an estimate of the number of individuals affected by the breach (or if unknown, the approximate number);
• (e) a description of the steps the organization has taken to reduce the risk of harm to individuals that could result from the breach;
• (f) a description of the steps the organization has taken or intends to take to notify affected individuals of the breach; and
• (g) the name and contact information of a person who can answer, on behalf of the organization, the OPC's questions about the breach.

The OPC expects organizations to submit the report as soon as feasible after determining the breach has occurred, even if not all details are yet known. Section 2(2) of the Regulations expressly permits organizations to supplement the initial report by submitting "any new information referred to in subsection (1) that the organization becomes aware of after having made the report." The OPC's October 2018 guidance, What you need to know about mandatory reporting of breaches of security safeguards, emphasizes that organizations should not delay reporting while waiting to complete a full root-cause investigation—initial reports should be filed promptly and updated as facts develop.

The OPC provides a standard PIPEDA Breach Report Form (available on priv.gc.ca) that tracks the section 2 requirements and includes additional fields for context (e.g., whether minors were affected, whether the breach involved a third-party processor, whether individuals have been notified). Organizations are not legally required to use the OPC's form, but the form ensures all mandatory elements are captured and provides a structured record that satisfies the statutory obligations.

## Notification to affected individuals — section 3 content requirements

Section 3 of the Breach of Security Safeguards Regulations sets out what a notification to an affected individual must contain. The notification must include:

• (a) a description of the circumstances of the breach;
• (b) the date or time period when the breach occurred (or if unknown, the approximate date or period);
• (c) a description of the personal information involved in the breach;
• (d) a description of the steps the organization has taken to reduce the risk of harm;
• (e) a description of the steps that affected individuals could take to reduce the risk of harm or mitigate harm that could result from the breach; and
• (f) a toll-free number or email address (or other contact information) that the individual can use to obtain further information about the breach.

The content overlap between the report to the OPC (section 2) and the notification to individuals (section 3) is intentional, but the notification to individuals must be tailored to the recipient. Subsection 10.1(6) of PIPEDA requires that notification "contain sufficient information to allow the individual to understand the significance of the breach and to take steps, if any are possible, to reduce the risk of harm that could result from it, or to mitigate that harm." The OPC has stressed that notifications should be written in plain language, avoid legal and technical jargon, and be conspicuous—distinct from marketing emails or general privacy updates.

## Form and manner of notification to individuals — direct and indirect

Section 4 of the Regulations requires that notification to individuals be direct—directly notifying each affected individual—unless direct notification is not feasible in the circumstances or the OPC determines (or the organization has reason to believe) that direct notification is likely to cause further harm to the individual. When direct notification is not required or feasible, section 5 permits indirect notification: the organization must publicize the breach "in a manner that the organization believes, on reasonable grounds, will bring the breach of security safeguards to the attention of the individuals," such as through prominent public notice (website banner, press release, social media) that reaches the affected population.

## Practical considerations — timing and supplementation

Though PIPEDA does not impose a fixed deadline for notification to individuals (unlike GDPR's 72-hour rule for authority notification), the "as soon as feasible" standard under subsection 10.1(6) has been interpreted by the OPC to mean as soon as reasonably possible. Organizations should not wait until every detail (exact number of individuals affected, full cause analysis) is finalized before notifying individuals—early notification enables affected individuals to take protective steps (credit monitoring, password resets, fraud alerts) while the risk of harm is still acute. Organizations may send an initial notice with the information required by section 3(a)–(f) based on available facts and follow up with supplemental information as the investigation progresses.

The OPC has signaled in enforcement guidance that organizations face greater scrutiny when notification is delayed beyond what the facts justify, particularly when the organization possessed sufficient information to notify individuals earlier but chose to wait for the conclusion of internal or third-party forensic investigations. In its 2019 breach record inspection report, the OPC noted that 20 percent of sampled sub-threshold breach records either met the RROSH threshold in the OPC's view or lacked sufficient information to verify the organization's determination—underscoring that organizations should err on the side of early notification when the RROSH assessment is close.

## Language and accessibility

While the Regulations do not specify the language of notification, the OPC has recommended in guidance that organizations notify individuals in the language used for communications with the individual—if an organization communicates with a customer primarily in French, the breach notification should also be in French. For organizations operating across Canada, this means bilingual notices may be required for customers who have interacted with the organization in both English and French, consistent with the general principles under PIPEDA Schedule 1, Principle 4.8 (Openness).

Source: Breach of Security Safeguards Regulations, SOR/2018-64, sections 2–5 Source: Personal Information Protection and Electronic Documents Act, sections 10.1(2), 10.1(3), 10.1(6) Source: Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (October 2018) Source: Office of the Privacy Commissioner of Canada, PIPEDA Breach Report Form

Beyond the obligations to report to the Office of the Privacy Commissioner of Canada (OPC) under subsection 10.1(2) and to notify affected individuals under subsection 10.1(3), PIPEDA imposes a separate third-party notification duty under section 10.2. When an organization has determined that a breach creates a real risk of significant harm (RROSH) and has notified affected individuals, it must also notify any other organization, government institution, or part of a government institution of the breach if the notifying organization believes that the third party may be able to reduce the risk of harm that could result from it or mitigate that harm—or if any prescribed conditions are satisfied.

The third-party notification requirement came into force on November 1, 2018, alongside the broader mandatory breach reporting regime under the Digital Privacy Act amendments to PIPEDA.

## Triggering condition — belief that the third party can reduce or mitigate harm

Subsection 10.2(1) sets out the trigger: an organization that has already notified individuals under subsection 10.1(3) (because the breach creates a RROSH) shall notify any other organization or government institution if the notifying organization believes that the third party "may be able to reduce the risk of harm that could result from it or mitigate that harm." The test is subjective belief, not certainty—the notifying organization need not prove that the third party will in fact take action, only that it reasonably believes the third party has the ability to reduce or mitigate harm.

The statutory language is permissive in identifying which third parties to notify but mandatory once the belief threshold is met. There is no discretion to withhold notification from a third party that the organization believes can reduce harm. The trigger is also conditional on having already notified individuals under subsection 10.1(3)—if the breach does not meet the RROSH threshold for individual notification, section 10.2 does not apply. However, organizations may still voluntarily notify third parties of sub-RROSH breaches as part of their security incident response, and doing so is consistent with PIPEDA's safeguards principle under Principle 4.7 of Schedule 1.

The statute references "if any of the prescribed conditions are satisfied" as an alternative trigger, but as of 2026 the Breach of Security Safeguards Regulations, SOR/2018-64, do not prescribe any additional conditions under section 10.2. The obligation therefore turns entirely on the notifying organization's belief that the third party can reduce or mitigate harm.

## Who qualifies as a "third party" under section 10.2

The broad statutory language—"any other organization, a government institution or a part of a government institution"—covers a wide range of potential third parties. The OPC's October 2018 guidance, What you need to know about mandatory reporting of breaches of security safeguards, and the OPC's 2016 and 2017 submissions to Innovation, Science and Economic Development Canada (ISED) on the draft Regulations identify several common scenarios:

• Law enforcement (municipal police, RCMP, provincial securities regulators) where the breach involves suspected criminal activity (cyberattack, fraud, identity theft) and law enforcement can investigate, warn other potential victims, or issue public alerts.

• Financial institutions and payment processors (banks, credit card issuers, payment networks such as Visa or Mastercard) where the breach involves payment card data, account credentials, or banking information and the financial institution can cancel and reissue cards, flag accounts for fraud monitoring, or reverse fraudulent transactions.

• Credit bureaus (Equifax, TransUnion) where the breach involves social insurance numbers, date of birth, or other information used for identity verification and the credit bureau can place fraud alerts or credit freezes on affected individuals' files.

• Service providers, cloud vendors, and data processors where the breach occurred at or through a third-party processor's systems and the processor may be able to contain the breach, identify the root cause, or notify other clients of the processor who may be similarly exposed. The OPC has clarified that when a breach occurs at a processor, the principal organization (the organization that engaged the processor and retains control of the personal information under PIPEDA) is responsible for breach reporting to the OPC and notification to individuals, but may also need to notify the processor itself under section 10.2 if the processor can reduce harm—or conversely, the processor may notify the principal organization under section 10.2 if the processor discovers the breach first.

• Other privacy enforcement authorities (provincial privacy commissioners in Alberta, British Columbia, and Quebec; federal, provincial, or foreign data protection authorities) where affected individuals reside in multiple jurisdictions and the other authority has enforcement or guidance powers that may reduce harm. The OPC's 2016 and 2017 submissions to ISED expressly recommended that breach reports to the OPC include "a list or description of third party organizations that were notified of the breach, pursuant to s. 10.2(1) of PIPEDA, as well as Privacy Enforcement Authorities from other jurisdictions." While notification to foreign supervisory authorities is not legally required by section 10.2 unless the organization believes they can reduce harm, it is consistent with coordinated cross-border breach response (for example, notifying the U.S. Federal Trade Commission or a state attorney general if U.S. residents are affected, or notifying the EU supervisory authority under GDPR Article 33 if EU data subjects are affected and GDPR applies).

• Government institutions that have issued identity credentials or licenses that were compromised in the breach (provincial ministries that issue driver's licenses, Service Canada for social insurance numbers, passport offices) and can flag the credentials as compromised, issue replacements, or take steps to prevent fraudulent use.

The key analytical question is capacity to reduce or mitigate harm. A third party does not need to be the source of the breach or have a pre-existing contractual relationship with the notifying organization; the test is purely functional—can the third party take action to protect affected individuals?

## Timeline — "as soon as feasible"

Subsection 10.2(2) requires that the notification "shall be given as soon as feasible after the organization determines that the breach has occurred." This is the same timeline that applies to reporting to the OPC under subsection 10.1(2) and notifying individuals under subsection 10.1(6). The OPC has clarified that "as soon as feasible" means as soon as reasonably possible in the circumstances—organizations should not delay third-party notification while waiting for a complete investigation, but should notify promptly based on available information and supplement as facts develop.

In practice, third-party notification often occurs in parallel with individual notification and the report to the OPC, particularly when the third party is a law enforcement agency or financial institution that needs to act urgently to prevent fraud. The OPC expects organizations to prioritize third-party notification when the third party's ability to reduce harm is time-sensitive (for example, notifying a payment processor within hours of discovering a payment-card breach so the processor can cancel compromised cards before fraudulent charges occur).

## Permitted disclosure of personal information to the third party — subsections 10.2(3) and (4)

Section 10.2 creates a statutory exception to PIPEDA's consent and purpose-limitation rules to facilitate third-party notification. Subsection 10.2(3) permits an organization to disclose personal information without the knowledge or consent of the individual if:

• (a) the disclosure is made to the other organization, government institution, or part of a government institution that was notified of the breach under subsection (1); and

• (b) the disclosure is made solely for the purposes of reducing the risk of harm to the individual that could result from the breach or mitigating that harm.

This means the notifying organization may share affected individuals' personal information (names, account numbers, compromised credentials, the nature and extent of the exposure) with the third party to enable the third party to take protective action—for example, providing a list of compromised credit card numbers to the issuing bank so the bank can cancel and reissue cards, or providing social insurance numbers to a credit bureau so the bureau can place fraud alerts.

Subsection 10.2(4) further provides that, despite Principle 4.5 of Schedule 1 (which requires personal information to be used only for the purposes for which it was collected, or compatible purposes), an organization may disclose personal information for purposes other than those for which it was collected in the circumstance set out in subsection 10.2(3). This clarifies that breach-response disclosure to third parties is not a breach of PIPEDA's use-limitation principle, even when the original purpose of collection (e.g., processing a transaction, providing a service) did not contemplate sharing the information with law enforcement, payment processors, or credit bureaus.

The disclosure authorization is narrow: the personal information may be disclosed only to the third party notified under subsection 10.2(1), and only for reducing or mitigating harm. The third party that receives the information becomes subject to PIPEDA's safeguards and retention-limitation principles and must not use the information for unrelated purposes (such as marketing or secondary data analytics).

## No prescribed content requirements for third-party notification

Unlike the report to the OPC (section 2 of the Breach of Security Safeguards Regulations) and the notification to individuals (section 3 of the Regulations), section 10.2 does not prescribe specific content requirements for third-party notifications. The notification must be sufficient to enable the third party to reduce or mitigate harm—practically, this means describing the nature and scope of the breach, the types of personal information involved, the number of individuals affected (or an estimate), and the specific action the notifying organization believes the third party can take. The OPC's breach report form (available on priv.gc.ca) includes an optional field for organizations to list third parties notified under section 10.2, and the OPC's guidance recommends that organizations document third-party notifications in their breach records under section 10.3(1) to demonstrate compliance.

## Relationship to voluntary coordination with other privacy authorities

While section 10.2 does not require organizations to notify privacy enforcement authorities in other jurisdictions unless the organization believes those authorities can reduce harm to affected individuals, the OPC has encouraged coordinated notification when breaches affect individuals subject to multiple privacy regimes. In its 2016 and 2017 submissions to ISED, the OPC recommended that breach reports to the OPC include "a list or description of … Privacy Enforcement Authorities from other jurisdictions" notified of the breach. Organizations operating under Alberta's Personal Information Protection Act (Alberta PIPA), British Columbia's Personal Information Protection Act (BC PIPA), or Quebec's Act respecting the protection of personal information in the private sector (and, as of September 2023, Quebec's modernized Law 25) should assess whether those provincial regimes impose parallel breach notification obligations and whether notification to the Alberta, BC, or Quebec privacy commissioner is required or advisable. Similarly, organizations subject to GDPR (Regulation (EU) 2016/679) or other non-Canadian data protection laws should assess whether those regimes impose separate breach notification obligations to supervisory authorities or data subjects.

The OPC does not have formal adequacy or reciprocal-enforcement arrangements with most foreign data protection authorities, but informal coordination is common practice in cross-border breach investigations involving multinational organizations or cloud service providers.

Source: Personal Information Protection and Electronic Documents Act, section 10.2 Source: Breach of Security Safeguards Regulations, SOR/2018-64 Source: Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (October 2018) Source: Office of the Privacy Commissioner of Canada, Discussion document on data breach notification and reporting regulations (June 2016) Source: Office of the Privacy Commissioner of Canada, Submission: Breach of Security Safeguards Regulations (October 2, 2017)

Under subsection 10.1(3) of PIPEDA, when an organization determines that a breach creates a real risk of significant harm (RROSH), it shall notify each affected individual unless "otherwise prohibited by law." The default method is direct notification—individually notifying each affected person by mail, email, telephone, or other direct means. However, section 5 of the Breach of Security Safeguards Regulations, SOR/2018-64, permits indirect notification in two limited circumstances: when direct notification is not feasible in the circumstances, or when the Office of the Privacy Commissioner of Canada (OPC) determines, or the organization has reason to believe, that direct notification is likely to cause further harm to the individual.

## Statutory framework — subsection 10.1(5) and section 5 of the Regulations

Subsection 10.1(5) of PIPEDA provides that notification to an individual "may be given indirectly if the Commissioner has determined that direct notification is likely to cause further harm to the individual or if it is not feasible in the circumstances to give it directly." Section 5(1) of the Regulations cross-references this provision and states: "For the purposes of subsection 10.1(5) of the Act, the notification referred to in subsection 10.1(3) of the Act may be given to an individual indirectly if (a) it is not feasible in the circumstances to give it directly; or (b) the Commissioner has determined that giving it directly is likely to cause further harm to the individual or the organization has reason to believe that giving it directly is likely to cause further harm to the individual."

Section 5(2) of the Regulations requires that indirect notification "must be given by public communication or similar measure that could reasonably be expected to reach the affected individuals."

The statutory structure thus creates two distinct grounds for indirect notification:

1. Feasibility exception — direct notification is not feasible in the circumstances (section 5(1)(a)); and
2. Further-harm exception — the OPC has determined, or the organization reasonably believes, that direct notification would cause further harm to the individual (section 5(1)(b)).

## The feasibility exception — when is direct notification "not feasible"?

The Regulations do not define "not feasible," and the OPC's October 2018 guidance, What you need to know about mandatory reporting of breaches of security safeguards, offers only general direction: indirect notification is permitted "if the organization does not have the contact information for the individuals or cannot reasonably obtain it" or "if the cost of direct notification would be excessive in relation to the resources of the organization." The guidance emphasizes that the feasibility analysis is fact-specific and that organizations bear the burden of demonstrating why direct notification was not feasible.

In practice, the OPC has identified several recurring scenarios where indirect notification may be justified on feasibility grounds:

• Lack of current contact information — The organization's records do not include mailing addresses, email addresses, or telephone numbers for affected individuals, or the contact information on file is stale or incomplete (e.g., customers who transacted with the organization years ago and have since moved, closed email accounts, or changed phone numbers). The OPC expects organizations to make reasonable efforts to locate updated contact information (e.g., checking publicly available databases, contacting intermediaries such as insurance brokers or agents who may have current details), but does not require organizations to hire skip-tracing services or conduct exhaustive searches if the breach population is large and the likelihood of locating individuals is low.

• Excessive cost relative to organizational resources — The organization is a small or medium-sized enterprise with limited financial resources, and the cost of printing, postage, call-center staffing, or third-party notification vendors would impose a disproportionate burden relative to the organization's annual revenue or operating budget. The OPC has not published a numeric threshold (e.g., cost exceeding X percent of revenue), and organizations invoking this ground should document the cost estimate and the financial constraint in their breach records under section 10.3(1).

• Large-scale breach with unknown or shifting population — The breach affects a very large number of individuals (tens of thousands or millions), and the organization cannot ascertain the full list of affected individuals because the compromised database lacked unique identifiers, contained duplicate or incomplete records, or spanned multiple legacy systems that cannot be reconciled. The OPC has emphasized that organizations cannot use scale alone to justify indirect notification—if the organization possesses valid contact information for a subset of the affected population, it must provide direct notification to that subset and use indirect notification only for individuals whose contact details are genuinely unavailable.

The OPC's 2019 breach record inspection report, 2019 Breach record inspections, found that approximately 15 percent of sampled breach records where organizations used indirect notification did not contain sufficient detail for the OPC to verify that direct notification was genuinely infeasible. The OPC expects organizations to document the specific reason why direct notification was not feasible (not merely "cost" or "scale") and to retain evidence (e.g., failed delivery logs, database search results showing no contact information, cost estimates from notification vendors) in the breach record.

## The further-harm exception — when would direct notification cause harm?

The further-harm ground under section 5(1)(b) applies when notifying an individual directly would itself create or aggravate harm to that individual. The statutory language distinguishes between two scenarios:

• The OPC has determined that direct notification is likely to cause further harm; or
• The organization has reason to believe that direct notification is likely to cause further harm.

In the first scenario, the organization may seek a determination from the OPC by describing the circumstances in the breach report and requesting guidance on whether direct notification should be withheld. The OPC does not issue formal exemption orders, but may provide an informal opinion (typically by telephone or email) indicating that indirect notification is appropriate. Organizations that rely on an OPC determination should document the date, substance, and OPC contact in the breach record.

In the second scenario, the organization may unilaterally decide to use indirect notification if it has reason to believe direct notification would cause further harm, without first obtaining OPC approval. This is a lower threshold than "the OPC has determined," and it permits organizations to act quickly when immediate direct notification would be harmful. However, the organization must be prepared to justify its belief to the OPC if the OPC requests access to the breach record under subsection 10.3(2).

The OPC's October 2018 guidance offers a single example of the further-harm exception: "an organization may have reason to believe that notifying a victim of intimate partner violence or elder abuse directly (for example, by mail to a shared residence) could alert the abuser and put the victim at further risk." The OPC has not published additional examples, but the logic extends to other contexts where direct notification would create risk to the individual (such as stalking or harassment scenarios involving domestic violence shelters, sexual assault counseling services, or witness protection programs where notifying individuals at their address of record could reveal their whereabouts to an abuser or perpetrator).

Organizations may not invoke the further-harm exception to avoid reputational harm to the organization or to prevent negative publicity. The statutory language requires harm to the individual, not to the organization. Similarly, organizations may not use the further-harm exception to avoid notifying individuals of breaches that are embarrassing or sensitive to the individual (e.g., breaches of dating-app data, health information, financial distress records) unless there is a specific, articulable risk that direct notification would cause additional harm beyond the harm already caused by the breach itself.

## Form and manner of indirect notification — section 5(2) public communication requirement

When indirect notification is justified, section 5(2) of the Regulations requires that the notification "must be given by public communication or similar measure that could reasonably be expected to reach the affected individuals." The OPC's guidance identifies several acceptable methods:

• Prominent website banner or homepage notice — A conspicuous, plain-language notice posted on the organization's homepage (not buried in a privacy policy or FAQ) that remains visible for a reasonable period (at least 30 days, or longer if the breach is ongoing or evolving). The notice should be distinct from marketing content or general announcements.

• Press release or media advisory — Issuing a press release to national, regional, or local news outlets and notifying consumer reporters, privacy beat journalists, and television/radio stations that cover data security issues. The OPC expects organizations to target media likely to reach the affected demographic (e.g., French-language media for Quebec residents, community newspapers for geographically concentrated populations).

• Social media posts — Publishing breach notifications on the organization's official social media accounts (Twitter, Facebook, LinkedIn, Instagram) and, where appropriate, purchasing promoted or sponsored posts to ensure the notice reaches individuals who do not actively follow the organization's accounts.

• Industry or trade association notices — For breaches affecting members of a professional association, trade group, or industry body, requesting that the association distribute the notice to its membership via newsletter, member portal, or email list.

The OPC has emphasized that indirect notification must be as effective as reasonably possible in reaching the affected population. Organizations should use multiple channels when feasible (e.g., website notice + press release + social media) and should tailor the notice to the known or likely language, geography, and media consumption habits of affected individuals. Indirect notification that consists solely of a brief, technical blog post on the organization's website—with no media outreach, no social media amplification, and no effort to reach individuals who do not regularly visit the website—is unlikely to satisfy the "reasonably be expected to reach" standard.

## Content requirements for indirect notification — section 3 elements still apply

Section 3 of the Regulations prescribes what a notification to an affected individual must contain, whether the notification is direct or indirect. Indirect notifications must include:

• (a) a description of the circumstances of the breach;
• (b) the date or time period when the breach occurred;
• (c) a description of the personal information involved;
• (d) a description of the steps the organization has taken to reduce the risk of harm;
• (e) a description of the steps that affected individuals could take to reduce or mitigate harm; and
• (f) a toll-free number or email address (or other contact information) that individuals can use to obtain further information.

The OPC expects indirect notifications to use plain language, avoid legal or technical jargon, and be conspicuous—distinct from marketing emails, general privacy updates, or routine operational announcements. For large-scale breaches where indirect notification is combined with a dedicated call center or web portal, the organization should ensure that call-center staff are trained to answer breach-related questions, verify caller identity (to prevent social engineering), and provide individualized guidance on protective steps.

## Relationship to direct notification — hybrid approach when contact information is partial

Organizations are not required to choose between all-direct or all-indirect notification. When an organization possesses valid contact information for some but not all affected individuals, the OPC expects the organization to provide direct notification to the individuals for whom contact information is available and indirect notification to the remainder. For example, if a breach affects 10,000 individuals and the organization has current email addresses for 7,000 of them, the organization should send direct email notifications to the 7,000 and use indirect notification (website notice, press release, social media) to reach the 3,000 for whom no contact information is available.

The OPC's 2019 breach record inspection report found that organizations sometimes used indirect notification as the sole method even when they possessed partial contact information, citing cost or administrative convenience. The OPC has signaled that this practice is inconsistent with the statutory requirement to notify individuals directly unless it is not feasible to do so—if direct notification is feasible for a subset, it must be used for that subset.

## Record-keeping and OPC oversight

Organizations that use indirect notification must document the rationale in the breach record maintained under section 10.3(1). The OPC may request access to the record under subsection 10.3(2) and may investigate whether the organization's decision to use indirect notification was justified. In its 2019 inspection report, the OPC noted that 15 percent of sampled records where indirect notification was used lacked sufficient detail to verify the organization's determination, and recommended that organizations include:

• The specific ground for indirect notification (feasibility or further harm);
• Evidence supporting the determination (e.g., cost estimate, database query showing no contact information, clinical assessment of harm risk);
• A description of the indirect notification method(s) used (website notice, press release, social media, paid advertising); and
• The date(s) when the indirect notification was published or disseminated.

Organizations that cannot substantiate the decision to use indirect notification may face OPC enforcement action, including a recommendation that the organization implement policies requiring OPC consultation before using indirect notification in future breaches, or a referral to the Attorney General of Canada for possible prosecution under PIPEDA's offence provisions if the OPC determines the organization knowingly contravened the notification requirement.

Source: Personal Information Protection and Electronic Documents Act, subsection 10.1(5) Source: Breach of Security Safeguards Regulations, SOR/2018-64, section 5 Source: Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (October 2018) Source: Office of the Privacy Commissioner of Canada, 2019 Breach record inspections

PIPEDA imposes a universal record-keeping obligation that extends to every breach of security safeguards involving personal information under an organization's control, regardless of whether the breach met the "real risk of significant harm" (RROSH) threshold for reporting to the Office of the Privacy Commissioner of Canada (OPC) or notifying individuals. This requirement came into force on November 1, 2018, alongside the mandatory breach reporting regime enacted by the Digital Privacy Act amendments to PIPEDA.

## Statutory framework — section 10.3 and the Breach of Security Safeguards Regulations

Section 10.3(1) of PIPEDA provides: "An organization shall, in accordance with any prescribed requirements, keep and maintain a record of every breach of security safeguards involving personal information under its control." The statutory language is absolute—"every breach"—and does not distinguish between reportable breaches (those meeting the RROSH threshold under subsection 10.1(1)) and sub-threshold breaches that were investigated but determined not to require reporting or notification.

The Breach of Security Safeguards Regulations, SOR/2018-64, prescribe two key requirements for record-keeping:

Section 6(1) sets the retention period: "For the purposes of subsection 10.3(1) of the Act, an organization must maintain a record of every breach of security safeguards for 24 months after the day on which the organization determines that the breach has occurred."

Section 6(2) sets the content standard: "The record referred to in subsection 10.3(1) of the Act must contain any information that enables the Commissioner to verify compliance with subsections 10.1(1) and (3) of the Act."

The 24-month retention period starts when the organization determines that the breach has occurred—not when the breach was discovered, not when the investigation concluded, and not when the report to the OPC was filed (if applicable). This determination point is typically the date when the organization's privacy or security team concludes that an incident meets PIPEDA's definition of a "breach of security safeguards" (the loss of, unauthorized access to, or unauthorized disclosure of personal information resulting from a breach of the organization's security safeguards or a failure to establish those safeguards).

## Why 24 months — legislative rationale and the OPC's dissenting view

The 24-month retention period was adopted by the federal government over the OPC's objection. In the OPC's October 2017 submission to Innovation, Science and Economic Development Canada (ISED) on the draft Regulations, the OPC recommended a five-year retention period, arguing that "two years is not a sufficient time frame to develop a wholesome assessment, as five years will provide a clearer picture of how the various aspects of the breach are and have been addressed by an organization" and that a longer period "will allow the OPC and organizations to have a better understanding of risks—this would help improve the intelligence and analytical capabilities required for the OPC to identify any systemic issues and more effectively guide organizations develop better security practices."

The government's Regulatory Impact Analysis Statement (RIAS) accompanying the final Regulations justified the 24-month period on the grounds that it "aligns with limitations on initiating civil litigation" under general commercial law. The RIAS did not specify which limitation period was being referenced, but the rationale appears to have been administrative convenience and industry feedback rather than privacy-specific policy.

Organizations should note that the 24-month period under section 6(1) is a minimum—other legal obligations may require longer retention. For example, organizations subject to securities law (such as reporting issuers under National Instrument 52-109 Certification of Disclosure in Issuers' Annual and Interim Filings) may need to retain breach records longer to support management certifications of internal controls over financial reporting. Organizations in regulated sectors (banks, insurance companies, telecommunications carriers) may have sector-specific record-retention requirements imposed by their primary regulator (OSFI, provincial insurance regulators, CRTC) that apply to security incident documentation. And organizations operating under Quebec's Law 25 (the modernized Act respecting the protection of personal information in the private sector, effective September 2023 for the breach notification provisions) face a five-year retention requirement under section 3.6 of Quebec's Regulation respecting the protection of personal information, which supersedes PIPEDA's 24-month rule for Quebec residents' personal information when an organization is subject to both regimes.

## What must be in the breach record — section 6(2) content standard and OPC expectations

Section 6(2) of the Regulations requires that the record "contain any information that enables the Commissioner to verify compliance with subsections 10.1(1) and (3) of the Act"—that is, verify whether the organization properly assessed the RROSH threshold and, if the threshold was met, whether the organization reported to the OPC and notified individuals. This is a functional standard, not a prescriptive checklist, but the OPC's October 2018 guidance, What you need to know about mandatory reporting of breaches of security safeguards, and the OPC's 2019 breach record inspection report identify several core elements:

For all breaches (reportable and sub-threshold)

• Date or time period of the breach — the date the breach occurred, or if unknown, the approximate time period. This is distinct from the date the organization discovered the breach or completed its investigation.

• Circumstances and cause — a description of how the breach occurred (cyberattack, employee error, lost device, unauthorized access by employee, misdirected email, theft) and, if known, the root cause (unpatched software vulnerability, weak password, failure to encrypt, inadequate access controls).

• Personal information involved — the types of personal information compromised (names, dates of birth, social insurance numbers, payment card data, health information, financial records, credentials) and the sensitivity of that information, which is one of the two mandatory factors under subsection 10.1(8) for assessing RROSH.

• Number of affected individuals — the number of individuals whose personal information was involved, or an estimate if the exact number cannot be determined.

• RROSH assessment — the organization's analysis of whether the breach created a real risk of significant harm under subsections 10.1(1) and (3), including the reasoning and the two mandatory factors: (a) the sensitivity of the personal information involved, and (b) the probability that the personal information has been, is being, or will be misused. The OPC expects this assessment to be documented in writing—a bare conclusion ("no RROSH") without supporting analysis does not satisfy section 6(2).

For sub-threshold breaches (breaches that did not meet RROSH)

• Explanation of why the breach was not reported or notified — a brief but substantive explanation of why the organization concluded the breach did not create a real risk of significant harm. The OPC's 2019 breach record inspection report found that 20 percent of sampled sub-threshold breach records either did not contain sufficient detail for the OPC to verify the organization's RROSH determination or, in the OPC's view, actually did meet the RROSH threshold and should have been reported. The OPC has signaled that records stating only "low risk" or "no RROSH" without describing the analysis are inadequate.

For reportable breaches (breaches that met the RROSH threshold)

• Steps taken to reduce harm — the remediation and containment measures the organization implemented (system shutdown, password resets, credit monitoring offered, forensic investigation, enhanced monitoring, patches deployed, access controls tightened).

• Notification to individuals — a description of when and how individuals were notified (direct notification by mail, email, telephone, or indirect notification by public communication), the content of the notification, and whether the notification complied with section 3 of the Regulations.

• Report to the OPC — the date the breach was reported to the OPC, the report reference number (if assigned), and whether any supplemental information was submitted under section 2(2) of the Regulations.

• Third-party notifications under section 10.2 — if the organization notified other organizations, government institutions, or law enforcement under section 10.2 because the organization believed they could reduce or mitigate harm, the record should identify the third parties notified, the date, and the rationale.

The OPC has recommended that organizations use the PIPEDA Breach Report Form (available on priv.gc.ca) as a template for their internal breach records, even for sub-threshold breaches, because the form tracks the core elements and ensures consistency. Organizations are not legally required to use the OPC's form for record-keeping (as opposed to reporting, where the form is the prescribed manner under section 2 of the Regulations), but doing so simplifies compliance and creates a defensible record if the OPC requests access under subsection 10.3(2).

## OPC inspection powers — subsection 10.3(2) proactive access

Subsection 10.3(2) of PIPEDA provides: "An organization shall, on request, provide the Commissioner with access to, or a copy of, a record." This language is unqualified—the OPC may request breach records at any time, without needing to demonstrate reasonable grounds to investigate or initiate a complaint under section 11. The OPC's power to inspect breach records is proactive and supervisory, not complaint-driven.

The OPC has exercised this power in targeted inspection campaigns. In 2019, the OPC conducted its first breach record inspection, examining breach records from seven telecommunications companies to assess compliance with the record-keeping obligation and to gather intelligence on how organizations were interpreting and applying the RROSH standard. The OPC's September 2020 inspection report, 2019 Breach record inspections, summarized the findings and identified several compliance gaps:

• Insufficient RROSH documentation — 20 percent of sampled sub-threshold breach records lacked sufficient detail for the OPC to verify the organization's determination that the breach did not meet the RROSH threshold, or the OPC concluded the breach actually did meet the threshold based on the information in the record.

• Underreporting of certain breach types — The OPC noted a surprisingly low incidence of loss (1 percent), theft (4 percent), and unauthorized employee access or snooping (3 percent) in the sampled breach records, compared to the OPC's experience with breach reports filed under subsection 10.1(1), where loss (11 percent), theft (8 percent), and employee misuse (7 percent) are more common. The OPC suggested this discrepancy may indicate reporting gaps—organizations may not be identifying or recording these breach types, or may be incorrectly concluding they do not meet the RROSH threshold.

• Inconsistent record formats — Organizations used widely varying formats, depth of analysis, and terminology for breach records, making it difficult for the OPC to verify compliance or aggregate data for sectoral analysis. The OPC recommended standardizing on the PIPEDA Breach Report Form structure.

The OPC has signaled that breach record inspections will be an ongoing compliance tool, particularly in sectors with high breach volumes or sectors where the OPC has received complaints or media reports suggesting underreporting. Organizations should assume their breach records may be inspected and should document the RROSH assessment contemporaneously and in writing.

## Quasi-criminal offence for knowingly contravening record-keeping requirements

Subsection 10.1(1) of PIPEDA creates a quasi-criminal offence for knowingly contravening the reporting, notification, or record-keeping requirements in Division 1.1 (sections 10.1–10.3). The offence provisions apply to record-keeping as well as reporting and notification. Knowingly failing to maintain breach records, knowingly destroying breach records before the 24-month retention period expires, or knowingly refusing the OPC's request for access under subsection 10.3(2) can result in referral by the OPC to the Attorney General of Canada and prosecution by the Director of Public Prosecutions, with a maximum fine of $100,000 per violation.

This criminal-penalty structure is rarely invoked in practice—the OPC does not have the power to issue administrative monetary penalties and must refer suspected offences to the Attorney General, and the threshold is knowingly (intentional or reckless disregard, not mere negligence or administrative oversight). However, the existence of the offence provision underscores the mandatory nature of the record-keeping obligation and the seriousness with which Parliament viewed the integrity of breach records as an oversight and enforcement tool.

## Practical record-keeping recommendations — documentation, centralization, and periodic review

The OPC's guidance and enforcement practice suggest several best practices:

Document the RROSH assessment in writing at the time of the breach investigation. A post-hoc reconstruction of the organization's reasoning months or years later, written in response to an OPC inspection request, is less credible and may not satisfy section 6(2).

Centralize breach records in a single system or repository (dedicated breach-management software, secure internal wiki, shared drive with access controls) so that the organization can produce all breach records promptly in response to an OPC request under subsection 10.3(2). The OPC's 2019 inspection report noted that organizations with decentralized or ad hoc record-keeping struggled to produce complete records and often could not confirm they had captured every breach.

Retain records for longer than 24 months if the organization has other legal obligations or if the breach involved litigation, regulatory investigation, or material financial impact. The 24-month period is a floor, not a ceiling. Organizations facing civil claims, class actions, or securities disclosure obligations arising from a breach should retain the breach record until the claim is resolved and any appeal period has expired. Organizations operating in Quebec must retain breach records involving Quebec residents' personal information for five years under Quebec's Regulation respecting the protection of personal information, section 3.6.

Conduct periodic internal audits of breach record completeness and quality, particularly if the organization has a high volume of breaches or a decentralized incident-response structure (multiple business units, franchisees, dealers, or third-party processors that may discover breaches independently). The OPC has recommended annual or semi-annual internal reviews to ensure that all breaches are being captured, recorded, and analyzed consistently.

Train incident-response personnel on the record-keeping obligation and the content requirements under section 6(2). The OPC's 2019 inspection report found that organizations with formal breach-response policies and trained privacy teams produced higher-quality breach records than organizations where breach response was informal or ad hoc.

Source: Personal Information Protection and Electronic Documents Act, section 10.3 Source: Breach of Security Safeguards Regulations, SOR/2018-64, section 6 Source: Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (October 2018) Source: Office of the Privacy Commissioner of Canada, 2019 Breach record inspections (September 2020) Source: Office of the Privacy Commissioner of Canada, Submission: Breach of Security Safeguards Regulations (October 2, 2017)