I85PREP
⌘ K
DPO study materials
DPO study resources

The Retention Clock Nobody Reset

DPO · Put your knowledge to work in context.

All case studies

The Retention Clock Nobody Reset

A mid-sized insurer's marketing team built a lead-capture form that writes prospects into a CRM. The privacy notice says prospect data is deleted 12 months after last contact. The CRM's deletion job was configured against a last_activity field, but a 2023 migration began populating a new last_touch field while leaving last_activity frozen at migration time. Since then, roughly 340,000 prospect records have last_activity older than 12 months, while 210,000 of those have last_touch within the last 90 days. The deletion job runs nightly and has been deleting on last_activity. A sales director flags that "recent leads are vanishing." Meanwhile, the DPO finds 130,000 records where both fields are older than 12 months and which were never deleted because they were flagged do_not_delete during a legal hold that ended eight months ago. The hold-lift script never cleared the flag.

1. Classify the three populations (A: recent `last_touch`, stale `last_activity`; B: both stale, flag still set; C: any other records) by whether the current deletion behavior is over- or under-retaining, and state the correct action for each.

Read the worked answer

Population A (~210k, recent last_touch, stale last_activity): The policy clock is "last contact." last_touch is the true contact signal, so these records are within retention. Deleting them is over-deletion - a data-loss and business-continuity problem, and arguably a breach of the notice's own promise (you told people you keep data for 12 months after contact; deleting early isn't a privacy win, it's an accuracy failure). Action: pause the deletion job, then correct the field mapping and backfill last_activity from last_touch before re-enabling.

Population B (~130k, both stale, flag still set): The legal hold ended eight months ago; there is no lawful basis to keep these. The stale flag is causing under-retention - the actual privacy risk. Action: clear the do_not_delete flag for records whose hold has lifted, confirm with legal that no successor hold applies, and delete on the next cycle.

Population C: Records where last_activity is stale and last_touch is also stale but no flag - these are being correctly deleted. No action beyond verification.

The key judgement: the same bug (field drift) produces opposite harms in different populations, and the fix must be sequenced - stop the harmful deletion first, then remediate under-retention.

2. The deletion job is currently live and running nightly. What is the correct order of operations, and why does order matter here?

Read the worked answer

Order matters because the two errors have asymmetric reversibility. Over-deletion is irreversible; under-retention is a continuing but remediable exposure.

  1. Suspend the nightly job immediately. Every night it runs, it destroys Population A records that should be retained. You cannot un-delete them.
  2. Snapshot / quarantine the current deletion queue so you have an audit trail of what was deleted and when (needed for any notification or regulator conversation).
  3. Fix the field mapping and backfill last_activity from last_touch for Population A - this restores the clock to the policy definition.
  4. Clear stale legal-hold flags for Population B after legal sign-off.
  5. Re-enable the job with a dry-run/diff report for the first cycle, so you can see exactly what will be deleted before it is.
  6. Add a reconciliation check (row counts by retention bucket) to catch field drift early.

If you instead fixed the flag first and left the job running, you would delete Population B correctly but keep destroying Population A - the worst of both. Suspend first, remediate second, resume with verification.

3. A regulator asks for evidence of your retention controls. What does the field-drift incident tell you about the adequacy of a "the job runs nightly" control, and what would you document as the remediation?

Read the worked answer

"The job runs nightly" is an activity, not a control. A control must have a defined expected outcome and a way to detect deviation. Here the job ran reliably - and did the wrong thing reliably for months. That is the classic failure mode: monitoring execution rather than correctness.

What to document:

  • Root cause: schema migration introduced last_touch without updating the deletion job's field reference; no post-migration validation of retention logic.
  • Detection gap: no reconciliation between "records that should have been deleted" and "records deleted." Population B sat eight months past hold-lift undetected.
  • Impact assessment: ~210k records over-deleted (business/accuracy harm), ~130k under-retained (privacy harm), with dates.
  • Corrective actions: field mapping fixed and backfilled; hold-lift script now clears flags automatically; deletion job converted to dry-run-then-commit with a diff report; quarterly reconciliation of retention buckets against policy.
  • Preventive control: any schema change touching a retention field requires a retention-logic test in the change process.

The honest framing for the regulator: the control existed but measured the wrong thing. The remediation is not "we will run the job more often" - it is "we will verify the job deletes the right records."