Data retention

What is data retention?

Data retention is the set of rules that decide how long you keep each kind of data and what happens when that time is up: delete it, archive it, or strip out the personal details. Every rule answers two questions: how long do we hold this, and on what basis?

The basis matters as much as the number. "We might need it someday" is not a basis; a purpose you can name, such as invoicing or a support case, is. Retention is a load-bearing part of data governance: it decides when data stops being an asset and becomes a liability.

Storage limitation versus legal retention

Two obligations pull against each other. The GDPR storage limitation principle, Article 5(1)(e), says the personal data you hold about people (PII) may be kept in identifiable form no longer than you need it for the purpose you collected it for. That points toward deleting early, and the data minimisation principle agrees: hold less, for less time.

Other rules push back. In Belgium, a business has to keep its accounts and supporting documents for seven years under the Code of Economic Law, and tax rules expect the same. You cannot erase last year's invoices to answer a privacy request, because another law says those invoices stay.

Retention is where you reconcile the two. Personal data with no legal hold follows storage limitation, so you set a short clock. Records under a statutory period stay for the legally defined term, then delete on schedule. The mistake is treating one rule as the only one.

The retention schedule

The practical artefact is a retention schedule: a table listing every category of data you hold, with four things pinned down for each.

• Purpose. Why you hold it, in plain terms. This justifies the period.

• Period. How long, as a concrete number rather than "as needed".

• Trigger. The event that starts the clock: account closed, invoice paid, employee left.

• Disposal method. What deletion means here, from a hard delete to anonymisation that keeps the row without identifying anyone.

One line might read: support tickets, held to resolve and audit issues, kept 24 months from the day the ticket closes, then reduced to anonymised counts with the free-text fields removed. Do that per category and the principle becomes something a pipeline runs on a timer.

What to watch out for with data retention

Keeping everything forever. Storage is cheap, so teams keep all of it. Old personal data no one uses is pure downside: it widens the blast radius of a breach and makes every erasure request harder to answer.

Deleting something a law told you to keep. The opposite failure. An over-eager cleanup job wipes records an accounting or tax rule required you to hold, or that you needed as an audit trail to reconstruct a decision. Deletion has to check for legal holds before it runs.

Forgetting backups and soft-deleted rows. This is the gap most policies miss. A soft delete only sets a deleted_at flag, so the personal data is still in the table. Backups hold full copies for weeks after a record was "deleted" in production. Both are still retained data. When you cannot purge a backup right away, put it beyond use until the backup cycle overwrites it.