There is a decent chance the number 72 appears somewhere in your incident response plan, in an answer you gave on a customer security questionnaire, or in a policy someone signed off last year and nobody has read since. If the law you answer to is PIPEDA, that number does not belong there.
This is an easy thing to get wrong, and for a sensible reason. Search for how long you have to report a breach in Canada and the results hand you a 72-hour clock with real confidence. Some of those pages are about European law and never say so clearly. Others are Canadian and have simply borrowed the number. The accurate write-ups do exist, and they are mostly law-firm client alerts written for counsel, at counsel's length, hedged the way advice to a client has to be. None of them lead with the correction.
What PIPEDA says
You report to the Privacy Commissioner when a breach of your security safeguards, meaning any loss, unauthorized access or unauthorized disclosure of personal information you hold, clears one bar. Section 10.1 of the Act sets that bar as whether it is "reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual."
Once it clears, the report goes in "as soon as feasible after the organization determines that the breach has occurred."
That is the whole timing standard, and it contains no fixed clock.
It reads like good news, and it is only half that. A deadline is hard to hit and easy to prove you hit, and a judgement call reverses both halves of that. "As soon as feasible" is a judgement you make on a bad day with incomplete information, and if it is ever questioned, you will be defending that judgement months later against people who have had the luxury of time.
The 72 hours people quote at you comes from somewhere real, just not from Canada. Article 33 of the GDPR requires notification to a supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach. That is a real deadline with a real number attached, and it applies to organizations covered by European law.
Plenty of Canadian companies are covered by it, which is part of why the confusion sticks. If you have European customers or staff, you may owe someone a 72-hour notification. What you do not owe is a 72-hour notification to the OPC, and running your Canadian obligation off a European number will not save you if the question ever gets tested.
What "real risk of significant harm" means when you have to decide
The Act does not leave "significant harm" to interpretation. It lists it: bodily harm, humiliation, damage to reputation or relationships, loss of employment or business or professional opportunities, financial loss, identity theft, negative effects on the credit record, and damage to or loss of property.
To decide whether the risk is real, the Act gives you two factors. How sensitive is the information, and how probable is it that the information has been, is being, or will be misused.
That is a smaller test than it looks, and you can work through it in an afternoon. A spreadsheet of names and work email addresses that a staff member emailed to the wrong colleague inside the company sits at one end. A customer list with dates of birth, home addresses and partial payment details, sitting in an S3 bucket that was public for six weeks, sits at the other. Most real incidents land somewhere in between, and the answer is a judgement call rather than a calculation.
You will not get every call right. Write down how you made it and what you knew at the time. An assessment written on the day holds up better than a correct one you piece together from memory a year later.
What to do, in order
The clock that matters starts when you decide a breach happened. "As soon as feasible" runs from that moment, so being slow to reach it is not a safe place to sit.
In PIPEDA Findings #2022-004, the OPC investigated MGM over a 2019 breach. The company began investigating in August 2019, notified affected Americans in September, and then left the risk to Canadians unassessed until February 2020, after the OPC made contact. The OPC found it had not reported or notified as soon as feasible, and set the expectation that the standard is flexible without being infinitely elastic. A slow start is not a neutral choice.
- Contain it. Shut off the access or the exposure before you analyze anything.
- Determine whether a breach occurred, and start this immediately rather than when the incident is tidy. Note the date you determined it.
- Assess real risk of significant harm against the two factors, and write the assessment down as you go.
- Report to the OPC if it clears the bar, using their breach report form.
- Notify affected individuals, directly where you can, with enough detail that they can protect themselves.
- Tell other organizations that could reduce the harm. Your payment processor, a bank, law enforcement where relevant.
- Record it, whatever you concluded, including the incidents you decided not to report.
If the situation calls for a lawyer, get one. A breach involving regulated data, a ransom demand, or anything touching Quebec is not the moment to lean on a blog post, this one included.
The record almost nobody keeps
The OPC states this one plainly: "PIPEDA requires you to keep records of all breaches of security safeguards of personal information under your control, whether there is a real risk of significant harm or not."
That covers every breach, not only the reportable ones. The Breach of Security Safeguards Regulations require you to keep each record for 24 months after you determine the breach occurred, and the record has to hold enough for the Commissioner to check that you reported and notified properly.
In practice that means the laptop left on a train, the misdirected email with a client attachment, the contractor account that stayed live for three months after they left. Each one is a breach of security safeguards. Most will not come close to the reporting threshold. All of them are supposed to be written down and kept for two years.
The OPC can ask to see those records. If you have never kept them, you have nothing to hand over, and that gap will say more about your program than any single incident would.
A dated log covers it: what happened, what information was involved, what you concluded about the risk and why, and what you did about it. It can live in a spreadsheet. What it cannot do is get written retroactively when someone asks for it.
If you have a Quebec footprint
Quebec runs on its own statute, its own regulator, and its own trigger. There they are called confidentiality incidents, and the test is a risk of serious injury rather than PIPEDA's real risk of significant harm. Notification goes to the Commission d'accès à l'information rather than the OPC, and the province wants its own register of incidents on top of the federal record you are already keeping.
The timing wording there is its own question and is not the federal standard quoted above, so check it against the statute or your lawyer rather than against this article. The same borrowing problem turns up in Quebec too. A number repeated confidently online is not a source. If you operate on both sides of that line, our comparison of PIPEDA and Law 25 covers the wider differences, and it is worth knowing which of your data sits where before an incident forces the question. That is a data sovereignty problem as much as a legal one, and whether your data has to stay in Canada is the place to start.
Where to start
Knowing your reporting obligation is close to worthless if you cannot tell that a breach happened.
Every timing standard in every jurisdiction starts counting from the moment you know, which means an organization with poor detection gets a longer runway right up until the day it gets a much worse conversation. The MGM finding is a story about assessment being slow. The more common version, in companies your size, is nobody noticing at all.
This is where a framework read earns its keep. NIST CSF 2.0 puts incident reporting and communication in its own category under Respond, RS.CO, and the subcategory RS.CO-02 is a single sentence: internal and external stakeholders are notified of incidents. Reading your own organization against Detect and Respond will tell you fairly quickly whether your breach notification policy is a real capability or a document. Our walkthrough of what changed in CSF 2.0 is a reasonable place to start if the framework is new to you.
If you would rather start that assessment from your actual documents than from a blank page, NISTForge finds and quotes the evidence for you to review, and our team works through it with you when the answer needs a human attached to it.
Either way, delete the 72 from your incident response plan. Then go and check whether anyone has been keeping the log.