GDPR Data Protection and Data Retention Governance Guide

A practical guide to data retention under the GDPR: what the regulation actually requires (and the fixed retention periods it deliberately does not set), how to build a retention schedule that survives scrutiny, and where retention connects to records of processing, erasure, impact assessments, and AI training data.

What the GDPR Is and Who It Reaches

The General Data Protection Regulation — Regulation (EU) 2016/679 — has applied since 25 May 2018 and remains in force without substantive amendment. It governs the processing of personal data by organizations established in the EU and, through its extraterritorial reach, by organizations outside the EU that offer goods or services to, or monitor the behavior of, people in the EU. Its role definitions carry the accountability structure: controllers determine purposes and means, processors act on the controller's instructions, and joint controllers share determination and must allocate their responsibilities transparently.

Two 2026-era notes for orientation. Enforcement remains led by national supervisory authorities; an EU regulation harmonizing cross-border enforcement procedure (Regulation (EU) 2025/2518) entered into force at the start of 2026, with its main investigation chapters applying to investigations opened and complaints lodged from April 2027 — a procedural change, not a change to the substantive rules. And the UK now runs a diverging regime: UK data protection law was amended in 2025 (the Data (Use and Access) Act 2025), while the European Commission renewed the UK's adequacy decisions in December 2025 — so EU–UK transfers continue, but "UK GDPR mirrors EU GDPR" is no longer accurate.

The Principles, with Storage Limitation as the Spine

Article 5 states the processing principles — lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality — with Article 5(2) making the controller accountable for demonstrating all of them. For retention governance the spine is storage limitation, Article 5(1)(e), and its two clauses both matter: personal data may be kept in identifiable form no longer than necessary for the purposes of processing, and longer storage is expressly permitted where data is processed solely for public-interest archiving, scientific or historical research, or statistical purposes, subject to the Article 89(1) safeguards.

A data retention position built on the first clause alone misstates the article it cites. The principle is purpose-relative on both ends: necessity bounds ordinary retention, and the carve-out disciplines — not forbids — the archival tail.

The Retention-Period Myth

A recurring retention error in vendor documents and internal policies alike: "the GDPR requires deletion after N years." The GDPR sets no fixed retention periods — not six years, not any number. Concrete numbers come from elsewhere, and a defensible retention policy names its sources:

The honest formulation for any data retention document: "the GDPR requires that we justify how long we keep each category — the numbers come from named laws or from our documented necessity analysis." Inventing a "GDPR retention period" fails in both directions: it overstates what the regulation says, and it understates the controller's accountability for the reasoning.

Building the Retention Schedule

The retention schedule is the working artifact of storage limitation — the register that turns a principle into checkable rows. A schedule entry that survives scrutiny carries:

Two practice cautions. First, anonymisation is a disposition only when it works: supervisory reviews of erasure practice have repeatedly flagged ineffective anonymisation used as substitute deletion. Second, a retention policy that exists but never fires is discoverable in one question — "show me the last deletion this schedule caused." A schedule with no execution evidence is a statement of intent, not a control.

Records of Processing and the Retention Hook

The GDPR's Article 30 requires controllers to maintain records of processing activities — and it contains retention's most under-used hook: Article 30(1)(f) asks for the envisaged time limits for erasure of each category of data, where possible. Populated honestly, the records of processing and the retention schedule become one story: every processing activity names its data categories, and every category names its clock.

The record-keeping exemption is narrower than commonly assumed. As in force, Article 30(5) exempts organizations under 250 employees only where the processing is occasional, involves no special-category or criminal-offence data, and is unlikely to result in a risk to rights and freedoms — cumulative conditions that real processing rarely satisfies all at once. As of August 2026, EU legislative proposals would relax the record-keeping exemption, but they remain proposals under negotiation: a compliant program documents against the in-force text and tracks the proposals as horizon items, never as current law.

Erasure in Practice

The right to erasure (Article 17) gives data subjects deletion on stated grounds — consent withdrawn, data no longer necessary, unlawful processing among them — balanced by stated exceptions, including freedom of expression, legal obligations, public-interest archiving and research under Article 89(1), and the establishment, exercise or defence of legal claims. Invoking an exception is a decision worth documenting: the justification, not just the outcome.

Operationally, erasure meets its hardest test in backups and downstream copies. A workable data retention and erasure practice states its backup position explicitly — how long backup cycles run, when a deleted record ages out of them, and how restoration processes avoid resurrecting deleted data. The EDPB's coordinated review of the right to erasure (report adopted February 2026) highlighted exactly these gaps: undefined retention periods, weak internal erasure procedures, and backup limitations left unstated. Legal holds are the disciplined exception: a hold suspends the schedule for named records, visibly, with an owner and an end condition — it does not quietly become the schedule.

Impact Assessments and Retention

A data protection impact assessment (Article 35 of the GDPR) is triggered where processing is likely to result in a high risk to rights and freedoms, particularly with new technologies. The listed cases — systematic and extensive automated evaluation including profiling with significant effects, large-scale processing of special categories, systematic large-scale monitoring of publicly accessible areas — are expressly non-exhaustive, and national authorities publish their own high-risk lists. The EDPB-endorsed DPIA guidelines (WP248 rev.01) offer nine screening criteria with a common rule of thumb that meeting two usually warrants a DPIA.

Retention lives inside the DPIA, not beside it: the required assessment of necessity and proportionality covers storage duration. A DPIA that evaluates collection and use but never asks "and for how long?" has skipped one of the questions the assessment exists to answer.

AI Systems and Personal Data

Training data governance is where data protection and AI governance meet, and three positions hold as of 2026. First, training corpora containing personal data are processing like any other — lawful basis and storage limitation apply to the corpus itself, so "training data" belongs on the retention schedule with a real disposition. Second, whether a trained model itself contains personal data is a case-by-case question: EDPB Opinion 28/2024 treats model anonymity as something to be demonstrated — considering the likelihood of extracting or regurgitating personal data — not assumed; the same opinion accepts legitimate interest as a possible basis for AI development, subject to the standard three-step assessment. Third, the public transparency duties about training content that apply to general-purpose AI model providers arise under the EU's AI legislation, not the GDPR — a data protection regulation question and an AI-regulation question that a careful document keeps distinct.

The practical consequence for retention governance: an organization building or buying AI capability should be able to answer, from its schedule, what personal data its training and evaluation sets contain, on what basis, for how long, and what happens to them at expiry.

Retention Readiness Questions

The questions a reviewer — customer, auditor, or authority — can fairly ask, and a mature program answers from its artifacts rather than from memory:

1. Does a retention schedule exist covering every category of personal data, with a named source for each period?
2. Do the records of processing populate the time limits for erasure, and do they reconcile with the schedule?
3. When did the retention policy last cause an actual deletion, and is there evidence?
4. What is the documented backup position for erased data?
5. Are legal holds visible, owned, and end-dated?
6. Do DPIAs assess storage duration explicitly?
7. Where do training and evaluation datasets appear on the schedule?
8. Which pending legislative changes are being tracked, and is anything documented as if a proposal were already law?

Eight questions, one theme: data retention governance is demonstrated by a schedule that names its reasons and provably runs. The GDPR supplies the principle and the accountability; the numbers, the evidence, and the discipline are the organization's own.