"How long can we legally keep this data" is one of the most common GDPR questions a growing business runs into, and it's also one of the most consistently misanswered. There is no single number in GDPR itself, no clause that says two years for this, five years for that. What the law actually requires is a functional test tied to purpose, backed up by the specific retention numbers that other laws (tax, employment, contract limitation periods) layer on top. This guide walks through what the storage limitation principle actually demands, where real fixed numbers do come from, and a worked retention schedule you can adapt for your own data map.
What the storage limitation principle actually says
GDPR Article 5(1)(e), the storage limitation principle, requires that personal data 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." Read closely, that sentence doesn't set a duration. It sets a test: data can be kept only as long as it's still needed for the purpose you collected it for, and no longer, regardless of whether that turns out to be six weeks or six years.
This ties directly to purpose limitation, Article 5(1)(b), which requires that data be collected for specified, explicit, and legitimate purposes and not processed further in a way incompatible with those purposes. Together, the two principles mean a retention period isn't a fixed calendar setting you configure once. It's a consequence of the purpose: once the purpose is fulfilled, or the data is no longer needed to fulfill it, the retention clock runs out, whatever that happens to work out to for a specific data type in a specific business.
That's the part most short summaries of GDPR skip, and it's also why "how long can we keep this" doesn't have a one-word answer. The honest answer is "as long as you can point to a real, ongoing purpose that still needs it, and not a day longer."
Where fixed numbers actually come from
None of that means retention periods live entirely in the abstract. In practice, most of the concrete numbers a business ends up using come from laws layered on top of GDPR, not from GDPR itself.
Tax and accounting law is the clearest example. Most EU member states require businesses to retain invoices, receipts, and financial records for a statutory period, commonly somewhere in the six-to-ten-year range depending on the country, regardless of whether the underlying customer relationship is still active. That statutory floor gives you a real, defensible number for financial records specifically, and GDPR doesn't override it. A business isn't violating storage limitation by keeping an invoice for the length of time tax law requires; it's complying with a legitimate legal obligation, which is itself a valid basis for processing under Article 6(1)(c).
Employment law works the same way for HR records, with country-specific retention rules for payroll, tax withholding, and workplace-safety documentation that often run several years past an employee's departure. Civil limitation periods (the window during which someone could bring a legal claim against you, also country-specific, often in the three-to-six-year range for contract disputes) are the usual justification for retaining a customer's contract and transaction history for a defined period after the relationship ends, since you may need that record to defend yourself if a dispute arises later.
The pattern across all of these: GDPR itself doesn't hand you a number. It requires you to identify which purpose, and which supporting legal basis, justifies keeping a given category of data, and to set a period (or clear criteria) that actually matches that purpose rather than an arbitrary "keep everything forever" default.
A worked retention schedule
Retention schedules are usually built data type by data type rather than as one blanket rule for the whole business, since different categories of data serve different purposes and carry different statutory requirements. Here's a representative example, the kind of table most businesses end up building internally, with the caveat that exact periods vary by country and should be confirmed against your own jurisdiction's statutory rules before you adopt them.
Example GDPR retention schedule
| Retention period | Legal basis | |
|---|---|---|
| Marketing contact list (opted in) | Until withdrawn, plus inactivity cleanup | Consent, Article 6(1)(a) |
| Active customer account data | Duration of the relationship | Contract necessity, Article 6(1)(b) |
| Invoices and financial records | Statutory period, commonly 6 to 10 years | Legal obligation, Article 6(1)(c) |
| Closed account, post-relationship | Local civil claims limitation period | Legitimate interest, Article 6(1)(f) |
| Website analytics and log data | Typically 14 to 26 months | Legitimate interest, Article 6(1)(f) |
| Unsuccessful job applicant data | Typically 6 to 12 months | Consent or legitimate interest |
A few of those rows are worth a second look. The marketing contact row doesn't resolve to a fixed number at all, it resolves to an event (consent withdrawal) plus a cleanup rule for people who've gone silent without formally unsubscribing, which is itself a common and defensible pattern: many businesses purge or re-permission contacts who haven't engaged in a set window, often twelve to twenty-four months, on the theory that stale consent stops being a good-faith basis for continued marketing. The analytics row reflects a range rather than a single number because it largely follows the default retention settings of whatever analytics tool a business uses, adjusted downward if there's no real purpose for keeping raw log data that long.
What "no longer than necessary" means when the period ends
Once a retention period expires, GDPR gives you two compliant paths, not one: deletion, or anonymization. Deletion is the more familiar option, the data is destroyed and no longer exists anywhere in your systems, including backups once those cycle out. Anonymization is the other valid path: if data is processed in a way that irreversibly strips it of anything that could identify a specific person, even indirectly, it stops being personal data at all, and GDPR simply no longer applies to it.
The distinction that trips people up most often is between anonymization and pseudonymization. Pseudonymized data, where identifying fields are replaced with a token or code but a key exists somewhere that could reverse the process, is still personal data under GDPR, because re-identification remains possible. True anonymization has to be irreversible in practice, not just inconvenient to reverse. If your business wants to keep aggregate usage patterns past a data subject's active retention window (for long-term product analytics, say), genuine anonymization is the compliant way to do that, not a database column renamed from email to user_ref.
Disclosing retention in your privacy policy, and to yourself
GDPR requires retention information in two different places, and businesses sometimes handle one without the other. Article 13(2)(a) and Article 14(2)(a) require that data subjects be told, at the point of collection, the retention period for their data or, where a fixed period can't be determined in advance, the criteria used to determine it. That's the sentence your privacy policy needs to contain, and "we keep data as long as necessary" on its own doesn't satisfy it, since it states the legal test back at the reader instead of answering it.
Separately, Article 30 requires most businesses to maintain internal Records of Processing Activities, which need to document retention periods (or criteria) for each processing activity, independent of what's published externally. A privacy policy with a specific, useful retention section usually reflects a business that's already done this internal documentation work; one with a vague, one-line retention mention often hasn't.
- We retain your data as long as necessary for our business purposes.
- Data may be kept indefinitely unless you request deletion.
- Account data: kept for your active subscription, plus 5 years for legal recordkeeping.
- Marketing data: kept until unsubscribe, or 18 months of inactivity.
The specific version on the right isn't longer for its own sake, it's answering the actual question a data subject (or a regulator reviewing a complaint) is asking: how long, and why. That's the bar Articles 13 and 14 are written to.
Building this into your policy without guessing
Most of the work here happens before you write a single sentence of policy text: mapping what data you collect, what purpose each category serves, and what statutory or contractual period actually applies to it, the same exercise the 7 key principles of GDPR are built around, storage limitation being one of the seven. Once that map exists, the policy language is mostly a matter of stating it plainly.
Our Privacy Policy Generator builds a retention section from the data types and business details you provide, so the specific-language pattern above happens by default instead of by memory, and it stays consistent with the rest of your policy's GDPR compliance language rather than living as a disconnected paragraph someone wrote once and never revisited.
The information in this article is for informational purposes only and should not be construed as legal advice on any matter, and does not create a lawyer-client relationship.
