PIPEDAAB PIPABC PIPAManaged service providers

A Breach at a Client: Who Notifies Whom

By Yong DuPublished September 5, 2026Reviewed September 26, 2026

When a breach happens at a managed client, the reporting duty is the client's. What the provider owes, to whom, and in what order.

On this page

The duty does not move

When a breach touches a managed client's personal information, the obligation to assess it and report it belongs to the client. PIPEDA s.10.1(1) places the duty on the organization; Alberta PIPA s.34.1(1) does the same. Neither has a provision that lets a service provider assume it.

BC PIPA has no mandatory breach-notification trigger for private-sector organizations at all, which is worth knowing before an incident rather than during one: a breach that is mandatory federally and in Alberta comes back as recommended in British Columbia on the same facts.

So the chain runs: you tell the client, the client determines, the client reports. Your job is to make the middle step possible.

What an assessment finds

The compliance assessment asks every organization the same questions, across 10 areas. In a real one, 14 gaps came back. This was one of them:

Do you keep a record of every privacy incident, including the ones you decided not to report?

critical · answered “no”

The provision: PIPEDA s.10.3(1), a record of EVERY breach · s.10.3(2), produced to the Commissioner on request · SOR/2018-64 s.6, kept 24 months

What closes it: Keep a record of every incident, including the ones you decided not to report. PIPEDA s.10.3(1) says "every breach of security safeguards", and the ones you assessed and let go are the half people miss. SOR/2018-64 s.6 requires the records to be kept 24 months, and s.10.3(2) lets the Commissioner ask to see them.

From an assessment of ACME Dental, a fictional Alberta clinic. The question, the finding and the provision are what the engine produced, not an illustration written for this page.

Walk one yourself: the same screens a subscriber answers, on a fictional Alberta clinic, ending in the findings and the documents it produces. No account, nothing to install.

What the provider actually owes

Notification to the client, promptly and completely. They cannot begin to determine anything until they know. "Complete" means what happened, when, what information was reachable, what you have and have not established, and what you have done.

The facts as they are, including the ones you do not have. The most useful sentence in an early notification is often "we cannot yet establish whether the data was accessed". Regulators treat uncertainty as the worse case, and so should the client's assessment. A provider who reports only what is confirmed pushes the client toward a determination on incomplete facts.

Whatever the client needs to assess. Access logs, the date the exposure began and ended, the scope of what was reachable. If you cannot say which records were touched, say that: it is an input to the assessment, not a gap in it.

Your own assessment, if your own information was involved. See below.

When the breach is on your systems

This is where it gets misread. If an incident on your infrastructure exposes a client's customer data, there are two organizations with obligations and two assessments:

The client is accountable for their customers' personal information. They assess, and they report if the threshold is met.
You are accountable for your own, staff records, your own client contact details, anything of yours in the same system. You assess that separately.

The same incident, two accountable organizations. Not double counting: the personal information belongs to different people and different organizations answer for it.

A provider managing several affected clients has one incident and several client assessments, each on its own facts. Two clients hit by the same intrusion can land on different answers, because the answer depends on what each of them held.

The order that works

Contain, and do not destroy the evidence of what happened.
Tell every affected client, with what you know and what you do not.
Establish scope per client, because each of them is assessing their own facts.
Support each assessment with logs and dates.
Assess your own exposure as an organization in your own right.
Record it, on both sides. PIPEDA s.10.3(1) requires a record of every breach of security safeguards, including the ones assessed and found not reportable.

Step six is the one that gets dropped when the answer is "not reportable", and it is a duty regardless of the outcome.

Common mistakes

Reporting to the regulator on the client's behalf. It does not discharge their duty, and it muddies the record of who determined what and when.

Waiting for a complete forensic picture before telling the client. The client's clock runs on their determination, and they cannot start. Tell them early and supplement.

Telling only the clients you are certain were affected. If you cannot establish scope, that uncertainty belongs to the client too.

Forgetting your own assessment. A provider whose staff records were in the same system is an affected organization, not just a supplier to affected organizations.

Assuming one answer covers every client. Different provinces, different Acts, different information. The assessment is per organization.

Onboarding a client: the privacy questions worth asking in week one
Offboarding a client: what happens to their privacy records
Answering a client security questionnaire
All four guides for managed service providers
How the ClearBreach MSP account works, including assessing a breach on a client's file as that client

Frequently asked questions

If a breach happens at a client, does the MSP report it to the regulator?

No. The reporting duty belongs to the organization accountable for the personal information, which is the client. PIPEDA s.10.1(1) places the obligation on the organization, and Alberta PIPA s.34.1(1) does the same. A provider reporting on a client's behalf does not discharge the client's duty and can confuse the record of who determined what. What the provider owes is prompt, complete notification to the client so the client can decide.

What if the breach happened on the MSP's own systems?

Then there are two organizations with obligations. The client is still accountable for their customers' personal information and assesses the breach on that basis. The provider is accountable for its own personal information, staff records, its own client contact data, and assesses separately. The same incident produces two assessments because there are two accountable organizations, not because it is being counted twice.

How fast does an MSP have to tell a client about a breach?

Fast enough that the client can meet their own deadline, which is the only measure that matters. PIPEDA requires reporting as soon as feasible after the organization determines a real risk of significant harm exists, and the client cannot start determining anything until you tell them. A contractual notification window measured in hours is normal for exactly this reason.

Do we have to tell a client about a breach that does not affect them?

If their information was not involved, they are not an affected organization and there is nothing for them to assess. If you cannot yet establish which clients were affected, treat that as unresolved rather than as a no. Regulators do not accept an absence of evidence as evidence of absence, and neither should a client.

This guide is educational and does not constitute legal advice. It is grounded in the text of PIPEDA, Alberta PIPA, and BC PIPA and published guidance from the OPC, OIPC Alberta, and OIPC BC. If your situation involves regulatory investigation, litigation risk, or circumstances not addressed here, engage a qualified privacy lawyer.

See what a compliance assessment finds

A real assessment for a small clinic: every area scored, every gap against the provision behind it, and the documents that close them.

See a complete assessment →

Get early access →