Updated September 25, 2026: every legal and factual statement in this article was re-checked against the primary source and corrected where needed.
Here's a question worth asking about the system you're about to launch: when does it delete anything?
In short: a system that reaches launch without an approved, enforced retention schedule for the personal information it collects defaults to keeping everything indefinitely. Retention has to be a design input decided before launch — records series identified, a period and disposal authority documented, and the system built to actually execute disposal — not a records-management task deferred to after go-live.
Not "what does the policy say?" Not "what did the records team recommend two years ago?" What does the system actually do, on its own, without a person remembering to do it?
For some systems the honest answer is: nothing. It keeps everything. Forever. Not because anyone decided that — because nobody decided anything, and forever is what you get by default.
What the gap looks like
A system can reach, or pass, its launch date with no approved retention schedule for the personal information it holds. The shape varies. Sometimes the records series was never identified, so there's nothing to apply. Sometimes the required records-management documentation is started but incomplete, sitting with someone who has eleven other things in flight. Sometimes — and this is the one that fools people — a retention schedule exists, properly approved, sitting in a binder, and nothing in the platform enforces a single line of it.
That last case is the dangerous one, because it looks like compliance. There's a document. Someone signed it. You can produce it if you're asked. But the database is still holding every record it has ever held, and will keep holding them until someone runs a query nobody has written yet.
A schedule the platform doesn't execute isn't a control. It's a description of a control you meant to build.
Why it happens
This isn't a discipline problem. The people involved are competent and busy, and the failure is structural.
Retention gets classified as a records-management task. Records management is a back-office function. Back-office functions get sequenced after the thing that has a launch date. So retention lands in the post-go-live pile — and the post-go-live pile is where work goes to be reprioritized.
Underneath that is an ownership gap. Your delivery team owns the build. Your records or information-management function owns the schedule. Nobody owns the join between them. Each group can complete its own work perfectly and still leave you with a live system retaining personal information indefinitely, because the handoff between them was never anyone's deliverable.
Shared platforms make this worse in a specific way. Programs onboarding to a shared platform can assume the platform's generic schedule covers their records. It may not. Generic schedules are written for the platform's own operational data, not for whatever your program collects on top of it — and the gap between those two things is exactly where personal information accumulates unnoticed.
The fix, and the bar
Move retention upstream. It's a design input, not a launch follow-up.
Concretely, four things:
- Bring records and information management in during design. Not for sign-off at the end — into the room while the data model is still changeable. The cost of adding a disposal path to a design is small. The cost of adding one to a production system holding live records is not.
- Identify the applicable records series for every category of personal information you collect. Every category. If no series fits, that's not a reason to skip it — that's a finding, and the answer is to create one.
- Document the retention period and the disposal authority for each. How long, and on whose authority. A period without an authority is a preference. An authority without a period is a policy nobody can action.
- Make the system execute it. Automated disposition — purge, hard delete or, where the law allows it, anonymization, on schedule — with a hold check so nothing under an open access request or a legal hold is destroyed, and verified in testing before production. Not verified by reading the configuration. Verified by putting a record in, moving the clock, and confirming the record is gone.
That fourth point is the whole thing. It's the difference between a retention schedule and retention.
Run this on your own system this week
You don't need an assessment to find out where you stand. Three questions, and you can answer all of them before Friday.
One: what's the oldest record in production, and should it still be there? Query it. Don't ask, query. Do not be surprised if it is older than the system's own stated retention period, or older than the program.
Two: name the job that deletes things. Not the policy — the scheduled job, the stored procedure, the lifecycle rule. If nobody can point to it in under a minute, it doesn't exist. If someone says "we'd handle that manually," you've found a control that depends on a person remembering, which is not a control.
Three: for each category of personal information, what's the disposal authority? If the answer for any category is a shrug, that category is on indefinite retention right now, whatever the binder says.
Anything that fails those three questions is a finding you can close on your own terms, quietly, before a regulator, an access request, or a breach turns it into someone else's finding on their timeline.
Why this one is worth your attention
Retention gaps are unusual among privacy problems in that they compound. A missing privacy notice is bad the day you find it and no worse a year later. Indefinite retention gets worse every single day the system runs, because the volume of personal information you're holding without authority — and the size of the breach you'd have to report — grows on its own while you're thinking about something else.
It's also among the cheapest things to fix early and among the most expensive to fix late. Building disposal into a design costs a conversation. Retrofitting disposal into a production system means data migration, legal review of what can be destroyed, and a defensible record of what was destroyed and why — with real records already in scope while you work it out.
Canadian privacy law comes at retention from two directions. PIPEDA and Quebec set a ceiling: under PIPEDA, personal information should be kept only as long as its purposes require, then destroyed, erased or made anonymous; Quebec requires destruction or anonymization once the purpose is achieved, in both the private and public sectors, subject to any preservation period set by law. The federal Privacy Act and Ontario's public-sector statutes set a floor instead, so people have time to ask for their records: at least two years after last use for federal institutions, at least one year for Ontario's provincial institutions. Those statutes then require disposal to follow prescribed rules rather than anyone's preference. What differs is the paperwork. What doesn't differ is that "we kept it because deleting it was never anyone's job" is not a defence under any of them.
Mosaic builds retention into privacy assessments as a launch dependency rather than a closing recommendation, using a proprietary, standardized methodology. Our reviews are expert-led throughout — the finding, the disposal design, and the verification standard come from people who have had to defend them.