Website or Database Compromise — What Canadian Organizations Must Do

Which laws apply

Jurisdiction	Applies when	Regulator
PIPEDA	The compromised database held personal information used in commercial activity; or the affected individuals are in provinces without substantially similar legislation (Ontario, Manitoba, New Brunswick, and others)	Office of the Privacy Commissioner of Canada (OPC) — priv.gc.ca
Alberta PIPA	Personal information about Alberta residents or employees was accessed or exfiltrated from your database	OIPC Alberta — oipc.ab.ca / breachnotice@oipc.ab.ca
BC PIPA	Personal information about BC residents or employees was accessed or exfiltrated from your database	OIPC BC — oipc.bc.ca

For most organizations, PIPEDA and one or both provincial statutes apply simultaneously. A separate notification is required for each applicable regulator if RROSH is determined.

---

What makes this scenario different

Ransomware, phishing, and lost devices are breach scenarios where the initial event is often obvious — a ransom note appears, an employee reports a suspicious email, a laptop is reported missing. A website or database compromise is frequently the opposite: the attacker gains access, extracts what they want, and leaves no visible sign. Organizations commonly discover these breaches weeks or months after the initial intrusion, through a third-party threat intelligence alert, a customer complaint about fraudulent activity, a security scan, or a credential dump appearing on the dark web.

Three features define this scenario.

The dwell time is often substantial and unknown. Between the moment an attacker first exploits a vulnerability and the moment your organization discovers the intrusion, attackers may have had continuous or repeated access to your database. A SQL injection vulnerability in a web form may have been exploited months before discovery. A web shell installed in a compromised plugin may have been active for a year. Your RROSH assessment must account for the full dwell period, not just the moment of discovery.

Exfiltration is often difficult to confirm. SQL queries that extract data look similar to legitimate queries in many logging configurations. A web shell gives an attacker interactive server access with no automatic exfiltration alert. Organizations frequently cannot confirm whether specific records were extracted — only that an attacker had the capability and access to extract them. When exfiltration cannot be ruled out and the attacker had access to personal information, the RROSH assessment should treat exfiltration as likely.

The vulnerability may affect more than you know. A SQL injection vulnerability in one form or endpoint may give access to your entire database, not just the table the form connects to. A compromised plugin on a WordPress site may give an attacker access to every table, every file, and every credential stored on the server. Scoping the breach accurately requires understanding not just where the attacker entered but what they could have reached from that entry point.

---

Immediate steps — this scenario specifically

1. Take the affected system offline if it is actively compromised — but preserve logs first. If an attacker is actively in your system, taking it offline stops the intrusion. But before making changes, capture the current state: preserve web server logs, database query logs, access logs, and any file system evidence. These are the records your forensic investigation and RROSH assessment depend on. If you patch immediately without preserving logs, you lose the evidence you need to determine what was accessed.

2. Identify the vulnerability and the initial entry point. Determine how the attacker gained access: SQL injection through a web form, a remote code execution vulnerability in a plugin, a compromised admin credential, an unpatched CMS or framework version. The entry point determines the scope of what the attacker could have reached from that position.

3. Determine the dwell period. Check your web server logs, database logs, and security event logs for the earliest evidence of exploitation. If you cannot find the first point of entry in logs, use the earliest plausible date based on vulnerability disclosure dates, plugin installation or update history, or the date a known vulnerability was published for the software version you were running. The dwell period runs from that date to the date you contained the intrusion.

4. Determine what personal information was accessible during the dwell period. Map the database tables and files the attacker could have reached from the entry point. Which tables contain personal information? What categories — customer contact data, payment records, account credentials (hashed or plaintext), health information, transaction history? How many individuals' records were in those tables?

5. Check whether the database credentials or admin passwords were exposed. If the attacker accessed your database or server configuration files, they may have obtained credentials that allow ongoing access — to the database directly, to your email, or to third-party services. Rotate all credentials immediately: database passwords, admin panel passwords, API keys stored in configuration files, and any other credentials accessible from the compromised system.

6. Do not restore from backup before completing your evidence capture. Restoring a clean backup is the right recovery step — but only after you have preserved logs, captured the compromised state, and completed your initial forensic review. Restoring early destroys evidence of what the attacker accessed and for how long.

---

What drives RROSH in this scenario

Factors that push toward RROSH:

• The attacker extracted a database dump containing customer or employee records — confirmed exfiltration with malicious intent is strong evidence of RROSH
• The compromised database contained sensitive categories: payment card data, SINs, health information, account credentials (even hashed — rainbow table attacks are realistic for weak passwords), or enabling combinations (name + date of birth + address)
• A web shell was present and active during a period when the database held personal information — the attacker had full capability access regardless of whether extraction is confirmed
• The vulnerability was in a public-facing form or endpoint that handles personal information (checkout form, login page, customer account portal)
• The attacker's subsequent activity matches monetization of data: credential stuffing against other sites, phishing emails using your customer data, fraud reports from affected individuals
• The dwell period was extended — weeks or months of potential access

Factors that push against RROSH:

• The compromised system held only public-facing content with no personal information stored in the database (a brochure website with no user accounts, no forms that collect personal data, no transaction history)
• The attack was detected and contained within minutes before any database queries were executed, and logs confirm no data-table access
• The database held only non-sensitive, non-identifying information (aggregated statistics, public content)
• The attacker's activity was limited to defacement of public pages with no evidence of database access

The confirmed-exfiltration threshold: When a database dump appears on a dark web forum or is confirmed by a threat intelligence service, RROSH is almost certainly present — the data is in the hands of a malicious actor and is likely being used or sold. Do not delay notification while attempting to negotiate with the attacker or verify the authenticity of the dump. Assess and notify immediately.

---

Likely verdict range

Scenario	Typical verdict
SQL injection confirmed; database dump of customer records exfiltrated	RROSH — confirmed access with malicious intent and exfiltration
Web shell present; database with customer personal information accessible during dwell period; exfiltration not confirmed	RROSH likely — attacker had full capability access; treat exfiltration as probable
Plugin vulnerability exploited; attacker accessed admin panel but no database queries in logs	Case-by-case — depends on what the admin panel could reach and log completeness
Database contained hashed passwords and email addresses only; no financial or health data	Case-by-case — depends on hashing strength and whether email + account enables downstream harm
Website defaced; no database access in server logs; no user accounts or personal data in database	Likely BELOW_RROSH — but confirm log completeness before concluding
Payment card data accessed during checkout process (card-skimming script / Magecart attack)	RROSH — financial data with confirmed attacker access; also triggers PCI-DSS obligations

---

Scenario-specific obligations and complications

If RROSH is determined:

• OPC notification (PIPEDA): Report to the Office of the Privacy Commissioner of Canada as soon as feasible after determining RROSH. Use the OPC breach report form at priv.gc.ca. If your investigation is ongoing, file on available information and supplement the report as your investigation continues.
• OIPC Alberta notification (AB PIPA): Notify the OIPC Alberta without unreasonable delay. Email breachnotice@oipc.ab.ca. Use the official OIPC Alberta notification form.
• OIPC BC notification (BC PIPA): Notify the OIPC BC through their official breach notification process at oipc.bc.ca.
• Individual notification: Notify each affected individual directly. The notification must describe what happened, what information was involved, what steps the organization is taking, and what individuals can do to protect themselves. For credential exposure, advise individuals to change their password on your site and on any other site where they used the same password. For payment card exposure, advise them to contact their card issuer immediately.

If RROSH is not determined:

• No regulator notification required under PIPEDA or Alberta PIPA.
• No individual notification required.
• Internal breach record required — document the intrusion, the scope of access, your RROSH assessment and reasoning, and the remediation steps taken.
• Investigate the root cause and close the vulnerability. The absence of RROSH does not mean the incident was not serious — it means the specific personal information at risk did not cross the harm threshold.

BC PIPA — voluntary reporting option. Under BC PIPA, organizations may voluntarily report to the OIPC BC even where RROSH is not present. For web compromises involving BC residents where exfiltration cannot be confirmed but the attacker had database access, voluntary reporting demonstrates good faith and may reduce the risk of a complaint-driven investigation. See BC PIPA Breach Reporting.

For Ontario organizations. Ontario has no provincial private-sector privacy legislation — PIPEDA is the applicable framework. Report to the OPC at priv.gc.ca. No separate provincial regulator report is required. See Ontario Data Breach Reporting Requirements.

Complications specific to this scenario:

You do not know when the intrusion started. If logs are incomplete or the earliest exploitation date cannot be confirmed, use the most conservative estimate: the date the vulnerability was introduced (plugin installation, software version deployment) or the date the vulnerability was publicly disclosed for the software version you were running, whichever is earlier. Regulators expect you to use the broadest reasonable window, not the narrowest.

The attacker is threatening to publish or has already published the data. If an attacker is extorting you with a threat to release stolen data, paying the ransom does not satisfy your regulatory obligations and does not guarantee the data will not be released. Assess RROSH based on the fact that the data is in a malicious actor's possession, not based on whether they follow through on their threat. Notify regulators and affected individuals regardless of whether you pay. Involve legal counsel before making any payment.

A card-skimming script was injected into your checkout page (Magecart attack). This is a distinct sub-scenario: rather than extracting a database dump, the attacker injects JavaScript that captures payment card data in real time as customers enter it. RROSH is almost certainly present — payment card data was captured by a malicious actor for every customer who checked out during the skimmer's active period. This also triggers PCI-DSS obligations, which are separate from PIPEDA and PIPA. Contact your payment processor immediately.

Your site runs on a shared hosting environment and the host was breached. If your hosting provider was compromised and your site's data was affected as a result, this is a vendor breach scenario in addition to a web compromise. You remain the accountable party under PIPEDA and PIPA. Assess RROSH based on what your site's database contained and notify accordingly. Your contractual relationship with the hosting provider is a separate matter. See Vendor or Third-Party Breach: What Canadian Organizations Must Do.

Your database credentials appeared in the attacker's dump but you cannot confirm what was accessed. If an attacker posts your database credentials (username/password) in a dump, they had the means to access your database whether or not they ran specific queries. Treat this as potential access to every table those credentials could reach. Rotate all affected credentials immediately and assess RROSH on the basis of what the database contained.

---

Documents you will need

Regardless of RROSH determination:

• Internal breach record: date discovered, estimated intrusion start date, vulnerability exploited, scope of database access, personal information categories affected, number of individuals, RROSH assessment and outcome, remediation steps
• Web server logs and database query logs for the dwell period (preserved before remediation)
• Forensic summary from your investigation (internal or third-party)

If RROSH is determined, also:

• OPC breach report (PIPEDA)
• OIPC Alberta breach notification (AB PIPA) — if Alberta individuals affected; email breachnotice@oipc.ab.ca
• OIPC BC breach notification (BC PIPA) — if BC individuals affected; submit through OIPC BC's process at oipc.bc.ca
• Individual notification letters — one per affected individual or one per household

ClearBreach generates the regulator reports and individual notification letters automatically from your assessment answers.

---

Common mistakes in this scenario

Restoring from backup before preserving evidence. The instinct to restore quickly and get back online is understandable — but restoring before capturing logs and the compromised system state destroys the evidence your RROSH assessment depends on. Preserve first, restore second.

Waiting for forensics to complete before notifying. A full forensic investigation of a web compromise can take weeks. Regulators expect notification as soon as RROSH is determined — not when forensics closes. File your breach report on available information and update as your investigation continues. Supplementing a timely report is always better than a complete report filed months late.

Scoping the breach based only on confirmed queries in logs. If logs show an attacker executed specific queries, those queries define a confirmed minimum scope. But incomplete logging, log gaps, or log tampering by the attacker means confirmed queries may understate actual access. Scope your RROSH assessment based on what the attacker could have accessed from the entry point, not only what your logs can confirm.

Assuming a hashed password database does not trigger RROSH. Hashed passwords are not plaintext passwords — but they are not safe either. MD5 and SHA-1 hashed passwords are crackable. Even bcrypt-hashed passwords are at risk if passwords are weak. A database dump of email addresses and hashed passwords in an attacker's hands enables credential stuffing attacks against every other site where those individuals use the same email and password. This is real harm, not theoretical harm.

Treating a plugin update as the end of the incident. Patching the exploited vulnerability closes the door — but it does not address what happened while the door was open. Update the plugin and then complete your RROSH assessment for the dwell period. Both are required.

Not rotating credentials after a server compromise. If an attacker had access to your server, they potentially had access to every credential stored on it: database passwords in configuration files, API keys in environment files, admin panel passwords. Failing to rotate all of these creates ongoing risk even after remediation.

---

MSP note

If you manage web infrastructure or databases for clients and this compromise occurred in a client's environment you administer:

Notify the client immediately with full technical details: what vulnerability was exploited, what the attacker accessed, what the dwell period appears to be, and what remediation steps you have taken or are taking. The client organization is the accountable party under PIPEDA and PIPA for their individuals' personal information.

If the compromise resulted from a vulnerability in software you deployed and managed, your contractual liability to the client is a separate matter from the client's regulatory obligations. Both run concurrently.

If your own infrastructure was the entry point — a compromised managed service or shared platform you operate for multiple clients — you may be the vendor for multiple concurrent breaches across your client base. Each affected client organization needs to be notified separately and will conduct their own RROSH assessment. Run a ClearBreach assessment for each affected client under your MSP account and document each separately.

---

Ready to assess this breach? ClearBreach walks you through your website or database compromise scenario, applies PIPEDA, Alberta PIPA, and BC PIPA simultaneously, and generates your assessment verdict, regulator reports, and individual notification letters automatically — in under 15 minutes. Start your assessment →

---

This playbook covers PIPEDA, Alberta PIPA, and BC PIPA obligations for private-sector organizations. If your organization handles personal health information under provincial health legislation — such as Alberta's Health Information Act or BC's E-Health (Personal Health Information Access and Protection of Privacy) Act — additional obligations may apply when a database containing health information is compromised. Those obligations are not covered here. A Magecart or card-skimming attack also triggers PCI-DSS obligations, which are separate from PIPEDA and PIPA and are not covered here.

---

Related guides

• PIPEDA Breach Reporting Requirements — when and how to notify the OPC under PIPEDA
• Alberta PIPA Breach Notification — AB PIPA notification obligations and OIPC process
• BC PIPA Breach Reporting — BC PIPA notification obligations and OIPC BC process
• What Is RROSH? — the real risk of significant harm standard explained
• Vendor or Third-Party Breach: What Canadian Organizations Must Do — if the breach occurred at your hosting provider or a third-party platform
• Website or Database Compromise — Quick Reference — checklist for use during the incident