Data Retention — Storage Limitation Under Article 5(1)(e)
How to set defensible retention periods under GDPR — the per-category trigger taxonomy, the statutory overrides for tax and labour records in Germany, Poland, and Lithuania, and the deletion-method ladder that withstands an audit without over-engineering.
Bilingual EN + DE / PL / LT, counsel-redlinable Word + PDF, per-category retention pre-structured against your country.
Data retention in five sentences
Article 5(1)(e) GDPR requires personal data to be kept in a form which permits identification for no longer than is necessary for the purposes for which it is processed.
National statutory periods override the GDPR default whenever a legal obligation requires retention — German HGB §257 (6–10 years), Polish Ordynacja podatkowa Art. 86 (5 years), Lithuanian accountancy law (10 years).
Retention is per data category, not per activity — transactional records, contact data, consent records, and support transcripts each have their own driver.
Three trigger types cover almost every case — event, calendar, and condition — and the schedule names the trigger per category alongside the period.
Deletion is a method, not an aspiration — hard delete, tombstone-and-purge, field redaction, or aggregation; the schedule names which one applies and the deletion log evidences that it ran.
1. Storage limitation in practice
Article 5(1)(e) GDPR is the storage-limitation principle: 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. Two operative phrases do all the work — "no longer than necessary" and "for the purposes for which the personal data are processed" — and both bind retention to the specific processing activity.
What this rules out is the default-forever posture most small businesses arrive at without a schedule. "Keeping data in case we need it later" is unlawful unless an actual purpose justifies the keeping; "keeping data because the database does not have a delete script" is a technical-debt problem that maps directly to a regulatory problem. The discipline the regulation enforces is the inverse default: data is retained for a defined period because a defined purpose justifies it, and falls out of retention when that purpose is met.
The three things every retention schedule has to do substantively, irrespective of format:
Tie each retention period to a purpose.Tax retention is tied to Article 6(1)(c) compliance with a legal obligation; warranty retention is tied to Article 6(1)(b) performance of the contract; marketing retention is tied to Article 6(1)(a) consent. The purpose drives the period, not the other way around.
Specify a deletion method per category.Hard delete, tombstone-and-purge, field redaction, or aggregation. A category with no method is a category with no deletion.
Evidence that deletion runs. A deletion log (timestamp, record-identifier hash, method) for the supervisory authority to spot-check on request. Article 5(2) accountability lives or dies on this.
2. Why retention is per data category
A processing activity rarely has one retention period because the data within it rarely has one purpose. A customer order activity is the canonical example — four distinct retention drivers run in parallel inside it:
Transactional records (invoice number, order line items, total, tax breakdown) — driven by statutory tax law. 6–10 years from the end of the fiscal year, depending on country.
Shipping and contact data (delivery address, phone for delivery confirmation) — driven by the customer relationship. Active relationship plus 1 year, then deleted unless converted to a different activity.
Marketing consent records (opt-in evidence, preference settings, withdrawal log) — driven by Article 5(2) accountability for the consent. Until consent is withdrawn, plus a withdrawal-audit period of typically 3 years.
Customer support transcripts tied to the order — driven by warranty or service-quality purposes. Warranty period plus 1 year is the common SMB norm; longer for regulated services.
Treating the activity as a single retention block fails in two directions at once: shipping addresses get retained for 7 years after the customer relationship ended, which is unlawful storage limitation; transactional records get deleted at 18 months because that is the "customer relationship" default, which is unlawful tax non-compliance. Per-category retention is the shape that makes both lawful at once.
3. The trigger taxonomy — event, calendar, condition
Every retention period needs a start moment. Three trigger types cover almost every case — the schedule names which one applies per data category, alongside the period itself.
The retention clock starts at a specific moment — typically the end of the active relationship. Common examples: customer account closed (start of retention from closure date), employment terminated (start from last working day), contract terminated (start from termination date). Event triggers are the cleanest to operate because the start moment is unambiguous and machine-detectable; the failure mode is the trigger event happening without the system noticing, leaving the record in active retention indefinitely.
Calendar trigger
End of fiscal year, end of tax year, end of warranty period
The retention clock starts at a fixed periodic boundary. Statutory tax retention typically uses calendar triggers — Polish Ordinacja podatkowa Art. 86 starts the 5-year clock from the end of the calendar year in which the tax obligation arose; German HGB §257 similarly counts from the end of the financial year. Calendar triggers are predictable but can over-retain by up to a year compared to event triggers; that over-retention is generally accepted as proportionate to the legal certainty calendar dating provides.
Condition trigger
Consent withdrawn, objection raised, subject inactive for N years
The retention clock starts when a state changes — consent record transitions from given to withdrawn, marketing-objection processed, customer inactive for the threshold defined in the schedule. Condition triggers are the most flexible and the hardest to operate because they require ongoing evaluation of the underlying state. The supervisory authority expectation is that condition triggers run at least nightly across the affected datastores; manual quarterly sweeps are accepted only for low-volume categories.
4. Statutory overrides — DE, PL, LT
Where national law imposes a retention obligation, that obligation overrides the GDPR storage-limitation default. The retention schedule references the specific provision per country, not a generic "as required by law" clause that gives the supervisory authority nothing to verify against.
Tax-relevant records, counted from the end of the calendar year in which the deadline for paying the tax expired.
Poland
Kodeks pracy (post-2019)
10 years
Employee personnel files for employment relationships established or transitioned post-2019; older files may run to 50 years unless ZUS reporting moves them to 10.
Lithuania
Buhalterinės apskaitos įstatymas (Accountancy Law)
Personal employment files retain for the statutory period applicable at the time of file opening; current regime trends shorter, historic files retained on the original timeline.
Note: the table summarises the recurring statutory drivers an SMB encounters; sector-specific laws (financial services, healthcare, gambling, regulated professions) impose additional periods. The retention schedule cross-references the specific law each entry relies on, so counsel can verify against the current consolidated text.
5. The deletion-method ladder
Article 5(1)(e) requires deletion when retention ends — but does not specify how. Four methods cover the shapes that survive an audit. The schedule names which one applies per data category, and the deletion log evidences that the method runs.
1
Hard delete
Best for: Standalone records, account-scoped data, single-subject documents
The row, file, or document is removed from the live datastore. The deletion is logged (deletion timestamp, record identifier hash, deletion method) for accountability under Article 5(2). Hard delete is the cleanest method where the system supports it without breaking referential integrity; the failure mode to watch for is foreign-key dependents that block the delete and silently leave the record in place.
2
Tombstone + purge
Best for: Linked records where referential integrity matters
The record is marked deleted (a flag, a soft-delete timestamp) and removed from active queries, then physically purged from the datastore at the next scheduled purge run. The supervisory authority accepts tombstoning as deletion provided the purge actually runs and the purge cadence is documented; what is not accepted is indefinite tombstoning where the data physically remains.
3
Field redaction in place
Best for: Audit logs, multi-subject records, statute-required artefacts
The identifying fields (name, email, address) are nulled or replaced with hash placeholders while the surrounding record (transaction summary, audit context, statistical data) is preserved. Used where the surrounding record itself is required for retention reasons (audit trail, statutory transaction record). The redaction must be irreversible — replacing identifiers with values that can be looked up elsewhere does not satisfy storage limitation.
4
Anonymisation to aggregates
Best for: Analytical and reporting datastores
Row-level personal data is collapsed into aggregates (counts, sums, distributions) at the moment of expiry. The aggregates are no longer personal data under Article 4(1) and fall outside GDPR. The bar is high: the aggregates must satisfy the EDPB Opinion 28/2024 tests — no singling-out, no linking, no inference. Aggregation is the longest-lived deletion method and the right choice where business need persists past the personal-data retention.
Skip the drafting
A counsel-redlinable retention schedule with country-specific statutory periods built in.
CookieSentry generates the Data Retention Policy with per-category retention, named statutory drivers (DE HGB §257, PL Ordynacja podatkowa, LT accountancy law), trigger-type per category, and a deletion-method ladder mapped to your processing activities — derived from the same ROPA source that produces your privacy policy and DPA list. Bilingual EN + DE / PL / LT.
Backups are operationally separate from primary data but legally in scope of GDPR. The supervisory authority position, consistent across multiple decisions: deletion from the primary system combined with a documented backup lifecycle is sufficient. What is not sufficient is the controller having an indefinite backup of personal data already deleted from primary, with no eviction date.
The surviving practice has three components, all of which belong in the retention schedule:
Backup retention period stated alongside the primary retention. Typical pattern: incremental daily backups retained 30 days, weekly backups retained 90 days, monthly snapshots retained 12 months, archive snapshots retained per the longest applicable statutory period.
Backup-on-restore commitment. Where a backup is restored after a primary deletion, the schedule commits the controller to re-running the deletion against the restored data within a defined window — typically 5 working days. The restore is the event that re-triggers the deletion runtime.
Backup-tested DSAR / erasure handling.When a data subject exercises Article 17 erasure, backups within the standard rotation cycle are not individually scrubbed (which would break backup integrity) — instead, the schedule commits the controller not to restore any backup containing the erased data without re-running the erasure first. This is the supervisory-authority-accepted compromise.
7. Anonymisation as the longest-lived deletion
Anonymisation transforms personal data into something that no longer identifies a person — and therefore falls outside the GDPR entirely under Article 4(1). It is the mechanism that lets a controller retain analytical or statistical value past the personal-data retention period without breaking storage limitation.
EDPB Opinion 28/2024 (consolidating the WP29 Opinion 05/2014 framework) sets three cumulative tests anonymisation must pass:
No singling out.It must not be possible to isolate an individual's record from the dataset.
No linking. It must not be possible to link two or more records concerning the same individual.
No inference. It must not be possible to deduce, with significant probability, information concerning an individual.
Pseudonymisation — replacing direct identifiers (names, email addresses) with reversible tokens or stable hashes — does not meet the tests. Pseudonymised data remains personal data under Article 4(5); retention is still bound by Article 5(1)(e) and the data still belongs to the subject. The honest answer for most SMB use cases is that row-level retention will be pseudonymised at best, and real anonymisation requires aggregation — counts, sums, distributions — that no longer carries the individual forward.
Where it works, anonymisation is the cleanest long-term outcome: the operational signal survives, the personal data does not, and the schedule documents the anonymisation method as the deletion mechanism.
8. What the retention schedule contains
Retention dates are recorded primarily in the ROPA under Article 30(1)(f), but a separate retention schedule document is the operational artefact — read by staff who implement the deletion, by counsel who reviews the posture, and by the supervisory authority who audits. Eight columns cover the schedule:
Processing activity — the activity from the ROPA the row belongs to.
Data category — the specific category within the activity (transactional, contact, consent, support, etc.).
Retention driver — the legal or operational basis for the period (named statute, contractual purpose, accountability requirement).
Trigger type — event, calendar, or condition.
Trigger event — the specific moment that starts the clock (account closure, end of fiscal year, consent withdrawal).
Retention period — the duration from trigger.
Deletion method — hard delete, tombstone-and-purge, redaction, anonymisation.
Owner — the role responsible for ensuring the deletion runs (typically the operations lead or the data protection contact for SMBs).
The CookieSentry-generated retention schedule is one row per data category, with the eight columns populated against the controller's country and processing activities. The deletion log is a separate operational artefact maintained by the controller and reviewed periodically against the schedule.
9. Country notes — DE, PL, LT
Germany — BfDI and Landesdatenschutzbehörden
German supervisory authorities have published multiple decisions where retention failures clustered in two areas: HR records over-retained relative to the post-employment period required by tax and labour law (10 years is common but not universal — pension-related obligations can extend, while many ordinary HR records do not), and customer-database over-retention where no deletion mechanism existed at all. The Bavarian BayLDA framework explicitly asks for the named statute per retention period, not a generic legal-obligation reference. Berlin BlnBDI has fined for indefinite backup retention without a documented lifecycle.
Poland — UODO
UODO inspections frequently surface the post-2019 Kodeks pracy transition in HR records — files opened pre-2019 follow the historic 50-year retention unless ZUS reporting moves them to 10, and files opened from 2019 follow the 10-year regime. The schedule has to make the cohort visible. UODO has been particularly active on the marketing-consent question: where consent has been withdrawn, the controller must delete the substantive data and retain only the withdrawal-audit record — silent over-retention of the underlying email address is a recurrent finding.
Lithuania — VDAI
VDAI has published guidance on the deletion-evidence question — the controller must be able to demonstrate that deletion runs, not merely that it is scheduled to run. The deletion log (per-record timestamp, identifier hash, method) is the artefact VDAI requests in cross-border audits and inspections. Lithuanian accountancy law's 10-year retention is the most common statutory driver in the SMB schedules VDAI reviews.
10. Penalties under Article 83
Failures of the storage-limitation principle fall under the higher fining tier of Article 83(5): up to €20 million or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher, because Article 5 is in the higher tier's scope. The headline figure rarely lands on SMBs, but Article 5(1)(e) is the principle most often cited in the cumulative findings supervisory authorities issue across multi-article enforcement decisions.
For SMBs the practical risk is the compounding pattern: absent retention schedule, absent deletion mechanism, inability to evidence either, and an over-retained customer database that surfaces during a DSAR or breach response. Each becomes its own administrative finding and they pile up into a five-figure number that a small business cannot absorb. The schedule, the deletion log, and a dated change history are the durable defenses — and all three are operational rather than legal artefacts once the schedule itself is in place.
11. Frequently asked questions
What does "storage limitation" actually require us to do?+
Article 5(1)(e) GDPR requires personal data to 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. The operative word is "necessary" — measured against the purpose of the specific processing activity, not against company convenience. Two consequences: every retention period must be tied to a specific purpose and reviewed against it, and "keeping data just in case" is unlawful unless an actual purpose justifies the retention. The discipline is one retention rationale per category, not one company-wide retention period across all data.
How does GDPR retention interact with national tax and accounting law?+
Statutory retention periods set by national law override GDPR's storage-limitation default whenever the controller has a legal obligation to retain. Germany's HGB §257 and AO §147 require commercial books and tax-relevant records to be kept for 10 years (HGB) or 6 years (AO) depending on document class. Polish Ordinacja podatkowa Article 86 imposes a 5-year retention on tax-relevant records counted from the end of the calendar year in which the tax obligation arose. Lithuanian accountancy law similarly fixes retention for accounting records. The lawful basis for the override is Article 6(1)(c) — compliance with a legal obligation — and the GDPR retention schedule must reference the specific national provision driving each statutory period.
Can we keep customer data forever if we anonymise it first?+
Yes — anonymised data falls outside the GDPR entirely, because it is no longer personal data under Article 4(1). The bar for genuine anonymisation, however, is high. EDPB Opinion 28/2024 (which builds on WP29 Opinion 05/2014) sets three tests: it must be impossible to single out an individual, impossible to link records together, and impossible to infer information about an individual. Pseudonymisation — replacing direct identifiers while retaining linkage — does not meet the test; the data remains personal under Article 4(5). The honest answer for most SMB use cases is that aggregation (counts, sums, distributions) safely escapes GDPR; anything that retains row-level detail almost certainly does not.
How granular should retention periods be?+
Per data category within each processing activity. A customer order activity typically splits into transactional records (retained for the statutory tax period, 6–10 years depending on country), shipping addresses (retained while the customer relationship is active plus 1 year), marketing-consent records (retained until consent is withdrawn, then a short audit trail), and post-purchase support transcripts (retained for the warranty period plus 1 year). Treating an entire activity with one retention period either over-retains the categories that should expire sooner, or under-retains the categories that statute compels — both are findings.
What's the difference between retention triggers — event, calendar, condition?+
Three trigger types cover almost every case. Event triggers fire on a specific moment (account closure, contract termination, last-login date crossing a threshold) — the retention clock starts at the event. Calendar triggers fire on absolute dates (end of the calendar year for tax records, fiscal year-end for HR) — the retention clock starts at the period boundary. Condition triggers fire when a state changes (consent withdrawn, marketing-objection raised, subject becomes inactive after N years) — the retention clock starts at the state transition. Most SMB activities use a mix; the schedule documents which trigger applies per category.
Do backups have to follow the same retention as primary data?+
Backups are operationally separate but legally in scope. The surviving practice is to document the backup lifecycle in the retention schedule with its own period — typically 30–90 days for incremental backups, longer for archive snapshots — and to commit that the backup rotation will overwrite or destroy expired primary data within that window. EDPB Guidelines 9/2022 and successive supervisory authority decisions accept that primary deletion combined with documented backup expiry is sufficient; what is not sufficient is the controller having an indefinite "backup" of data that has been deleted from the primary system, with no eviction date.
How do we delete data that's intermingled with other records — shared logs, audit trails, multi-subject documents?+
Three durable patterns. First, structural deletion where the system supports it — most modern databases and SaaS tools have either a hard-delete or a tombstone-and-purge capability that covers the data subject's row across linked tables. Second, redaction in place where the surrounding record must be retained for legal reasons (e.g. an order audit log where the customer's identifying fields are nulled but the transaction summary remains). Third, transitioning to anonymised aggregates where individual-level retention is no longer necessary but aggregate analytics is. The retention schedule names the deletion method per category — what is not acceptable is a category with no deletion method specified.
What if we miss the deletion deadline on a specific record?+
Missing a deletion deadline by a few weeks is not, by itself, a fineable offence in any of the supervisory authority enforcement patterns we see. What is fineable is the absence of a documented retention schedule, the absence of a deletion mechanism, or the inability to evidence that deletion runs at all. The defensible response when the deadline is overshot is to document the cause, run the deletion, and record the corrective action — the documented near-miss is hygiene; silence is the violation. A controller that can show the schedule, the deletion log, and a documented response to a missed window defends well.
Is the retention schedule a separate document from the ROPA?+
Yes and no. The retention dates per activity per data category are recorded in the ROPA under Article 30(1)(f), and that record is the legal source of truth. A separate retention schedule document exists to expose the rationale to staff, to make the schedule actionable for the operations team, and to give counsel a single review surface — but the dates in the schedule must equal the dates in the ROPA, and updates land in the ROPA first. CookieSentry generates both documents from the same source so consistency is automatic; maintaining the two independently is what produces the contradictions auditors notice.
What about data we collected on consent — can we keep it after consent is withdrawn?+
Once consent is withdrawn, the lawful basis for the underlying processing falls away and the data must be deleted — Article 7(3) makes withdrawal effective immediately for future processing. Two narrow continuing-use grounds remain: a separate audit trail of the consent itself (the fact of consent, the date, the channel, and the withdrawal) is retained on the basis of Article 5(2) accountability, and any data covered by a different lawful basis (e.g. a transactional record covered by Art. 6(1)(c) tax retention) continues under that basis. The substantive personal data covered only by consent is deleted; the consent receipt record persists for as long as accountability requires.
How long do we keep DSAR responses, breach records, and other compliance artefacts?+
Compliance artefacts have their own retention drivers, separate from operational data. Breach register entries are retained for at least five years from closure (the supervisory authority looks back across multiple years to spot patterns). DSAR log entries are retained for the limitation period of complaints to the supervisory authority plus a margin — typically three years for SMB, five for regulated industries. ROPA change logs and consent receipts are retained for as long as the underlying processing continues plus the limitation period. The full copy of a DSAR export sent to a subject is generally not retained after delivery — that is the subject's data, not the controller's record.
Are German, Polish, and Lithuanian retention rules different?+
The GDPR storage-limitation principle is uniform across the EU; the statutory overrides are not. Germany has the longest commercial-records retention (HGB §257: 10 years for accounting records, contracts, and trade letters), with HR records typically retained for 6 years post-termination under tax law and longer where pension obligations apply. Poland's Ordinacja podatkowa Article 86 sets 5 years for tax-relevant records (counted from year-end), with HR records under Kodeks pracy at 10 years post-2019 (50 years for files opened before 2019 unless ZUS reporting moves them to 10). Lithuania's accountancy law sets 10 years for accounting records, with HR record-retention under VDI labour code at 50 years for personal files in the historic regime, transitioning to shorter periods. The retention schedule references the specific provision per country, not a generic "as required by law" clause.
The schedule that closes the GDPR document set
The Data Retention Policy, the per-category schedule, the country-specific statutory drivers, the trigger taxonomy, and the deletion-method ladder all ship in your CookieSentry GDPR pack alongside Privacy Policy, Cookie Policy, ROPA, DPA, Breach Procedure, and DSAR Procedure. Generate, redline with counsel where you want, ship.
This guide summarises GDPR Articles 4, 5, 6, 17, 30, 83, EDPB Opinion 28/2024, and the named national statutes (German HGB, AO; Polish Ordynacja podatkowa, Kodeks pracy; Lithuanian accountancy and labour law) for orientation. It is a practical reference, not legal advice; the application of these provisions to a specific schedule depends on facts only counsel familiar with your jurisdiction can assess. CookieSentry templates are drafted to current EU and national law and are intended for review by qualified counsel before publication.