PIPEDA Breach Reporting: The 72-Hour Myth and What Actually Triggers a Report

There's a persistent myth in Canadian privacy circles that PIPEDA gives you 72 hours to report a breach. It doesn't. That's GDPR. Conflating the two leads businesses to either panic on the wrong timeline or, worse, relax on the wrong one.

PIPEDA's actual standard is both more forgiving and more demanding. Let's get it right, because the moment after you discover a breach is the worst possible time to be reading the law for the first time.

The trigger isn't a clock — it's a test

Under PIPEDA, you must report a breach of security safeguards to the Office of the Privacy Commissioner of Canada (OPC) and notify affected individuals when the breach creates a "real risk of significant harm" — known in the trade as RROSH.

That's the whole hinge. No real risk of significant harm, no mandatory report. A real risk of significant harm, and you must notify "as soon as feasible." Not within 72 hours. As soon as feasible — which, for a serious breach, can mean faster than 72 hours.

What counts as "significant harm"

PIPEDA is specific here, and it's broader than people expect. Significant harm includes:

• 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
• Damage to or loss of property

If a breach could plausibly lead to any of those, you're in significant-harm territory.

What makes the risk "real"

Significant harm being *possible* isn't enough — the risk has to be *real*. PIPEDA tells you to weigh two factors:

The sensitivity of the information. A leaked SIN, banking details, or health record is inherently sensitive. A leaked first name on its own usually isn't. But sensitivity is contextual — a list of names on its own is benign; the same names on a list of clients of an addiction clinic is extremely sensitive.

The probability the information will be misused. Was the data encrypted? Was it recovered? Who got access — a malicious actor, or an employee who clicked the wrong button and reported it immediately? Was it a targeted attack or a random exposure? The likelihood of actual misuse moves the needle as much as the data itself.

You assess both together. Highly sensitive data with a high probability of misuse is an easy call. The hard cases live in the middle, and that's exactly where having a documented, repeatable assessment matters.

The register everyone forgets

Here's the requirement that trips up even careful businesses: PIPEDA requires you to keep a record of every breach of security safeguards — not just the ones you report. The reportable ones and the ones that didn't meet the RROSH threshold, all of it.

The OPC can ask to see that register. An organization that says "we've never had a breach worth recording" is, to a regulator, an organization that isn't looking. Maintaining the register is also how you spot patterns — three "minor" incidents in the same system is a signal, not a coincidence.

What good breach response actually looks like

When a breach hits, the sequence is roughly: contain it, assess the RROSH, and — if it crosses the threshold — notify the OPC and affected individuals as soon as feasible, document everything, and log it in the register either way.

The organizations that handle this well aren't the ones with the most lawyers. They're the ones who decided, on a calm Tuesday, exactly how they'd run that sequence — who assesses risk, who drafts the notification, who signs off — so that on the bad day, they're executing a plan instead of inventing one.

Where Valdra fits

This is precisely the workflow Valdra automates. You open an incident, the platform walks you through a structured RROSH assessment (sensitivity × probability), and if it crosses the threshold, it generates the OPC report and the individual notification letters — and logs everything to your breach register automatically, including the incidents that didn't need reporting.

Discovery-to-OPC-submission that takes most businesses one to two weeks can happen in hours, with the documentation trail a regulator expects already built.

If your current breach plan is "we'd figure it out," see what a real one looks like. Start with the free assessment and build the response before you need it. The worst time to design your breach process is in the middle of a breach.