Vendor or Third-Party Breach — What Canadian Organizations Must Do

Which laws apply

Jurisdiction	Applies when	Regulator
PIPEDA	The vendor processed personal information in the course of your commercial activity; or the breach involves personal information about individuals 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 was held by the vendor on your behalf	OIPC Alberta — oipc.ab.ca / breachnotice@oipc.ab.ca
BC PIPA	Personal information about BC residents was held by the vendor on your behalf	OIPC BC — oipc.bc.ca

For most vendor breaches, 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

In every other breach scenario, the organization knows what happened on its own systems. In a vendor or third-party breach, a supplier — your IT managed service provider, a SaaS platform, a payroll processor, a cloud storage provider, a bookkeeping service — has experienced a breach on its systems, and your data was caught in it.

The defining feature is dependence: you are relying on someone else to tell you what happened, what data was affected, and what they are doing about it. That dependence creates pressure to wait, defer, and assume the vendor will handle it. Waiting is the most common and most costly mistake in this scenario.

Your PIPEDA accountability did not transfer when the data did. Under PIPEDA Principle 1, Alberta PIPA s.5, and BC PIPA s.5, you remain the accountable organization for personal information you transferred to a third party for processing — regardless of what your contract with that vendor says. If the data was exposed and RROSH is present, your notification obligation runs to the regulator and to the affected individuals. The vendor's own breach notification does not satisfy yours.

---

Immediate steps — this scenario specifically

1. Confirm what personal information you transferred to the vendor. Before you can assess RROSH, you need to know what was at risk. Pull your data-sharing inventory for this vendor. If you do not have one, reconstruct it from contracts, onboarding records, and operational practices. What categories of personal information did this vendor receive? Whose information — customers, employees, patients, clients?

2. Get written confirmation of the breach scope from the vendor. Contact the vendor immediately and request written confirmation of: what systems were affected, what data categories were involved, whether your organization's data was confirmed accessed or only potentially at risk, and the timeline of the breach and their response. Do not accept a verbal summary — document everything in writing from this point forward.

3. Check your contract and DPA. Your contract or Data Processing Agreement may require the vendor to notify you within a specific timeframe, provide breach details in a defined format, and assist with your regulatory response. Identify those obligations and determine whether the vendor has met them. If they have not, put them on notice in writing.

4. Do not issue a public statement or notify individuals yet. Premature notification before you know what was affected creates confusion and may be inaccurate. Complete your RROSH assessment first. Notification comes after assessment, not before.

---

What drives RROSH in this scenario

RROSH — real risk of significant harm — is assessed based on what the vendor actually held on your behalf and whether the breach created meaningful exposure for the individuals whose information it was.

Factors that push toward RROSH:

• The vendor held sensitive categories of information: health data, financial records, SINs, passwords, government-issued ID numbers, or information about minors
• The breach involved confirmed unauthorized access, not just a system vulnerability
• The vendor held a combination of information types that together enable identity theft or fraud (name + SIN + date of birth is more dangerous than any single field)
• The individuals at risk are vulnerable — patients, employees, clients with high-value financial information
• The vendor is an IT managed service provider who held credentials or system access beyond just data files — compromised credentials may give attackers access to your own systems

Factors that push against RROSH:

• The vendor held only basic contact information (name and email) with no financial, health, or identity-enabling data
• The vendor confirmed the breach was limited to systems that did not contain your organization's data
• The breach involved an encrypted dataset and the encryption key was not compromised
• The vendor held aggregated or anonymized data with no individual identifiers

The combination effect: The vendor often holds more than one type of information. An HR platform may hold employee names, addresses, SINs, banking details for direct deposit, and emergency contact information. Each field individually may seem low-risk; the combination creates significant RROSH.

---

Likely verdict range

Vendor type and data held	Typical verdict
IT MSP with access to systems containing customer records, employee data, or financial files	RROSH — access to systems is access to data
Payroll processor holding employee SINs, banking details, salary information	RROSH — combination of SIN + financial data is high-risk by definition
SaaS CRM holding customer name, email, and phone number only	Case-by-case — depends on volume and whether additional context was stored
Cloud storage holding encrypted files where key was not compromised	Likely BELOW_RROSH — but confirm encryption scope
Bookkeeping platform holding client financial records and SINs	RROSH — financial data + SINs
Email marketing platform holding name and email only	Likely BELOW_RROSH for most scenarios — but assess volume and targeting risk

---

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. Do not wait for the vendor to report on your behalf.
• OIPC Alberta notification (AB PIPA): Notify the OIPC Alberta without unreasonable delay.
• OIPC BC notification (BC PIPA): Notify the OIPC BC as soon as reasonably possible.
• Individual notification: Notify each affected individual directly. The notification must describe what happened, what information was involved, what ClearBreach or the vendor is doing, and what the individual can do to protect themselves.

If RROSH is not determined:

• No regulator notification required under PIPEDA or Alberta PIPA.
• No individual notification required.
• Internal breach record required — document your assessment and your reasoning.
• Consider whether the vendor relationship needs to be reviewed or additional safeguards added.

BC PIPA — voluntary reporting option. Under BC PIPA, organizations may voluntarily report a breach to the OIPC BC even where RROSH is not present. For vendor breaches involving BC residents where RROSH is borderline, voluntary reporting demonstrates good faith and reduces 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:

The vendor notifies regulators — does that satisfy your obligation? No. The vendor may report under their own PIPEDA or PIPA obligations as an organization that experienced a breach. That notification covers the vendor's accountability. Your notification covers yours. If RROSH is present, both of you notify — the vendor for the breach on their systems, you for the breach of personal information you were accountable for.

The vendor is not a Canadian organization. PIPEDA and PIPA do not limit your accountability to Canadian vendors. If you transferred personal information to a US-based SaaS platform or payroll processor and that platform was breached, your Canadian obligations still apply. The vendor's compliance with US breach notification laws does not satisfy your Canadian obligations.

You cannot reach the vendor or the vendor has gone out of business. Proceed with your RROSH assessment based on what you know. The vendor's unavailability does not pause your obligations. Document your attempts to contact the vendor and assess based on the last known scope of data sharing.

The breach is a supply chain breach — your vendor's vendor was breached. Your accountability extends to the data regardless of how many layers of subprocessing were involved. Assess RROSH based on what personal information ultimately reached the affected systems, even if you did not have a direct relationship with the breached entity.

---

Documents you will need

Regardless of RROSH determination:

• Internal breach record: date discovered, vendor involved, data categories affected, number of individuals, RROSH assessment and outcome, actions taken
• Written correspondence with the vendor documenting what they disclosed and when

If RROSH is determined, also:

• OPC breach report (PIPEDA)
• OIPC Alberta breach report (AB PIPA) — if Alberta individuals affected; email breachnotice@oipc.ab.ca
• OIPC BC breach report (BC PIPA) — if BC individuals affected; submit through OIPC BC's breach notification process
• 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

Waiting for the vendor to report on your behalf. The vendor's notification to regulators covers their accountability, not yours. If RROSH is present, you notify independently. Regulators have received complaints from individuals who were never notified because both the vendor and the client organization each assumed the other had handled it.

Treating a DPA as a liability shield. A DPA that requires the vendor to notify you promptly and assist with your response is a contractual tool. It does not remove your statutory accountability to the individuals whose data was exposed. If the vendor breaches the DPA, you have a contract claim against them — you still have a regulatory obligation to the affected individuals.

Not knowing what data you shared. Many organizations cannot answer the question "what personal information does this vendor hold on our behalf?" within the first 24 hours of a breach notification. The RROSH assessment cannot proceed without that answer. Maintaining a vendor data inventory is not optional — it is the precondition for meeting your breach response obligations.

Assuming encrypted data is safe. Encryption at rest protects data if the encryption key was not compromised. If the breach involved access to both the data and the keys — or if the vendor cannot confirm whether the keys were affected — treat the data as exposed.

Delaying notification while waiting for the vendor's forensics report. Vendor forensics investigations can take months. Organizations routinely tell affected individuals nothing until the report is complete — then discover the OPC expected notification within days of the RROSH determination. If new material information emerges after you notify, send a follow-up. The initial notification must go out when RROSH is determined, not when the vendor finishes their investigation.

---

MSP note

If you are an MSP managing this response on behalf of a client:

The client organization remains the accountable party under PIPEDA, AB PIPA, and BC PIPA. Your role is to assist the client in identifying what data was affected, conducting the RROSH assessment, and fulfilling their notification obligations — not to absorb their accountability.

If your own systems were the ones breached — you are the vendor in this scenario — you have your own separate notification obligations as a data processor that experienced a breach, in addition to your contractual obligations to notify your clients promptly. Both run concurrently.

Document the separation clearly: what you are doing as the client's agent and what you are doing as the breached party. Regulators expect clarity on which organization is making which notification.

---

Ready to assess this breach? ClearBreach walks you through your vendor breach 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 vendor holding that information is breached. Those obligations 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 / Third-Party Breach — Quick Reference — checklist for use during the incident