Data retention and deletion: the schedule nobody enforces

Storage is cheap, so almost nobody deletes anything. The cost is not storage - it is that every record you keep past its usefulness is something that can be breached, subpoenaed, or found by a regulator asking why you still hold it. Retention is one of the few controls that reduces risk by removing things rather than adding them.

Why data you do not need is a liability

• Breach scope. The size of an incident is determined by what you were holding at the time. Seven years of customer records makes a materially worse disclosure than two.
• Legal discovery. Retained material is discoverable - including a decade of internal messages nobody has read since.
• Privacy law. GDPR's storage limitation principle, the Saudi PDPL and comparable regimes require personal data to be kept no longer than necessary. Indefinite retention is not a neutral choice; it is a violation.
• Subject rights. Erasure and access requests are far harder to answer when you do not know where data lives or how old it is.
• Cost. Secondary, but real, once backups and replicas are counted.

Building a schedule that can execute

Retention schedules fail when they are written by legal, filed, and never handed to anyone who could implement them. A workable one:

1. Start from data categories, not systems. Customer records, employee records, financial transactions, security logs, marketing contacts, contracts, CCTV. Systems change; categories persist.
2. For each, find the obligations. Tax and accounting rules commonly require years of retention. Employment law sets its own periods. Sector regulators add more. Contracts may impose their own.
3. Set the period to the longest binding requirement, then stop. "We might want it someday" is not a retention justification, and under privacy law it is an argument against you.
4. Define the trigger precisely. "Seven years" from what - creation, last transaction, or end of relationship? Ambiguity here is why schedules never get implemented.
5. Name an owner per category.
6. Specify the disposal method - deletion, secure erasure, or anonymisation, which is often the better answer for analytics data.

Where obligations genuinely conflict - a tax requirement to keep seven years against a privacy requirement to minimise - the usual resolution is to retain the narrow subset the law demands and delete the rest, rather than retaining the whole record. That distinction is worth documenting; it is exactly what a regulator will ask about.

The places deletion does not reach

Deleting from the production database is the easy part. The copies are the problem:

• Backups. Deleted records persist in backups until those expire. The accepted approach is to document that backups are not routinely searched for deletion, that they age out on a defined schedule, and that restored data has the deletion re-applied. Attempting surgical deletion inside backup sets usually breaks their integrity.
• Replicas, warehouses and analytics platforms, which are frequently forgotten entirely.
• Exports and reports sitting in shared drives and inboxes.
• Third parties who received the data - deletion obligations must be in the contract, and evidence of their deletion requested when a relationship ends.
• Logs, which often contain personal data nobody classified as such.
• Local copies on laptops and personal drives.

A defensible position states where deletion is immediate, where it is eventual, and why - not a claim of instant erasure everywhere that cannot survive scrutiny.

Legal hold

When litigation or an investigation is reasonably anticipated, relevant data must be preserved - and that obligation overrides the retention schedule. You need a documented process to suspend automated deletion for identified data, and to release it afterwards. Automated deletion running during a legal hold is a serious problem, and its absence is a reason many organisations quietly never automate deletion at all. The better answer is a hold mechanism, not permanent retention.

Evidencing it

Auditors ask for the schedule, evidence that it is applied, and evidence of actual disposal. The third is where most organisations have nothing. Keep disposal records - what category, what period, when, by what method, authorised by whom - without retaining the data itself. Certificates of destruction for physical media and hardware belong in the same file.

Key takeaways

• Data past its purpose is liability - breach scope, discovery and privacy exposure.
• Build the schedule from data categories with a precise trigger and a named owner.
• Be explicit about backups and replicas rather than claiming instant erasure everywhere.
• Build legal hold before automating deletion, and keep disposal records.