Retention policies are usually well written. They specify categories, periods and justifications, and they are approved by people qualified to approve them.
Then you query the database and find records from nine years ago in a category with a three-year period. Nobody ignored the policy. The policy simply had no mechanism.
Why manual deletion never happens
It is nobody’s job, it is irreversible, and it is unrewarded. Given a choice between deleting production data and almost any other task, a sensible engineer picks the other task — and they are right to, because getting it wrong is a serious incident and getting it right is invisible.
So it drifts, and the organisation carries a growing amount of data it has committed in writing to have destroyed. That gap is worse than having no policy, because the policy is now evidence of what you knew you should be doing.
Retention as code
The rule has to live where the data lives:
- A retention period attached to each category, in the schema, not in a document.
- A scheduled process that enforces it without human initiation.
- A log of what it deleted and when, which is often the only evidence you will have that the policy was honoured.
- Alerting when it does not run. A deletion job that has silently failed for four months looks exactly like a compliant system.
The details that make it hard
Deletion versus anonymisation. Often the record is needed for aggregate reporting but the identity is not. Stripping identifiers is usually the right answer and needs to be genuinely irreversible — a pseudonym you hold the key for is still personal data.
Cascades. Deleting a person leaves their attendance rows, uploaded files, messages and audit entries. Some must go, some must stay, and some contain their name in free text.
Backups. Restoring a backup reinstates deleted records. Either the restore path re-applies retention, or your backup window is effectively your retention period.
Legal hold. Anything under investigation or dispute must survive the schedule, which means the rule needs an override — and that override needs an expiry, or it becomes permanent by neglect.
Free text. Personal information in a notes field is not deleted by dropping a column, and it is the hardest category to find.
Where the clock starts
The most common design error is running retention from record creation. Usually the period should start from an event — the end of a membership, closure of a case, a last interaction — which means the system has to know that event happened.
If nothing marks an account as inactive, nothing can ever expire, and the schedule is theoretical no matter how carefully it was written.
The check
Pick a category with a defined period. Query for records older than it.
If any come back, the number is the size of the gap between the policy and the system — and it only grows while the mechanism is missing.
If your retention policy is a document rather than a job, get in touch, or read about our health and life sciences work.