GDPR Data Retention Policy: Lessons From a €680k Fine

Key Takeaways

On 28 July 2026, Spain's data protection authority (AEPD) fined Flexicar Internacional €680,000 — and €280,000 of that had nothing to do with the breach itself: €30,000 for a privacy policy that was too vague about retention, and €250,000 for keeping old "blocked" data mixed in with live data.
A privacy policy that says data is kept "as long as necessary" does not satisfy GDPR Article 13(2)(a), which requires the actual retention period or the specific criteria used to set it.
Retention disclosures must differentiate by data-subject type: a five-year hold on sales leads who never bought is a different story from an order record, and your policy has to say so.
Data you keep only for legal-defence reasons must be segregated and access-restricted, not left in your active CRM — GDPR calls this restriction of processing (Article 18); Spain calls it blocking (bloqueo).
Suffering a cyberattack does not excuse the underlying failures. As the AEPD reportedly put it, a breach "does not exempt from responsibility" when the controls should have been there first.

Introduction

It is the kind of line that sits in almost every online store's privacy policy: "We retain your personal data for as long as necessary to fulfil the purposes described above." It reads like compliance. On 28 July 2026, the AEPD priced that sentence — and the messy data practices usually hiding behind it — at a chunk of a €680,000 fine against the used-car retailer Flexicar.

The headline was a breach of website lead-form data. But the enforcement decision is more useful than a breach story, because two of the three infringements were about things every merchant controls without a security team: what your privacy policy says about retention, and where you keep the customer data you have stopped using. This guide turns that decision into two fixes you can make this week.

What the AEPD's €680,000 Flexicar Fine Actually Penalised

The AEPD's resolution (EXP202410832) split the €680,000 across three GDPR breaches, and the split is the lesson. As reported by Spanish legal press Confilegal and Moncloa, the AEPD assessed €400,000 under Article 5(1)(f) (integrity and confidentiality), €250,000 under Article 32 (security of processing), and €30,000 under Article 13 (transparency about retention).

The case began with complaints filed on 4–6 June 2024, after the data of people who had only filled in a contact form on Flexicar's website — leads who never bought a car — was exposed in a breach that followed Flexicar's absorption of its Iberian subsidiary. Investigating, the AEPD found two things that had nothing to do with the attacker. First, Flexicar kept those lead records for five years but never clearly disclosed that period; its privacy policy's retention information was, in wording reported from the resolution, too generic, and failed to distinguish formalised customers from mere leads. Second, data that should have been "blocked" — kept only to meet a legal obligation — was mixed in with active commercial data, without the logical or technical segregation that blocked data is supposed to have.

The transferable point is not "don't be Flexicar." It is that a breach turns your retention hygiene inside out for a regulator to inspect — and if old data you should have walled off is sitting in the same table as live data, the breach fine is only the beginning. The AEPD's closing position, as reported, was blunt: suffering a cyberattack "does not exempt from responsibility" where adequate measures were not implemented beforehand, and blocked data remains fully protected personal data. Flexicar was ordered to rewrite its privacy policy and prove it had implemented new security measures.

How Specific Does Your Privacy Policy's Retention Language Have to Be?

Specific enough that a reader learns either the actual period or the exact rule you use to set it — per data-subject type. GDPR Article 13(2)(a) requires you to disclose "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period." A blanket "as long as necessary" gives neither, which is why it drew a €30,000 line item.

The regulation offers a deliberate two-part standard, and most stores can meet the first part more often than they think:

State the period when you can. "Order and invoice records: 6 years after the transaction, to meet tax law" is a period. It is also more useful to the customer than a paragraph of throat-clearing.
State the criteria when a fixed number genuinely doesn't fit. "Support tickets: kept until the issue is resolved and then for 12 months, so we can reopen related queries" describes the rule, not a guess.

The Flexicar detail that matters for eCommerce is differentiation. A newsletter subscriber who never purchased, an abandoned-cart lead, a one-time guest checkout, and a repeat account customer are four different retention stories. The AEPD faulted a policy that treated "customer" and "someone who once submitted a form" as one bucket. If your policy has a single retention paragraph for "your data," that is the paragraph a regulator reads first.

The practical read: Article 13 is a transparency-at-collection duty, so this is not something you can fix only in a back-office spreadsheet — the disclosure has to reach the person when you collect the data. The practical version: your privacy policy's retention section should map to the retention schedule in your record of processing activities, category by category, and say so in plain periods.

Deleting vs. Blocking Data: The Segregation Trap That Cost €250,000

Here is the trap that catches careful merchants. You know you cannot keep data forever, so when a customer goes inactive you stop using their data — but you do not delete it, because you might need it for a tax audit, a chargeback dispute, or a future legal claim. That instinct is correct. Leaving that data in your live customer table is where it goes wrong.

GDPR's answer is restriction of processing under Article 18. When data is restricted, it "shall, with the exception of storage, only be processed with the data subject's consent or for the establishment, exercise or defence of legal claims or for the protection of the rights of another natural or legal person or for reasons of important public interest of the Union or of a Member State." In other words: you may keep it, but you must stop actively using it, and it should be walled off so it cannot be casually used.

Spain gives this its sharpest form. Under Article 32 of the LOPDGDD (Spain's national data protection law), a controller must block (bloqueo) data it no longer needs: identify and reserve it, apply technical and organisational measures that prevent processing — including viewing — except to make it available to judges, courts, the public prosecutor, or the DPA, and hold it only until the limitation period for potential liabilities expires. Blocked data may not be processed for any other purpose.

You do not have to be in Spain for this to bind you. The "blocking" label is Spanish; the principle is EU- and UK-wide through Article 18 restriction, Article 5(1)(e) storage limitation ("kept in a form which permits identification… for no longer than is necessary"), and the Article 5(1)(f) security duty. Flexicar's €250,000 Article 32 penalty is what happens when data that should have been reserved and access-limited was instead a normal, fully-readable part of the dataset an attacker walked off with.

The operational takeaway is a strong one: do not model "keep for legal reasons" as a status flag on a live record. A boolean like is_active = false that leaves the row in the same table, readable by the same staff and reachable by the same integrations, is not restriction — it is active data with a label. Restriction means the data lives somewhere your day-to-day tools cannot touch.

How to Fix Your Retention Disclosures and Segregate Inactive Data

You can close both gaps the AEPD penalised without a security project. Work through these in order:

Build a per-category retention schedule. List each data category — order records, marketing leads, support tickets, account profiles, consent logs — and assign each a period or a written criterion, with the legal reason (tax law, limitation period, ongoing consent). This schedule is the source of truth; everything else copies from it.
Rewrite the privacy policy from that schedule. Replace any single "as long as necessary" paragraph with a short table or list that differentiates data-subject types. State periods where you have them; state criteria where you genuinely don't.
Decide a rule for going inactive. For each category, define when data moves from active to restricted: e.g. "marketing leads with no engagement for 24 months are restricted, then deleted at 36 months unless a legal hold applies."
Actually segregate restricted data. Move it out of the live customer table — a separate, access-controlled store, encrypted, with day-to-day integrations (ESP, analytics, personalisation apps) cut off from it. The test: could a marketing automation still email a "restricted" contact? If yes, it is not restricted.
Log the whole thing. Record what you restricted or deleted and when. Article 5(2) accountability means the schedule and the evidence that you follow it are what turn a good policy into a defensible one.

Common Mistakes Merchants Make With Inactive Data

The single worst mistake is the one Flexicar was fined for: treating "we might need it later" as a reason to leave old data in the working dataset. Legal-defence retention is legitimate; leaving that data live and readable is not. Rank the rest below it:

The catch-all retention paragraph. One "as long as necessary" line for every data subject. It fails Article 13(2)(a) and, as the €30,000 line item shows, regulators now read it as a finding, not a formality.
Retention that lives only in the policy, not in the system. A policy that promises deletion at 24 months while the database keeps everything forever is worse than silence — it is a documented broken promise.
Confusing unsubscribe with deletion. A customer opting out of marketing is not a signal to delete their order history, and going inactive is not consent to keep marketing data indefinitely. These are separate clocks.
No owner for the schedule. Retention rules rot the moment a new app or data category appears and nobody updates the schedule. If your record of processing lives in a file called retention_final_v3.xlsx, you are in good company — and slightly exposed.

How PrivacyForge Helps

Both halves of the Flexicar problem are documentation-and-mapping problems before they are security problems, which is where PrivacyForge is built to help. The data mapping module gives you a per-category record of processing where each data type carries its own retention period, legal basis, and the criterion behind it — the exact schedule Article 13 expects your privacy policy to reflect, rather than a single vague clause.

From there, compliance scoring flags the gaps that draw fines: categories with no defined retention period, disclosures that don't differentiate data-subject types, and data held past its stated life. It won't move a database table for you — segregating restricted data is an engineering task on your side — but it will tell you which data should be restricted and give you the audit trail (Article 5(2) accountability) that proves you act on your own policy. For the broader picture, our complete guide to GDPR compliance in 2026 sets retention in context, and our companion guide on how long to keep customer data covers the periods themselves.

This article is informational content, not legal advice. Retention periods vary by jurisdiction and data type — confirm yours against local law or with a qualified adviser.

Frequently Asked Questions

How specific must retention periods be in a privacy policy?

Specific enough to satisfy GDPR Article 13(2)(a): you must state the actual retention period, or — only where a fixed period is not possible — the precise criteria used to determine it. A blanket "as long as necessary" gives neither and was part of the AEPD's €30,000 transparency penalty against Flexicar in July 2026. State periods where you can, and differentiate by data-subject type.

No. On its own it fails Article 13(2)(a), because it discloses neither a period nor the criteria for setting one. Regulators now treat it as a finding rather than a formality — the AEPD fined Flexicar €30,000 in part for exactly this generic language. Replace it with a per-category retention list showing real periods and the legal reason behind each.

Deleting removes the data entirely. Restricting (Article 18) keeps it in storage but stops active use: restricted data may, apart from storage, only be processed with consent, for legal claims, or on other narrow grounds the Regulation lists. Spain's "blocking" (LOPDGDD Article 32) is the same idea, requiring the data be reserved and access-limited to authorities until liability limitation periods expire.

How long can I keep sales leads who never bought anything?

Only as long as you have a lawful basis and a defined purpose — Article 5(1)(e) storage limitation forbids keeping identifiable data longer than necessary. Flexicar's five-year hold on non-converting leads was not itself the core problem; failing to disclose that period and mixing the old data with live data was. Set a period, disclose it, and delete or restrict on schedule.

Do I have to store inactive customer data differently from active data?

Yes, if you are keeping it only for legal-defence or compliance reasons. That data should be restricted under Article 18 — segregated from your live dataset, access-limited, and cut off from everyday tools like your email platform. The AEPD fined Flexicar €250,000 under Article 32 precisely because "blocked" data sat un-segregated alongside active data when a breach hit.

Conclusion

The Flexicar decision is a gift to smaller merchants because it is fixable without a security budget. A regulator has now shown, with a €280,000 price tag, that two ordinary habits — a catch-all retention sentence and a "keep it just in case" pile of old data in the live table — are enforceable failures on their own. Rewrite the retention section of your privacy policy from a real, per-category schedule, and move the data you keep only for legal reasons somewhere your daily tools cannot reach. Then, if a breach ever does come, the retention half of the investigation is already answered.

Start with the schedule. Map your data categories and their retention rules in PrivacyForge, and let compliance scoring show you which disclosures and which datasets still need work.

Sources

#data retention #privacy policy #GDPR enforcement #eCommerce #data mapping