On January 13, 2026, France’s data protection authority issued two sanctions totaling €42 million against Free Mobile and Free, the country’s second-largest telecom operator. The headlines focused on the breach — 24 million subscribers, IBANs exposed, an attacker selling the dataset on a forum. But buried in the CNIL’s reasoning is the part that should concern every CISO and DPO reading this: a substantial portion of that fine wasn’t for the breach itself. It was because Free Mobile had no working mechanism to sort and delete former subscribers’ data, and was holding personal information it had no legal basis to keep.
Most organizations have a data retention policy. Most of those policies could not survive a regulatory inspection. The gap between “we have a policy” and “we have a defensible policy” is wider than most legal and security teams realize, and supervisory authorities — particularly in the EU — have spent the last three years systematically closing the door on the workarounds that used to work.
Why “Keep Everything Just in Case” Stopped Working
The default posture across most enterprises is still retention by inertia: data accumulates, storage is cheap, deletion requires effort and risk acceptance, so nothing gets deleted. Under older privacy regimes, that posture was tolerable. Under GDPR Article 5(1)(e) — the storage limitation principle — that inertia is a compliance failure.
The text of the obligation is short. Personal data must be kept no longer than necessary for the purposes for which it was collected. What makes the obligation hard isn’t the rule — it’s the burden of proof. Controllers must define and document specific retention periods, and “as long as necessary” without further specification does not satisfy the article. The regulator does not have to prove a retention period is too long. The controller has to prove it is correct.
This inverts how most policies are written. A typical retention policy lists data categories and assigns a number — three years, seven years, “for the duration of the customer relationship.” The numbers usually come from an internal compromise between legal, finance, and operations. Almost none are tied to a documented purpose, a specific legal basis, or a deletion mechanism that actually fires when the period expires. When supervisory authorities inspect, that’s the chain they walk. Each broken link is a separate finding.
What the Free Mobile Fine Actually Punished
The Free Mobile case is worth dwelling on because the CNIL was unusually explicit about the retention component. The CNIL found that Free Mobile kept personal data of millions of former subscribers for a longer period than was necessary, and did not sort or delete it in due time, beyond what was justified for accounting purposes. The key word is “sort.” French law requires telecom operators to retain certain billing-related data for ten years. Free Mobile had not implemented measures to sort the data of former subscribers in order to retain only those necessary for accounting purposes and then delete them when their retention was no longer necessary.
In other words: the company had a legal obligation to keep some data. It used that obligation as cover for keeping all data. When the breach happened, the attacker walked away with the personal records of 24 million people, including a substantial number of former subscribers whose data should have been purged years earlier.
The fine was structured to reflect this. The companies were fined €27 million and €15 million respectively, based on Iliad’s €10 billion turnover and €367 million profit posted in 2024. CNIL noted that both Free and Free Mobile lacked the necessary capabilities to sort former subscribers’ data in a way that retained only the necessary information for accounting purposes. The breach was the trigger. The retention failure was an aggravating factor that turned a breach response case into a nine-figure GDPR sanction.
This is the pattern. Retention failures rarely produce standalone fines at the high end — they produce fines when something else has gone wrong, and the regulator opens the books and finds a graveyard of personal data that should not have been there.
The Five Failures Most Policies Share
After three years of CNIL, BfDI, and other supervisory authority decisions, a consistent diagnostic emerges. Most policies fail in some combination of the following ways.
The blanket period. A single retention figure applied across heterogeneous data — “we keep customer data for seven years” — ignores the purpose-specific nature of the obligation. Different data categories serve different purposes and must have different periods. Marketing engagement logs and tax-relevant transaction records cannot share a retention clock.
The undefined period. Phrases like “as long as necessary,” “until requested,” or “for the duration of our relationship” appear in countless policies. The CNIL has repeatedly rejected retention periods stated as “until the data subject requests deletion” — see CNIL Deliberation SAN-2022-009, 13 January 2022, EUR 300,000 fine against Dedalus Biologie, where retention of medical data without defined limits was cited as a core violation. The medical context made it worse, but the principle generalizes: a retention period that depends entirely on user action is no period at all.
The legal-hold dragnet. Organizations apply blanket holds covering whole systems, indefinitely, against hypothetical disputes. GDPR does not permit indefinite retention on the basis of hypothetical legal risk — legal holds must be tied to specific proceedings or credible threats of proceedings, must be documented, and must be lifted when those threats resolve. A litigation hold is a targeted pause on specific data. It is not a retention extension.
The active-only deletion. Policy says delete after three years. The operational pipeline removes records from the production database. The data lake snapshot from last quarter still has them. The encrypted backup from last year still has them. The dev environment seeded six months ago still has them. Failure to delete from backups, archived systems, and shadow copies is structurally the most common gap between policy and practice. Any system that holds a copy of the personal data is within scope of the retention obligation.
The archive that isn’t. Moving data to a “cold archive” is treated as a substitute for deletion. Under EU rules, an archive is a different category of processing with its own constraints — restricted access, defined expiry, often a narrower lawful basis. Data moved to an intermediate archive must still have a defined expiry and restricted access. An S3 bucket relabeled “archive” with the same access rules as production is not an archive.
What a Defensible Policy Actually Looks Like
A retention policy that survives an inspection looks substantially different from the templated document in most compliance shares. It is not longer — often it is shorter — but it ties every claim to something a regulator can verify.
The structural backbone is a retention schedule: a table mapping each processing activity from the record of processing activities (ROPA) to four columns. Data category. Retention period in defined units. Legal basis for that period. Deletion or anonymization method, with a named system of record. A compliant GDPR data retention policy is a formal document that maps every category of personal data to a defined retention period. The schedule is the document. Everything else — the prose policy, the privacy notice text, the training materials — derives from it.
The legal basis column is where most policies thin out. There are essentially three sources of a defensible retention period. A statutory mandate — tax law requiring transaction records for a fixed period, telecoms law requiring billing data, employment law requiring payroll records. A contractual obligation — the period needed to perform the contract plus a defined post-termination window for warranty, dispute, or limitation purposes. A legitimate operational purpose that the controller can articulate and would defend in writing — fraud detection requiring eighteen months of behavioral data, customer support requiring two years of ticket history. Each entry on the schedule should reference one of these, with the underlying provision identified by name.
Anonymization is the underused escape valve. Once personal data has been irreversibly anonymized — meaning it can no longer be used to identify an individual directly or indirectly — it falls outside the scope of GDPR and is no longer subject to retention period requirements. The constraint is that the process must be robust and documented, and that pseudonymization (where re-identification is possible with a separate key) does not qualify. For analytical workloads that don’t require subject-level identifiability, an aggressive anonymization step at the end of the active retention window converts a retention-risk problem into a non-personal-data problem.
The Cross-Border Wrinkle: GDPR vs. CCPA Approaches
US-based teams sometimes assume their California obligations are softer, then run into the same problems through a different door. They are not the same regime, but they are converging on the same operational expectations.
The CCPA, as amended by the CPRA, takes a different drafting approach. The CCPA does not impose fixed retention timelines such as “three years” or “seven years” for personal information. Instead, California Civil Code section 1798.100(a)(3) requires businesses to disclose how long each category of personal information is retained, or the criteria used to determine that period. Retention must be limited to what is reasonably necessary for the purposes disclosed at the time of collection. The disclosure obligation is the lever. The substantive limit — necessary for the disclosed purpose — is essentially the GDPR’s storage limitation principle in different words.
Where the two diverge usefully is on backups and the right to deletion. Businesses that store personal information on archived or backup systems can delay deletion compliance requests until said systems are either restored or re-accessed or used for a disclosure, sale, or commercial purpose. CCPA permits this carve-out explicitly. GDPR does not, though regulators have been pragmatic about backup deletion in practice when controllers can demonstrate that restored data would be re-deleted on restore. Either way, the policy must address backups by name. A policy silent on backup retention is presumptively non-compliant under both regimes.
The penalty exposure under CCPA is structurally lower per record but accumulates fast. The penalties for non-compliance can be significant, ranging up to $7,500 per intentional violation. The first CCPA settlement involved a $1.2 million fine against Sephora. The California Attorney General’s office and the CPPA have both signaled retention disclosure adequacy as an enforcement priority. The pattern echoes Europe’s: the inspection trigger is usually something else, and inadequate retention practices become a multiplier in the penalty calculation.
The FAQ DPOs Keep Hearing
Does GDPR require a written retention policy? While the GDPR doesn’t explicitly require a written retention policy, having one is strongly recommended as it demonstrates accountability and helps meet compliance obligations. In enforcement practice, the absence of a documented policy is one of the most frequently cited findings, so the practical answer is yes.
Can we keep data indefinitely if it’s strongly encrypted? No. Encryption is a security measure, not a lawful basis for retention. Even if data is stored securely, the GDPR requires that it be retained only as long as necessary for the purpose for which it was collected. Indefinite storage is generally not permitted. Discord ran this argument and lost.
Does the right to erasure override our legitimate retention period? A data subject’s right to erasure under GDPR Article 17 does not override legitimate retention obligations. Where data must be retained to comply with a legal obligation, to establish or defend legal claims, or for other Article 17(3) reasons, erasure can be refused — but the refusal must be communicated to the data subject with the legal basis clearly explained. The exception is real, but it is narrow and requires affirmative justification.
How often should we review the retention schedule? Annually at minimum, with triggered reviews when processing activities change, new data categories are introduced, or applicable law changes. Reviews should be documented with dates, participants, and decisions — the absence of a recent review is itself a finding in EU inspections.
The Stance
Treat retention as an engineering problem with legal supervision, not a legal problem with engineering support. A retention policy that lives in a Word document, references no specific systems, and triggers no automated process is decorative. The defensible version is the one where every entry on the schedule corresponds to a named purge job, a specific lifecycle rule, an audit log, and a person who would lose their job if it stopped running.
The economics are now firmly on the side of deletion. The cost of holding data — in regulatory exposure, breach blast radius, e-discovery scope, and storage — exceeds the cost of building the deletion infrastructure for any organization above mid-market scale. After the breach at Free Mobile, France experienced more customer-exposing or service-disrupting incidents on large telecommunication service providers. In July 2025, Orange France announced that it had detected a breach on its systems, causing operational disruptions. A month later, Bouygues Telecom suffered a data breach that exposed the sensitive data of 6.4 million customers. Each of these companies will face the same line of inquiry from CNIL: how much of the breached data should not have been there at all?
That is the question the next inspection will ask. Most current policies cannot answer it.
