Offboarding a Client: What Happens to Their Privacy Records
By Yong DuPublished Reviewed
When a managed services relationship ends, the client's compliance records are theirs. What to hand over, what to delete, and what to keep.
On this page
The records were never yours
A managed services provider holds a client's personal information as a service provider. Under PIPEDA the client remains the organization accountable for that information: Schedule 1 clause 4.1.3 makes an organization responsible for personal information transferred to a third party for processing, which is the clause your own client is measured against when they engage you. Accountability does not move. Neither does ownership of the compliance record.
That single fact settles most offboarding arguments before they start. The assessments, the generated documents, the record of any breach you assessed on their behalf: those describe the client's compliance position, and the client is the one who will be asked about it.
The four things to hand over
Every assessment they paid for, and the documents it produced. A privacy management programme is proved by artefacts. A client who cannot produce the roadmap, the incident response plan or the policies they commissioned cannot show a regulator that the programme existed, whatever they say about it.
The record of any breach you assessed. PIPEDA s.10.3(1) requires a record of every breach of security safeguards, including the ones assessed and found not reportable. If you ran that assessment for them, the record is theirs and they must be able to produce it on request under s.10.3(2).
Whatever you configured that carries privacy consequences. Retention settings, access rules, who was granted what. The incoming provider inherits decisions you made, and the client is accountable for them either way.
A written statement of what you still hold, and until when. This is the piece that gets skipped, and it is the one that protects both sides. See below.
What you keep, and why that is not a contradiction
Two duties pull in opposite directions at the end of a relationship.
PIPEDA Schedule 1 clause 4.5.3 requires personal information no longer needed for the identified purpose to be destroyed, erased or made anonymous. Alberta PIPA s.35(2) and BC PIPA s.35(2) both say the same thing in their own words: destroy it or render it non-identifying.
But PIPEDA s.10.3(1) requires a record of every breach of security safeguards, and SOR/2018-64 s.6 fixes that at 24 months. If you assessed a breach on a client's behalf during the relationship, the record of that assessment has a retention period that does not end when the contract does.
The resolution is not to choose one. It is to say plainly which records you are keeping, on what basis, and for how long, then to delete on that schedule rather than on the last day of the contract.
What this looks like in ClearBreach
The same tension is in the product, and it is worth naming because it shows the shape of a defensible answer rather than describing one.
A completed assessment is reduced after 24 months: the answers go and a verification record stays, holding what is needed to prove the assessment happened and nothing about what was in it. That record is deleted after five years. A cancelled account is removed after 24 months, and its verification records survive it, because a record that cannot say whose assessment it was is not evidence of anything.
Two consequences matter for an offboarding conversation. The client's own downloaded copies are unaffected, they are the client's, held by the client, on their own systems. And a client organization managed through a provider is not deleted when that provider leaves. The provider is the buyer; the client is the subject; the records are the client's.
Common mistakes
Deleting on the last day. It looks tidy and it destroys records the client may need, some of which have their own retention periods.
Handing over a login instead of the records. Access can be revoked, contracts lapse, and platforms change hands. The client needs the artefacts, not a seat.
Leaving the handover format to the termination. Agree it while the relationship is good. A departing client asking for "everything" and a provider asking "in what format" is a conversation nobody has time for in week one of a transition.
Forgetting the exports. The most common offboarding breach is not a system left open, it is a copy made for convenience during the transition and never deleted: a spreadsheet on a technician's laptop, an archive in a personal cloud folder. Those are yours to account for.
Related
Frequently asked questions
Who owns a client's compliance records when the MSP relationship ends?
The client. You held their personal information and their compliance records as a service provider acting on their behalf, not as the organization accountable for that information under PIPEDA. Accountability never transferred to you, so neither did ownership. On termination the client is entitled to the records that document their own compliance position, and you are expected to stop holding what you no longer need.
Can we delete a former client's data immediately when the contract ends?
Not always, and not without asking. Two things pull in opposite directions: PIPEDA Schedule 1 clause 4.5.3 requires information to be destroyed when it is no longer needed for the identified purpose, while PIPEDA s.10.3 requires a record of every breach of security safeguards to be kept for 24 months. If you assessed a breach for that client, the record of it has a retention period of its own. Hand over the client's own copies first, then delete on a stated schedule rather than on the last day.
What do we have to give a departing client?
Everything that documents their compliance position: assessments they paid for, the documents generated from them, and the record of any breach you assessed on their behalf. A client cannot demonstrate a privacy programme to a regulator using records they cannot reach. Agreeing the handover format before termination is easier than agreeing it during one.
Does offboarding a client trigger a privacy breach notification?
Only if information is exposed in the process, and offboarding is a common way for that to happen: a shared drive left open to a departed technician, an export emailed to a personal address, a backup that nobody deprovisioned. Those are breaches on their own facts and are assessed the same way any other is. The end of a contract is not itself a breach; the handover is where the risk sits.
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 →