Retention Schedule

A retention schedule is the document that states, for each category of data an organization holds, how long it is kept, why that period, and what happens when it ends. It turns the principle of not keeping data indefinitely into something a job can execute and a reviewer can check.

It exists because regulators state the rule and leave the number open. The UK regulator is direct about it: “The UK GDPR does not set specific time limits for different types of data. This is up to you.” GDPR Article 5(1)(e) names the principle “storage limitation” and requires data be “kept in a form which permits identification of data subjects for no longer than is necessary” — necessary for your purposes, which only you can say.

What a row of it contains

A schedule with only two columns — data and duration — cannot be defended or executed. Five make it both.

• Category. Defined so that someone can decide whether a given dataset falls in it. “Customer records” fails this test; “completed order records including delivery address” passes.
• Period, and what it counts from. Three years from account closure and three years from last login are different rules with different outcomes; the trigger event matters as much as the duration.
• Basis. Why this period — a statutory duty, the purpose the data was collected for, a defined analytical need, or dispute defence. Without it, the next person cannot tell which periods are negotiable.
• End action. Delete, anonymise, or aggregate and delete the detail. Not the same thing, and the choice is usually available.
• Owner. A named owner who decides when the basis is questioned, because it will be.

The ICO ties documenting these to compliance rather than good practice — “you need to establish and document standard retention periods … wherever possible” — and treats the end of a period as a prompt for a decision, not an automatic erase: “You should review whether you still need personal data at the end of any standard retention period, and erase or anonymise it.”

Where the numbers come from, and how conflicts resolve

Four kinds of argument bear on a period, and they do not carry equal weight. A statutory duty to keep sets a floor and overrides an operational preference to delete. The purpose the data was collected for sets a ceiling — purpose limitation means that once the purpose is spent, continuing to hold it needs a fresh justification. Dispute defence is legitimate and expands without bound if nobody scopes it. Analytical value is the weakest basis and the most confidently asserted, which is why it deserves a specific question: does the analysis need the personal detail, or would an aggregate serve it?

That question is often where the schedule earns its keep, because the end action does not have to be deletion. Keeping counts, distributions, and cohort summaries while removing the personal detail satisfies storage limitation and preserves what the analysis actually used. The regulator’s own wording pairs the options — “erase or anonymise” — and anonymisation genuinely achieved takes the result out of scope. The caveat is that it has to be genuine; a table with the name column dropped and everything else intact is usually still about identifiable people.

One narrow exception is worth knowing, and it is narrower than its summary. Data held only for archiving in the public interest, scientific or historical research, or statistical purposes may be kept longer than the purpose it was collected for would allow. “We may analyse it later” is not that exception, and reaching for it to avoid writing a period is the most common misuse of it.

The conditions attached matter as much as the permission, because relying on the exception without them is not relying on it at all. Under the EU Regulation such processing “shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject,” and those safeguards “shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation.” The measures “may include pseudonymisation provided that those purposes can be fulfilled in that manner.” And there is a stronger clause that is easy to miss: “where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner” — if the research can be done without identifying people, it must be.

Three practical consequences. The exception is tied to the purpose, so it does not license using the retained data for something else later — reuse for an operational or commercial purpose is a separate decision under the ordinary rules. It requires the safeguards to actually exist and be documented, which means a records entry naming them rather than a claim in a meeting. And the aggregate route above is not exempt from judgment either: keeping summaries is only out of scope if the result genuinely no longer identifies anyone, which is an assessment of what could be re-identified with the means reasonably likely to be used, not a consequence of having aggregated.

Jurisdiction matters here more than in most of this entry, and so does the difference between a rule being removed and a rule being moved. The wording above is the EU Regulation’s. In the UK the same article no longer carries it: the Data (Use and Access) Act 2025 created a new chapter whose provisions, in the explanatory notes’ own words, “combine the existing safeguards currently found in Article 89” with those from the Data Protection Act 2018 — a consolidation, not an abolition, so the safeguards still apply and are cited from somewhere else. Other regimes frame the exception differently again. The practical instruction is the same in every case: cite the text that applies to you as of the date you are writing, rather than the one quoted in an article — including this one.

Match the unit and the retention clock

A storage lifecycle policy can automate expiry only when its clock matches the approved retention trigger or expiry date, every record in the object shares the disposition conditions, and holds and referenced versions are protected. File granularity alone is insufficient: creation time may precede contract closure, and rewriting old records into a new file must not silently restart their retention period. When those conditions do not align, calculate eligible objects or expiry dates separately. Per-person rules also require identifying that person’s records across objects.

Per-subject retention needs a stored map from subject to the places their data lives, a job that acts on it, and a report of what it touched. Writing the schedule is the cheap half; that map is the work, and a schedule written without knowing whether it exists tends to specify periods nothing can enforce.

Two failure modes follow from getting the unit wrong or skipping the map, and they look alike from outside.

• A schedule nothing executes. Periods are documented, no job applies them, and data accumulates. The document then makes things worse than having none, because it evidences a rule you are visibly not following.
• A schedule that covers the source and not the copies. The warehouse table expires on time while extracts, caches, and derived tables keep the data. Retention applies to data, not to one location of it.

Both are caught by the same habit: whatever runs the schedule should emit counts, and those counts should be read. A retention job that deletes zero rows for three months has either nothing to do or has broken, and nobody can tell which without looking.

Review the schedule on a fixed cadence rather than when something prompts it. Purposes change, products retire, statutory periods are amended, and a schedule that reflects last year’s business is a document being followed rather than a decision being made.

How a schedule fits with classification, deletion mechanics, and evidence is worked through in The Copy You Forgot.

References: ICO, Principle (e): Storage limitation; Regulation (EU) 2016/679 (GDPR), EUR-Lex; Article 89, as originally adopted; Data (Use and Access) Act 2025, Explanatory Notes.