Key Takeaways
- The GDPR does not set fixed retention periods. The storage limitation principle (Article 5(1)(e)) says personal data may be kept "no longer than is necessary" for the purpose it was collected — you define the period, and you must be able to justify it.
- Other laws set minimum retention periods that override your urge to delete: German tax law, for example, requires invoices to be kept for 8 years (reduced from 10 as of January 2025) and commercial books and annual financial statements for 10 years.
- You must document retention periods in your record of processing activities (Article 30(1)(f)) and tell customers about them in your privacy notice (Article 13(2)(a)).
- A written policy is not enough. Regulators expect data to actually be deleted or anonymized when the period expires — including in backups and archives. Berlin's DPA fined Deutsche Wohnen €14.5 million over an archive system that could not delete tenant data at all.
- The practical answer for most eCommerce data: keep transaction records as long as tax and commercial law require, keep contract data until legal claims expire, and delete marketing data when consent is withdrawn or contacts go stale.
Introduction
"How long can we keep customer data?" is one of the most-asked GDPR questions in eCommerce — and one of the most misunderstood. The regulation never gives a number. Instead, it hands you a principle (keep data only as long as necessary), a documentation duty (write your periods down and publish them), and an enforcement risk if you default to keeping everything forever.
This guide explains what the GDPR actually requires, gives realistic retention benchmarks for the data types every online store holds, and walks through building a retention policy you can defend in an audit.
This article is informational content, not legal advice. Retention obligations vary by country and sector — confirm specifics with a qualified legal professional.
What the GDPR Actually Says About Retention
Three provisions do the heavy lifting:
- Article 5(1)(e) — storage limitation. Personal data must be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed." Note the wording: data that is fully anonymized is no longer personal data, so anonymization is a valid alternative to deletion — for example, converting old orders into aggregate sales statistics.
- Article 13(2)(a) — transparency. When you collect data, you must tell people "the period for which the personal data will be stored, or if that is not possible, the criteria used to determine that period." A privacy policy that says nothing about retention is incomplete.
- Article 30(1)(f) — accountability. Your record of processing activities (ROPA) should include "the envisaged time limits for erasure of the different categories of data." If you have not built a ROPA yet, start with our guide to [building a record of processing activities](/resources/blog/data-mapping-101-how-to-build-a-record-of-processing-activities).
Behind all of this sits Article 5(2): you must be able to demonstrate compliance. "We delete data when it is no longer needed" is a claim; a documented retention schedule plus evidence of actual deletion is proof.
How Long Should an Online Store Keep Customer Data?
There is no single GDPR answer, but there are defensible patterns. The logic is always the same: identify the purpose, find any statutory retention duty, and add the limitation period for legal claims where relevant.
| Data category | Typical approach | Why |
|---|---|---|
| Orders, invoices, payment records | Statutory minimum — e.g., 8 years for invoices in Germany, 10 years for books and financial statements; other EU countries commonly require 6–10 years | Tax and commercial law require retention; GDPR deletion duties yield to legal obligations (Article 17(3)(b)) |
| Contracts and customer correspondence | Until the limitation period for contract claims expires (e.g., 3 years standard in Germany) | Legitimate interest in defending legal claims |
| Marketing lists (consent-based) | Until consent is withdrawn; periodically purge contacts who have gone silent | Consent-based processing ends when consent does |
| Customer accounts | Define an inactivity window, notify, then delete or anonymize — many shops use two to three years of inactivity as a trigger | The purpose (serving an active customer) has lapsed |
| Consent records | For as long as the processing runs, plus the limitation period — they are your proof of lawful basis | Accountability (Article 7(1)) |
| Analytics and behavioral data | Short cycles — months, not years; aggregate or anonymize quickly | Rarely necessary in identifiable form for long |
Two notes on this table. First, the German invoice change is recent: the Fourth Bureaucracy Relief Act (BEG IV) cut the retention period for invoices and booking receipts from 10 to 8 years for periods beginning after 31 December 2024, while ledgers and annual financial statements stay at 10 years. If your policy still says "10 years for everything, because Germany," it is now over-retaining. Second, the non-statutory rows are judgment calls — what matters is that you chose a period, wrote down why, and apply it consistently.
Retention duties and deletion duties coexist
A common point of confusion: tax law says keep the invoice for 8 years, a customer says delete everything under Article 17 (right to erasure). Both are satisfiable. Erasure does not apply where processing is necessary "for compliance with a legal obligation" (Article 17(3)(b)) — so you keep the invoice, delete everything you have no legal duty to hold (marketing profile, analytics history, support chats), and tell the customer exactly that. Our guide to [automating data subject requests](/resources/blog/data-subject-access-requests-automation) covers how to handle these partial-erasure responses at scale.
What about backups?
Retention limits apply to all copies, not just the live database. Regulators accept pragmatic approaches — for example, ensuring expired data in backups is deleted on the backup rotation cycle and is not restored back into production — but "it lives forever in our backup bucket" is not a compliant end state. Document how your backup cycle interacts with your retention schedule.
Three quick answers eCommerce teams ask
- A customer closed their account — delete everything? No. Close out the marketing profile, behavioral data, and account record on your schedule, but invoices and transaction records stay for their statutory term. Tell the customer which parts remain and why.
- Unsubscribes from the newsletter — delete the email address? Keep a minimal suppression record (typically just the address) so you can keep honoring the opt-out; deleting it entirely risks re-adding the person later. Suppressing future contact is its own narrow purpose.
- Abandoned carts and guest checkouts? No contract was concluded, so no tax clock applies — these should age out on a short cycle measured in weeks or months, not years.
How to Build a Data Retention Policy in 6 Steps
Step 1: Map your data
You cannot set retention periods for data you have not inventoried. List every category of personal data, where it lives, and why you process it — this is the same exercise as building your ROPA, so do them together.
Step 2: Attach a purpose and legal basis to each category
The retention period flows from the purpose. Order data exists for contract performance and tax compliance; a newsletter list exists for consent-based marketing. Different purposes, different clocks.
Step 3: Set a period — or documented criteria — per category
Where a statute gives you a number, use it. Where it does not, choose a defensible period and record the reasoning. Article 13 explicitly allows criteria ("until account deletion plus 30 days") where a fixed period is impossible.
Step 4: Document and publish
Put the schedule in your ROPA, summarize it in your privacy policy, and version both. An undocumented practice does not exist as far as an auditor is concerned.
Step 5: Actually delete
This is where enforcement happens. Build deletion or anonymization routines — scheduled jobs, CRM automation rules, archive purges — and capture evidence that they ran. In the Deutsche Wohnen case, Berlin's data protection authority found an archive that retained tenant data indefinitely with no technical ability to delete, and issued a €14.5 million fine. The fine was later overturned on procedural grounds and the case ended up before the Court of Justice of the EU, but the substantive message has only hardened since: a "data cemetery" is a GDPR violation, not a storage strategy.
Step 6: Review annually
Laws change (see the German example above — and the proposed [EU Digital Omnibus](/resources/blog/eu-digital-omnibus-gdpr-ai-act-2026) may change more), tools change, and purposes lapse. Put a yearly review on the calendar.
Common Retention Mistakes in eCommerce
- Keeping everything "just in case." "It might be useful someday" is not a purpose. It is the exact reasoning the storage limitation principle was written to prohibit.
- One blanket period for all data. "We keep customer data for 10 years" over-retains marketing data and may under-retain financial records. Periods attach to purposes, not to "data" in general.
- A policy with no deletion behind it. The gap between the written schedule and what the database actually contains is the first thing a regulator checks.
- Forgetting processors. Your email platform, helpdesk, and analytics vendors hold copies of customer data. Their retention behavior is your responsibility — your [data processing agreements](/resources/blog/gdpr-data-processing-agreements-ecommerce-guide) must require deletion or return at the end of service.
- Deleting what the law requires you to keep. Over-eager cleanup that wipes invoices inside the statutory window trades a GDPR problem for a tax problem. Erasure requests do not override legal retention duties.
How PrivacyForge Helps
Retention compliance is mostly an inventory-and-evidence problem, which is what PrivacyForge is built for:
- Data mapping records every processing activity with its purpose, legal basis, and retention period — giving you the Article 30(1)(f) documentation regulators ask for first, in an exportable ROPA.
- DSAR automation handles erasure requests with workflows that distinguish what must be deleted from what legal obligations require you to keep, with an audit trail of every response.
- Consent management keeps timestamped consent records — your proof of lawful basis for exactly as long as you need it.
- Compliance scoring flags gaps such as processing activities with no documented retention period, so over-retention surfaces before an auditor finds it.
Not sure where your store stands? Run our [free compliance scan](/scan) for a first read, or work through the [GDPR eCommerce checklist](/resources/blog/gdpr-compliance-for-ecommerce-practical-checklist) for the full picture.
Conclusion
The GDPR's answer to "how long can we keep customer data" is a method, not a number: tie every data category to a purpose, find the statutory clocks, choose and document defensible periods for the rest, and prove that deletion actually happens. Stores that do this once — and review it yearly — turn one of the most-cited GDPR principles from a standing risk into a settled, documented routine.
Start with the inventory. Everything else in retention compliance follows from knowing what you hold and why.