Rules
Personal data lifecycle problems: overcollection, hidden reuse and weak deletion
Six personal data lifecycle problems, with the symptom to confirm, the check that finds the cause, and the repair that holds after the next release.
What to take away
- A privacy failure is a mismatch between purpose, data, behavior, promise, and control, not a broken setting.
- Confirm the symptom before you edit a notice or delete evidence.
- Repair the collection point or the data flow, never only the screen the user sees.
- Test replicas, exports, logs, vendors, and backups, because that is where deletion usually fails.
- Give every repair one owner and one completion test.
Privacy problems rarely arrive labeled. They surface as a settings bug, a support ticket, or a field nobody remembers adding. The six patterns below each need different evidence, and each has a repair that survives the next release.
Problem 1: Overcollection
Symptoms: a simple feature asks for contacts, precise location, date of birth, or identity documents. Optional fields block progress. Fields stay in the form long after the purpose ended.
Overcollection field audit
- Trace each field to purpose
- Test feature without the field
- Check software kits and logs
- Remove or make field optional
- Stop downstream events and copies
- Update schemas, tests, and notice
Check: trace each field to a purpose, a decision, a system, and a recipient. Test the feature without the field. Software kits and logs collect too, so look past the visible form.
Repair: remove the field or make it genuinely optional. Stop the downstream events, delete the unneeded copies, update schemas and tests, and revise the notice. Record why any retained field stays.
The FTC's Start with Security guide tells businesses not to collect personal information they do not need. It does not decide any product's legal basis or required fields.
Problem 2: Hidden reuse
Symptoms: delivery data turns up in marketing segmentation. Support messages train a model with no review. A new team treats an existing warehouse as a general-purpose source.
Is the new use compatible?
Compare original purpose, notice, choice, contract, and expectation
Continue with updated records
Stop use, narrow data, offer choice, separate system, or abandon
Check: set the original purpose, notice, choice, contract, and user expectation beside the new use. Name the new recipients, decisions, retention, and possible harms.
Repair: pause the incompatible use while it is reviewed. Then narrow the data, offer a real choice, separate the system, or abandon the reuse. Update the records after the behavior is settled, not before.
Problem 3: Excessive retention
Symptoms: records have no disposal trigger. Former users sit in active marketing tables. Logs and support attachments outlive their operational value. "Legal" appears as a permanent reason with no named duty.
Retention review checklist
- Group records by purpose and system
- Find last valid event and legal need
- Check dispute period and backup cycle
- Sample old data to see what remains
- Set trigger, period, action, owner, exception
- Cover stores, logs, archives, vendors, paper, backups
Check: group records by purpose and system. Find the last valid event, the statutory or contractual need, the dispute period, the backup cycle, and any legal hold. Sample old data to see what is actually there.
The ICO's guidance on storage limitation says to review whether data is still needed and to erase or anonymize it when it is not. It also separates deletion from taking data offline. Apply it where the UK regime applies, with fact-specific advice.
Repair: set a trigger, a period, an action, and an owner. Also set an exception route and a test. Cover active stores, logs, archives, and vendors. Also cover paper and backup expiry. Never erase records under a valid hold.
Problem 4: Weak deletion
Symptoms: a deleted profile stays public, searchable, or reachable by an old link. The live row disappears while files, analytics events, and vendor copies live on. Support cannot explain the schedule.
Deletion trace workflow
- Submit controlled deletion in test account
- Trace identifiers through primary stores
- Check replicas, search indexes, object storage
- Check queues, vendors, and backups
- Confirm financial or abuse records separated
- Build orchestrated workflow with retries and alerts
Check: run a controlled deletion in a test account. Trace the identifiers through primary stores, replicas, search indexes, and object storage. Then trace them through queues, vendors, and backups. Confirm that financial or abuse records are separated on purpose.
Repair: build one deletion workflow with retries, failure alerts, provider instructions, and completion evidence. Describe backup expiry honestly. Deactivation is not deletion.
Problem 5: Shadow profiles
Symptoms: someone who never registered can be found through contact uploads. Identifiers join into a profile with no visible account. Deleted users reappear after the next import.
Check: identify the uploaders, matching keys, identity graphs, and suppression lists. Also identify invitations, advertising audiences, and inferred fields. Establish what the affected person can see, contest, or remove.
Repair: minimize imports, give uploaders clear duties and affected people real controls, separate invitation delivery from persistent profiling, limit matching, and keep only the narrow suppression value that prevents re-creation.
Problem 6: Unclear accountability
Symptoms: product assumes security owns retention. Security assumes legal approved the purpose. Legal relies on a notice engineering never checked. Vendor management has no owner after launch.
Check: ask who can approve collection, change a purpose, add a recipient, or grant privileged access. Also ask who can answer a request, suspend deletion, or close an incident. A committee is not an answer unless one named person can act.
Repair: assign decision rights, operational owners, escalation, review dates, and evidence. Tie privacy gates to product and vendor change processes. Give leaders a short list of unresolved risks with due dates.
Verify the repair
| Evidence | What it proves |
|---|---|
| Original symptom and affected scope | The problem was real and bounded |
| Containment and root cause | The flow, not the screen, was fixed |
| Code or configuration change | The fix ships with the release |
| Data cleanup across stores and vendors | Copies are gone, not hidden |
| Notice or contract update | The promise matches the behavior |
| Test result, owner, closure date | Someone is accountable for it holding |
Recheck after the next deployment and after the next scheduled deletion cycle.
Common questions
Should we update the privacy notice first?
Usually the behavior and the legal decision come first. A notice describes the approved practice; it cannot legitimize an unauthorized one. Ask the Office of the Privacy Commissioner, your provincial commissioner, or a licensed lawyer where the answer depends on jurisdiction.
Is offline data deleted?
No. Reduced availability lowers some risk, but retained offline data still exists and still needs a purpose, protection, a retention period, and request handling.
Can a suppression list be kept after deletion?
Sometimes a narrowly scoped value prevents re-enrollment or repeated marketing. Its purpose, fields, access, period, and legal basis still need review. No opt-out guarantees the record stays gone.
What proves a deletion fix works?
A traced test across live stores, replicas, indexes, and vendors. It also covers scheduled backup expiry. Plus alerts for failed steps. Outcomes depend on the controller, the jurisdiction, and the verification process.
