If your website was compromised and personal information was exposed, Canadian privacy law may require you to report it to a regulator and tell the people affected, and the clock starts when you discover it, not when you finish investigating. Under PIPEDA the test is whether the breach creates a real risk of significant harm. Alberta’s PIPA sets a similar test with a different notification path. Both carry fines up to $100,000.

By Cody Wise, founder of Wise Media, Calgary. Published 6 October 2026. This is not legal advice. Every obligation below is quoted from the statute, the regulations or the regulator’s own guidance, all linked at the end, and you should confirm how they apply to your business with a lawyer.

Summary

  • A hacked website can be a reportable privacy breach. It depends on whether personal information was exposed and whether that creates a real risk of significant harm, not on how the attacker got in.
  • Two thresholds, one phrase. PIPEDA section 10.1 and Alberta PIPA section 34.1 both turn on a real risk of significant harm. The wording is nearly identical. The procedures are not.
  • The reporting path differs by province. Under PIPEDA you report to the federal Privacy Commissioner and notify affected individuals yourself. Under Alberta PIPA you notify the Commissioner, and section 37.1 lets the Commissioner require you to notify individuals.
  • Timing is immediate, not scheduled. PIPEDA says as soon as feasible. Alberta PIPA says without unreasonable delay. Neither gives you a fixed number of days to hide behind.
  • Record-keeping is wider than reporting. PIPEDA requires a record of every breach of security safeguards, reportable or not, kept for 24 months.
  • Fines reach $100,000. PIPEDA section 28 and Alberta PIPA section 59 both top out there for an organization.
  • Your rankings are a separate problem. Google surfaces the compromise in the Search Console Security Issues report and you request a review there once the site is clean.
An overhead view of a laptop and a notebook on a desk, set up to log the timeline of a website security incident
The first artefact of a breach response is not a fix. It is a written timeline, because every obligation below is dated from the moment you discovered the problem.

Table of Contents

Does a hacked website count as a reportable breach?

Sometimes. The question is not whether you were hacked. It is whether the compromise involved personal information under your control, and whether a reasonable person would conclude that the exposure creates a real risk of significant harm to someone. A defaced homepage with no database access is a security problem. A compromised contact form, a dumped WooCommerce customer table, a skimmer on a checkout page or an admin account used to read submitted applications is a privacy problem with legal duties attached.

What counts as personal information on a typical business site

  • Contact form and quote request submissions, including names, phone numbers, addresses and free-text details
  • Customer accounts, order histories and shipping addresses in an ecommerce store
  • Newsletter lists stored in or synced through the site
  • Uploaded documents, from job applications to intake forms to property or financial paperwork
  • Booking and appointment records, including guest or client details
  • Saved payment tokens, and in the worst case card data captured live by injected script
  • Server logs tying IP addresses to identifiable individuals

Most owners underestimate this list, because the site feels like a brochure. It is usually a small database of other people’s information with a public login page attached. That is the mental shift that makes the rest of this article make sense, and it is the same reasoning behind keeping a current inventory of what your site actually holds, which we covered when setting out who actually owns your website, its code and its accounts.

The distinction that trips people up

There are two separate obligations hiding in one event. The duty to record and the duty to report. Under PIPEDA you must keep a record of every breach of security safeguards involving personal information under your control, whether or not it is reportable. You must report only those that meet the real risk of significant harm threshold. Many businesses do neither, then discover during a complaint that the absence of a record is itself a problem.

Which law applies to you: PIPEDA, Alberta PIPA, or both?

Short answer for an Alberta business: probably Alberta’s PIPA for what you do inside the province, and PIPEDA for personal information that crosses a provincial or national border, plus PIPEDA if you are federally regulated. Alberta, British Columbia and Quebec have private-sector privacy laws that have been declared substantially similar to PIPEDA, which is why the provincial statute generally governs intra-provincial commercial activity in those provinces. Everywhere else in Canada, PIPEDA is the private-sector law.

That split matters more than it sounds, because a website is not an intra-provincial object. If your Calgary store ships to Saskatchewan, takes bookings from Ontario or uses a United States hosting provider, information is moving across borders. In practice a lot of Alberta businesses need to be able to answer under both regimes, and the honest professional answer is that the allocation is a legal question, not a web development one.

 PIPEDA (federal)Alberta PIPA
Reporting triggerBreach creates a real risk of significant harm to an individual (s.10.1)A reasonable person would consider that there exists a real risk of significant harm to an individual (s.34.1)
Who you report toOffice of the Privacy Commissioner of CanadaOffice of the Information and Privacy Commissioner of Alberta
TimingAs soon as feasibleWithout unreasonable delay
Notifying individualsYou must notify affected individuals yourselfThe Commissioner may require you to notify individuals (s.37.1). You may also notify voluntarily
Notifying other organizationsRequired where another organization or a government institution may be able to reduce or mitigate the harm (s.10.2)Address as part of your notice and harm mitigation
Record-keepingA record of every breach, kept 24 months (s.10.3 and the regulations)Keep records sufficient to show your assessment and response
Maximum fine, organization$100,000 on indictment, $10,000 on summary conviction (s.28)$100,000 for a person other than an individual (s.59)

Quebec’s private-sector regime also imposes incident obligations, including a register of confidentiality incidents, and British Columbia has its own PIPA. We have not reproduced their section numbers or penalty figures here because we could not verify them against primary text in the same pass, and on a compliance page an unverified number is worse than a gap. If you hold personal information about people in Quebec or British Columbia, confirm those duties with the Commission d’accès à l’information and the BC Office of the Information and Privacy Commissioner respectively.

What is a real risk of significant harm?

It is a two-part assessment. First, is the harm significant? Then, is the risk of it real? The Privacy Commissioner’s guidance lists significant harm as including bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss and identity theft, along with negative effects on a credit record and damage to or loss of property. That is a wide definition, and embarrassment-grade harm is inside it.

The two factors you have to weigh

  1. Sensitivity of the information. Sensitivity is contextual. Health and financial information is usually sensitive, and the guidance also points to information about ethnic origin, political opinions, genetic data, sexual orientation and religious beliefs. A list of email addresses is less sensitive than the same list labelled by medical service requested.
  2. Probability that the information has been, is being, or will be misused. Relevant questions include who accessed the data, how long it was exposed, whether there is evidence of malicious intent, whether the data was encrypted or otherwise unreadable, and whether harm has already materialised.

Worked examples, deliberately mundane

ScenarioLikely assessmentWhy
Homepage defaced, no database or file access evidenced in logsRecord it, probably not reportableNo personal information exposed, but you still owe yourself the written assessment
Admin account compromised, contact form submissions readable for three weeksLikely reportableFree-text submissions often contain sensitive detail, and a long exposure window raises probability of misuse
Payment skimmer injected on a checkout pageReportable, and urgentFinancial information, clear malicious intent, direct route to financial loss and identity theft
Vulnerable plugin exploited to send spam, no evidence of data accessRecord it, assess carefullyTurns on what the shell could reach, not on what the attacker appears to have used it for
Uploaded job applications or intake documents exposed by a misconfigured directoryLikely reportableIdentity documents and personal histories sit at the top of the sensitivity scale

Notice the pattern. The question is never “did they take it”. It is “could they have, and how bad would that be”. Waiting for proof of exfiltration before assessing is the single most common way businesses blow the timing requirement.

The first 72 hours, in order

Technical cleanup and legal assessment run in parallel, not in sequence. Here is the order that keeps both defensible. For the cleanup side in detail, work through our WordPress hacked site cleanup and hardening guide alongside this.

  1. Start a written log, timestamped. Date and time of discovery, who found it, what they saw. Every obligation below is measured from discovery, so an undocumented discovery date is a liability.
  2. Contain without destroying evidence. Take the site offline or into maintenance mode, rotate credentials, revoke sessions and API keys. Preserve server logs, access logs and a forensic copy of the compromised state before you overwrite anything. Restoring from backup first and asking questions later destroys the only record of what was reachable.
  3. Determine scope. What did the compromised account or code have access to? Database tables, uploaded files, connected services, email. The answer is the basis of the harm assessment, and “we are not sure” means you assume the broader scope until you are.
  4. Run the real risk of significant harm assessment, in writing. Sensitivity, then probability of misuse. Record the reasoning and the conclusion, including a conclusion of not reportable. The written assessment is the artefact that shows you took the duty seriously.
  5. Report to the regulator if the threshold is met. As soon as feasible under PIPEDA, without unreasonable delay under Alberta PIPA. Both regulators would rather receive an early report with gaps than a complete one late. Alberta’s guidance is explicit that you should submit even if your internal investigation is incomplete.
  6. Notify affected individuals. Under PIPEDA this is yours to do, and the method is prescribed. Under Alberta PIPA the Commissioner may direct it, though nothing stops you notifying voluntarily and doing so usually reads better than waiting to be told.
  7. Notify other organizations that can reduce the harm. PIPEDA section 10.2 contemplates this. In practice it means your payment processor, your bank, a credit bureau in a card or identity case, and law enforcement where appropriate.
  8. Clean, rebuild, harden, then deal with Search. Patch the entry point, not just the symptom. Then request a review in Search Console.
  9. File the record. 24 months minimum under the federal regulations, and keep it somewhere a successor can find it.
Documents being signed at a desk, representing the written breach assessment and notification records a business must keep
The written assessment is not paperwork for its own sake. A reasoned decision on file, even a decision not to report, is what distinguishes a handled incident from an ignored one.

What the report must contain, and how to notify people

The federal Breach of Security Safeguards Regulations set out what a report to the Commissioner must contain. Section 2(1) requires a description of the circumstances of the breach and, if known, the cause, along with when it occurred, the type of personal information involved, the number of individuals affected, the steps the organization has taken to reduce the risk of harm, how individuals are being notified, and contact details for a representative who can answer questions.

The report checklist

  • Circumstances of the breach, and the cause if known
  • The date or period during which it occurred
  • The type of personal information involved
  • The number of individuals affected, or an estimate
  • Steps taken to reduce the risk of harm
  • Steps taken or to be taken to notify affected individuals
  • Contact information for someone who can answer the regulator’s questions

Direct and indirect notification

Direct notification is the default. The regulations describe it as notification given to the affected individual in person, by telephone, mail, email or any other form of communication a reasonable person would consider appropriate. Indirect notification, meaning a public communication or similar measure that could reasonably be expected to reach the affected individuals, is permitted in defined situations: where direct notification would be likely to cause further harm, where it would cause undue hardship for the organization, or where the organization does not have contact information for the individuals.

Read that list carefully, because “undue hardship” is not a convenience exemption. Having five thousand email addresses and not wanting to send five thousand emails is not hardship. Not having addresses at all is a different matter.

What a good notification to customers actually says

  • What happened, in plain language, and when
  • Specifically which of their information was involved, and which was not
  • What the realistic risk to them is, without minimising it
  • What you have already done
  • What they should do now, concretely, such as changing a reused password or watching a statement
  • A named human and a direct way to reach them

The instinct to soften this is strong and wrong. Vague notifications generate second contacts, complaints and the impression of concealment. A specific, unflattering, early notification is reputationally cheaper than a polished late one.

Separate problem, separate process, and it does not wait for your legal work. Google reports compromises through the Security Issues report in Search Console, where an owner can see the list of suspected files hosted on the site. While the compromise is live, visitors can meet an interstitial warning instead of your page, which does more immediate commercial damage than a ranking change. Once the site is genuinely clean and the entry point is closed, you request a review in the Security Issues report.

The sequencing rule

  1. Remove the malicious content and close the vulnerability that allowed it
  2. Confirm the site is clean, including files outside the web root and scheduled tasks
  3. Only then request a review, because a failed review costs you the turnaround time twice
  4. Monitor the Security Issues report until it clears, and keep monitoring afterwards

Almost every compromise we are called into arrives through a known, patchable vulnerability in a plugin or theme that was left alone. The specifics change monthly, and the pattern does not, which is the argument we made in the Elementor Pro vulnerability runbook and the reason patch cadence belongs in a contract rather than in someone’s good intentions. What that cadence should look like is set out in what a WordPress maintenance plan should actually include.

The mistakes that turn an incident into a penalty

  • Restoring from backup before preserving evidence. Fast, understandable, and it erases the only basis for an honest scope assessment.
  • Waiting for certainty before reporting. The standard is as soon as feasible, not once fully understood. Alberta’s regulator says to submit even with an incomplete investigation.
  • Treating no proof of theft as no risk. The test is probability of misuse, assessed on what was reachable.
  • Keeping no record of breaches you decided not to report. The federal record-keeping duty covers every breach, not only the reportable ones.
  • Assuming your developer or host handles it. The obligation sits with the organization that controls the personal information. A vendor can help you discharge it. It cannot absorb it.
  • Quietly fixing it and saying nothing. Knowingly failing to report under PIPEDA is an offence, with a maximum fine of $100,000 on indictment.
  • Collecting data you never needed. The cheapest breach is the one with nothing valuable in it. Most sites collect, and keep forever, fields nobody ever reads.
  • Having no privacy policy that matches reality. If your posted policy describes practices you do not follow, the breach is the moment that becomes visible. We covered the baseline in whether your business needs a privacy policy in Canada.

The thirty minute preparation that changes the outcome

  1. Write down what personal information your website and its connected services actually hold, table by table and integration by integration
  2. Delete the fields and the historical records you have no current reason to keep
  3. Name the person who makes the reporting call, and their backup
  4. Save the two regulator reporting pages as bookmarks, now, not during an incident
  5. Create the empty breach record file so the duty has somewhere to land
  6. Confirm you have working, tested, offsite backups and a known patch cadence

FAQ

Do I have to report a data breach in Canada?

You must report to the Privacy Commissioner, and notify affected individuals, if a breach of security safeguards involving personal information under your control creates a real risk of significant harm to an individual. That is the test in PIPEDA section 10.1. Alberta’s PIPA section 34.1 applies a similar test for organizations covered by it. Breaches below that threshold are not reportable, but the federal record-keeping duty still applies.

How long do I have to report a breach?

There is no fixed number of days. PIPEDA requires reporting as soon as feasible after determining a breach has occurred, and Alberta PIPA requires notice without unreasonable delay. Treat both as “immediately once you have enough to describe it”, and file an incomplete report rather than a late one.

What counts as a real risk of significant harm?

Significant harm includes bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss and identity theft, plus negative effects on a credit record and damage to or loss of property. Whether the risk is real is assessed on the sensitivity of the information and the probability that it has been, is being or will be misused.

What is the fine for not reporting a data breach in Canada?

Under PIPEDA section 28, an organization that knowingly contravenes the reporting or record-keeping obligations is liable to a maximum fine of $10,000 on summary conviction or $100,000 on indictment. Under Alberta’s PIPA section 59, failing to notify the Commissioner is an offence with fines up to $10,000 for an individual and $100,000 for a person other than an individual.

How long do I have to keep breach records?

The federal Breach of Security Safeguards Regulations require an organization to maintain a record of every breach of security safeguards for 24 months after the day on which the organization determines that the breach occurred. That covers breaches you concluded were not reportable.

My site was defaced but no data was taken. Do I still have obligations?

If no personal information under your control was exposed, there is likely nothing to report, but you should still document the incident and your assessment, close the vulnerability, and keep the record. “No data was taken” is a conclusion you have to be able to support from logs, not an assumption.

Is my web agency or host responsible for reporting?

The obligation sits with the organization that controls the personal information, which is almost always you rather than your vendor. A host or agency can detect, contain, investigate and help you prepare the report, and Alberta’s guidance contemplates authorising a third party in writing to give notice on your behalf, but the duty does not transfer by default. Check what your contract actually says.

Will a breach hurt my Google rankings?

The bigger immediate cost is usually a browser or search warning that stops visitors reaching you at all. Google flags the compromise in the Search Console Security Issues report, and once the site is clean and the entry point closed you request a review there. Clean first, then request, because a failed review costs you the waiting period twice.

The takeaway

A website compromise is two incidents. One is technical and you can buy your way out of it in a weekend. The other is legal, it is dated from the moment you noticed, and it is judged on what you wrote down rather than on how quickly you got the site back up. The businesses that come out of this well are not the ones with the best firewall. They are the ones that knew what personal information they held, decided in advance who makes the call, and documented the reasoning the same day.

Do the inventory this week, while nothing is wrong. Delete what you do not need. Then make the patch cadence somebody’s contractual job.

Want the inventory and the patch cadence handled?

We audit what a site actually holds, cut the data nobody needs, close the common entry points and put the update and backup cadence on a schedule somebody is accountable for. If you have just been compromised, or you would rather not find out this way, tell us what you are dealing with through our intake form and we will come back with the first three things we would change. For ongoing cover, our website growth packages include the maintenance layer, and new builds under our website packages start from a smaller data footprint by design.

Primary sources