How to write a data retention policy

What the GDPR really asks for

Let us start with what is written about this most often and is not true: nowhere does the GDPR require a document called a "data retention policy".

It asks for three things from which such a document follows in practice.

Storage limitation. Personal data are kept in a form which permits identification of the person for no longer than is necessary for the purpose for which they are processed.

Stating the period. When you collect the data you must tell the person how long you will keep them — and where that cannot be stated, at least the criteria used to determine it.

The record. The record of processing activities states, where possible, the envisaged time limits for erasure of the different categories of data.

On top of that comes the accountability principle: you must be able to demonstrate compliance. And with retention periods that is hard to do without something written down — nobody carries thirty purposes in their head.

A retention policy is therefore the answer to a question, not an obligation in itself. That is good news: it means there is no point writing it from a template, only from what you actually have.

Where a retention period comes from

A retention period is not a matter of opinion. For every category of data the answer comes from one of three sources — in this order.

Specific legislation. Accounting, payroll, archiving, medical records. Where legislation sets the period, the decision is already made and there is nothing to consider. This is the most common source and at the same time the one most often overlooked — organisations look for the answer in the GDPR, where it is not.

The purpose. Where legislation is silent, the data are kept for as long as the purpose lasts. A registration for an event that took place a year ago has no purpose left.

Being able to defend yourself. Once the purpose has ended, a legitimate interest in keeping the data for the limitation period may remain — but not "just in case, forever". That period has to be named and justified, not used as a storeroom.

A practical rule: if you cannot write one sentence of justification for a retention period, the period has not been determined. It has been guessed.

How to do it so that it lasts

Start from the record of processing activities, not from an empty document. That record already contains the categories of data and the purposes. A retention policy is one more column in it, not a new document with a life of its own.

Tie the period to an event, not to a date. "Three years from the end of the employment relationship" works. "Until 2029" works for one year and then misleads.

State the source of every period. A provision of a regulation, or a sentence of justification. Without it, in a year nobody will know why the number is there, and you will not defend it in an inspection.

Decide who keeps track of the period. A policy without an owner is a list of good intentions. Erasure does not usually happen by itself — it has to be somebody's repeated act or a function of the system.

What happens when the period expires

There are two options and they are not equivalent.

Erasure. The data cease to exist. It is the clean solution and the right one for most categories.

Anonymisation. The data remain, but the person can no longer be identified from them — neither afterwards nor by combination with another set. At that point they are no longer personal data and the GDPR does not apply to them. Mind the difference from pseudonymisation, where the key exists and the data remain personal. This is the most frequent confusion in the whole subject.

And a third option that pretends to be a solution: moving the data to an archive "indefinitely". That is neither erasure nor anonymisation — it is retention with a different route of access.

Backups — where policies fail

This is the part most policies do not address, and it is the first question you will be asked in an inspection.

Data erased from the production database remain in the backups — for a week, a month, sometimes years. Going through backups and deleting individual records is usually not technically possible and would damage the integrity of the backup.

A workable approach has three parts and belongs in the policy itself:

Backups have their own, shorter, named retention period. Data disappear from them by the cycle, not by intervention.

Backups are not used for ordinary access to data — only for recovery after a failure. That has to be written down and observed.

If a backup is restored, the erasure is carried out again on the restored data. Without this step, erased data return to production after a restore and nobody notices.

Writing those three sentences is the difference between a policy that holds up and a policy that looks good.

Five mistakes we see most often

One period for everything. "We keep data for three years" across twenty purposes means that some data are held too long and others erased too early — and both are a problem.

A period without a source. A number nobody can trace back.

A policy nobody carries out. The document exists, the erasure does not happen. An inspection asks for the record that it was done, not for the document.

Forgotten places. Shared drives, mailboxes, exports to spreadsheets, old test environments. Data get erased where somebody looks after them and survive where nobody does.

A template from the internet used without adaptation. You recognise it because it contains categories of data the organisation has never processed.

Where we can help

We will draw up the retention policy, or give you our template and go through filling it in with you — whichever makes sense. Part of that is a review of the record of processing activities, because without it the policy is written blind.

If you already have a policy, we can assess it against what actually happens in the organisation. That is usually more useful than writing a new one.

Legal position verified as of 11 September 2026. With legal content, an outdated article is worse than none — if you find a discrepancy, write to us at info@iosec.eu.