PIPEDA Breach Notification and Record-Keeping: What to Get Right

The part of breach response most teams skip

When a breach happens, most organizations pour their energy into containment and recovery — and rightly so. But under Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), two obligations are just as important and far easier to get wrong: notifying the right parties at the right time, and keeping a record of the incident. These are not optional best practices. They have been legal requirements since the mandatory breach provisions came into force on 1 November 2018.

The rules are simple to state and genuinely tricky to apply under pressure. This guide walks through what PIPEDA actually requires, the judgment call at the centre of it, and the record-keeping habit that protects you long after the incident is closed.

When PIPEDA's breach rules apply to you

PIPEDA governs how private-sector organizations handle personal information in the course of commercial activity. If you collect, use, or disclose personal data about customers, users, or employees as part of doing business, the breach obligations almost certainly reach you — even if your team is small and even if the affected data sits with a third-party processor.

A few points that trip people up:

• The obligation attaches to the organization that controls the personal information, not necessarily the one whose systems were breached. If your vendor is compromised but the data is yours, the reporting duty is generally yours.
• Provincial private-sector laws (in British Columbia, Alberta, and Quebec) and health-specific laws like PHIPA can apply instead of, or alongside, PIPEDA. Quebec's Law 25 has its own breach-notification regime with comparable triggers.
• "Personal information" is broad — names tied to email addresses, account credentials, location data, and inferred attributes all count. It is not limited to financial or health data.

The test that decides everything: real risk of significant harm

PIPEDA does not require you to report every breach to the regulator and to individuals. It requires you to do so when a breach of security safeguards creates a "real risk of significant harm" (RROSH) to an individual. That phrase is the hinge of the entire framework, so it is worth slowing down on.

"Significant harm" is defined expansively in the Act. It includes bodily harm, humiliation, damage to reputation or relationships, loss of employment or of business or professional opportunities, financial loss, identity theft, negative effects on a credit record, and damage to or loss of property.

"Real risk" turns on a weighing of factors. The two the Act names explicitly are the sensitivity of the personal information involved and the probability that the information has been, is being, or will be misused.

• Sensitivity: health information, government identifiers (like the SIN), and financial account details sit at the high-sensitivity end. But context matters — a name plus email can become sensitive when it reveals membership in a vulnerable group.
• Probability of misuse: a recovered laptop with forensic evidence it was never accessed is very different from credentials exfiltrated and posted for sale. Consider who obtained the data, whether it was encrypted, how long it was exposed, and any evidence of malicious intent.
• Document the analysis either way. Deciding a breach does not meet RROSH is a defensible position only if you can show your reasoning.

Who you notify, and when

Once you conclude a breach poses a real risk of significant harm, three notification duties can be triggered. PIPEDA's timing standard is firm: notification must happen "as soon as feasible" after you determine the breach has occurred. There is no fixed day count, but "as soon as feasible" does not mean "once the dust fully settles."

• The Office of the Privacy Commissioner of Canada (OPC): you must report the breach to the federal regulator. The OPC provides a breach report form; the report should describe the circumstances, the personal information involved, the number of people affected (or an estimate), the steps you have taken, and your assessment of the risk.
• Affected individuals: notification must be direct (by phone, mail, email, or in person) unless direct contact is not feasible — for example, if it would cause further harm or you lack current contact information — in which case indirect notification, such as a public notice, is permitted. The notice must contain enough information for the person to understand the significance of the breach and to take steps to reduce their risk of harm.
• Other organizations or government institutions: if notifying a third party — such as a payment processor, a credit bureau, or law enforcement — could reduce or mitigate the risk of harm, you must notify them too.

The record-keeping requirement everyone forgets

Here is the obligation that quietly catches organizations off guard: PIPEDA requires you to keep a record of every breach of security safeguards involving personal information — not just the ones you decided were reportable. The sub-threshold incidents count too.

You must maintain these records for at least 24 months after the day you determine the breach occurred, and you must provide them to the OPC on request. In practice, a regulator reviewing one reported breach can ask to see the full log, and a thin or missing log undermines confidence in your whole program.

A useful breach record captures enough for someone to reconstruct your decision-making later:

• What happened, when it was discovered, and when you determined it had occurred
• The personal information and approximate number of individuals involved
• Your real-risk-of-significant-harm assessment and the reasoning behind it — including the not-reportable conclusions
• What you notified, whom, and when (or why notification was not required)
• Containment and remediation steps, and any changes made to prevent recurrence

Building this into your incident response, not bolting it on

The organizations that handle PIPEDA breaches well are not the ones with the fastest lawyers — they are the ones who decided in advance who runs the RROSH assessment, where the breach log lives, and what a notification looks like. When those decisions are made calmly ahead of time, the actual incident is mostly execution.

Practical moves that pay off:

• Add a standing RROSH assessment template to your incident response plan, so the analysis is consistent and documented every time.
• Keep the breach log in one place with a defined owner, and make logging part of closing out any security incident — not a separate compliance chore.
• Map your data flows and vendors now, so that when a processor is breached you already know whose data is affected and who must report.
• Pre-draft notification templates for the OPC report and individual notices; editing under pressure beats writing from scratch.

Getting it right without overthinking it

PIPEDA's breach regime rewards organizations that are honest, prompt, and well-documented. The substantive judgment — does this breach create a real risk of significant harm — is yours to make, but it has to be made deliberately and written down. Notify as soon as feasible when the threshold is met, and keep a record of everything, including the incidents you decided not to report.

If you are unsure whether the rules apply to you, or you are working through a live incident, the moment to get clarity is before the OPC asks. A short, defensible process beats an improvised scramble every time.

Related reading

• Does PIPEDA apply to my business
• What to do after a data breach