Your website had a data breach — what Canadian law makes you do next

The call always sounds roughly the same. A strange page has appeared on the site, or the host has sent a warning, or a customer says they got an odd email from your address. Then, somewhere in the next ten minutes, the real question arrives: is this a website data breach, and do I have to tell anybody?

In Canada the answer is sometimes yes, and the deadline is not a date on a calendar — it is "as soon as feasible". Since 1 November 2018, a business whose security safeguards have been breached has three separate duties under PIPEDA, and one of them applies even to the small incidents you decide not to report.

I am a web designer, not a lawyer. What I can tell you is what happens on the server in the first hour, because that hour usually decides whether you can answer the Privacy Commissioner's questions at all. Every legal point below links to the statute or to the regulator's own guidance.

Do I have to report a data breach to the government in Canada?

Only above one threshold. Under PIPEDA you must report a breach of security safeguards to the Privacy Commissioner of Canada, and notify the individuals affected, when it is reasonable in the circumstances to believe the breach creates a real risk of significant harm to an individual. Below that line, no report — but still a record.

Notice what is not in that test. Not the size of your company. Not how many people were affected. Not whether the attacker was clever or whether you were careless. PIPEDA has no minimum headcount and no revenue floor, and Ontario has no general private-sector privacy law of its own, so an Ontario business with a contact form sits under the federal statute exactly as a bank does. Ontario health-information custodians have a second, stricter regime on top of this one under PHIPA; if you run a clinic, that is a separate conversation with your privacy officer.

The other thing worth saying out loud: a breach of security safeguards is broader than "we got hacked". Losing a laptop is one. Emailing a client list to the wrong address is one. So is leaving something readable that should not have been readable.

Here is what that looks like on an actual small-business website, which is the part the legal guidance never covers.

That last row is the one to take most seriously. Your contact form does not usually store anything — it emails. Which means the breach surface is not the website at all. It is a mailbox holding years of names, phone numbers, addresses and problems people described to you in confidence.

What counts as a "real risk of significant harm"?

The Act does not leave this to your imagination. It defines significant harm as a specific list, and then gives you two factors for deciding whether the risk of it is real. You are expected to reason through both and write down your conclusion — not to feel your way to an answer.

The list, quoted from the statute, is "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."

Two of those deserve a second look, because they are the ones that catch ordinary businesses. Humiliation and damage to reputation or relationships mean the harm does not have to be financial. A leaked enquiry list from a clinic, a lawyer, a debt-help service or an addiction counsellor can be devastating without a dollar moving. If you build for a medical or health-adjacent practice, treat the enquiry form as the sensitive part of the site, because that is exactly what it is.

Then the two factors, from the same section: "the sensitivity of the personal information involved in the breach" and "the probability that the personal information has been, is being or will be misused."

Encryption is worth one honest sentence. Properly encrypted data with a key the attacker never touched pushes the probability of misuse down hard. "The hosting has SSL" is not that — HTTPS protects data in transit, not a database sitting on a disk. The two get confused constantly, usually by whoever is trying to reassure you.

The record you must keep even when you don't report

This is the obligation small businesses miss, and it is not optional or graded on severity. PIPEDA requires you to keep and maintain a record of every breach of security safeguards, reportable or not, and the regulations set the retention at 24 months from the day you determined the breach occurred. The Commissioner can ask to see them.

The OPC's own guidance is blunt about the scope: there "must be a record of every breach of security safeguards," and businesses must "keep breach records of all breaches of security safeguards for two years." So the nuisance incident you dismissed in four minutes still needs four lines written down.

Four lines is genuinely the minimum. The OPC lists the required contents as the date or estimated date of the breach, a general description of the circumstances, the nature of the information involved, and whether or not the breach was reported.

That example is a real one from a client site, shortened. And I would add a fifth line the law does not ask for: why you concluded what you concluded. A record that says "not reported" tells a regulator nothing. A record that says "not reported, because the forms do not store submissions and the access log shows no successful query" tells them you actually did the work.

Before your host restores that backup

Stop. A restore is the fastest way to destroy the only evidence you have. Both the report to the Commissioner and the notice to individuals must describe the personal information involved — and after a clean restore, nobody on earth can tell you what that was. Make the site safe first, then preserve, then rebuild.

"Make it safe" does not mean "make it normal". Taking the site offline, or putting it behind a maintenance page, stops the bleeding without touching the evidence. What you want copied before anything else, ideally to somewhere outside that server: the web access logs covering the period, the error logs, the current files as they stand, and a dump of the database as it stands. Then restore.

I will give you the example that made me care about this. On a client site last August, an automated SQL-injection scanner worked through two unprotected forms for about a minute, hundreds of submissions, one malformed payload after another — time-based probes, a couple of Oracle-specific ones. The mailbox drowned. The interesting part came after.

The question that decided whether this was a nuisance or a reportable breach was narrow and factual: did the payloads that asked the database to pause for fifteen seconds actually make the server pause? If yes, the injection worked and the data was exposed. If no, it was a mail flood and a bad afternoon. That answer lives in exactly one place — the SSL access log at those timestamps. Restore the site first and you have deleted your own answer, and then you are writing a breach report that says "we don't know", which is the worst sentence you can put in one.

A backup restores your website. It does not restore the evidence you are legally required to describe.

What has to go in the report and the notification?

The regulations spell both out, and they overlap but are not identical. The report to the Commissioner is an account of what happened and how big it is. The notice to the individual is that, plus the part they care about: what this means for them and what they should do now.

The report goes to the OPC in writing, through their secure online breach reporting form; they will also accept any format that captures the required information. Notice to individuals is normally direct — in person, by phone, by mail or by email. Indirect notice, meaning a public announcement, is the fallback for when direct notice would cause further harm, would be an undue hardship, or when you simply do not have contact details for the people affected.

And there is a third notice people forget. If another organisation or a government institution could reduce the risk of harm, you have to tell them too. In practice that is your payment processor, a bank, sometimes the police — the people who can freeze something before it is used.

One nuance on timing that is genuinely useful: the statute says "as soon as feasible after the organization determines that the breach has occurred." The clock starts at determination, not at the intrusion. You are allowed the time it takes to establish that something actually happened. You are not allowed to stretch that investigation because the answer is inconvenient.

What happens if you just say nothing?

Section 28 of PIPEDA turns silence into an offence. Knowingly failing to report a reportable breach, or knowingly failing to keep the records, carries a fine of up to $10,000 on summary conviction and up to $100,000 as an indictable offence. Note which duties are named: reporting and record-keeping.

The word doing the work in that sentence is knowingly. A good-faith judgement that turned out to be wrong is a different thing from a decision to keep quiet. Which is precisely why the "why we concluded this" line in your record is worth more than the four required ones: it is the difference between a call you documented and a call you buried.

For scale, the OPC reported receiving "almost 700 breach reports from businesses, affecting more than 20 million Canadians" in its 2025–26 year. Reporting does not single you out. At this point it is ordinary business paperwork, filed by hundreds of Canadian companies a year.

Ten steps, in the order you actually do them

1. Contain without destroying. Site offline or behind a maintenance page. Do not restore, do not "clean up" files.
2. Copy the evidence off the server. Access logs, error logs, current files, current database.
3. Write down the time you found out. That timestamp starts your "as soon as feasible" clock.
4. Change the credentials that matter. Hosting, CMS admin, database, and the mailbox your forms deliver to.
5. Work out what data was reachable — not what was definitely taken, but what the attacker could have reached.
6. Apply the two factors — sensitivity, and probability of misuse — and write your conclusion down as you go.
7. If it clears the line, report to the OPC through their secure form, and notify the people affected.
8. Tell anyone who can reduce the harm: processor, bank, and any organisation whose accounts are exposed.
9. File the record, reportable or not, and calendar it for 24 months.
10. Close the hole that let it in, then check the other sites on the same hosting account.

Step ten is not padding. Shared hosting means shared blast radius, and I have seen a second site on the same account sitting there quietly broken for days because everyone was looking at the first one. If you would rather this never became your Tuesday, ongoing maintenance is the unglamorous version of this whole article — patching, updates and backups that exist somewhere other than the server they are backing up. You can also start with a free audit of your site to see what is currently exposed.

Frequently asked questions

Sources, read on 18 September 2026: Justice Laws — PIPEDA, sections 10.1 to 10.3 for the reporting and notification obligations, the definition of significant harm, the two risk factors and the record-keeping duty, and section 28 for the $10,000 and $100,000 fines; Breach of Security Safeguards Regulations (SOR/2018-64), in force 1 November 2018, for the contents of the report and the notification, direct and indirect notice, and the 24-month retention; OPC — What you need to know about mandatory reporting of breaches for the record contents and the "record of every breach" requirement; OPC news release, 4 June 2026 for the almost-700 reports figure.