Deleting data is a GDPR duty of its own. Storage limitation (Art. 5(1)(e)) says personal data may be kept only as long as its purpose requires, and the right to erasure (Art. 17) forces deletion once specific triggers are met. At the same time, German commercial and tax law, among other regimes, requires you to keep some of the same records for years. A Löschkonzept resolves this conflict: fixed deletion rules per data type, with periods, triggers and owners. Supervisory authorities are paying close attention right now: since March 2025 the European Data Protection Board has been running a Europe-wide coordinated enforcement action on the right to erasure. This guide shows what the law requires, which retention periods override deletion, and how to build the concept step by step.
- Storage limitation (Art. 5(1)(e)) and the right to erasure (Art. 17) require an active deletion routine, not a one-off cleanup.
- Statutory retention periods (e.g. HGB, AO) override deletion until they expire. In the meantime the data is restricted (Art. 18), not actively used.
- A Löschkonzept turns deletion into fixed rules per data type - period, trigger, owner - instead of case-by-case decisions.
What Is a Löschkonzept and Why Do I Need One?
Isn't deleting on request enough?
No. The right to erasure is only one trigger among several: personal data must also be deleted when the purpose for which they are processed is fulfilled, when consent (where given) is withdrawn, when a valid objection under Art. 21 stands, or when the processing was unlawful in the first place (Art. 17(1)). Storage limitation makes this an ongoing duty, not an annual cleanup. An auditor's question is concrete: which data do you delete, when, and can you show it happened? Ad-hoc answers fail that test; a documented routine passes it. The Löschkonzept is that routine in writing.
It is also the piece your other documentation already points to. Every entry in your Record of Processing Activities names a retention period, and your privacy notice must disclose retention criteria (Art. 13(2)(a)). The Löschkonzept is the system behind those statements.
When Does a Retention Obligation Override Deletion?
Which data must I keep even when deletion is requested?
Art. 17(3)(b) contains one key exception: no erasure while processing is necessary to meet a legal obligation. In Germany that mainly means the statutory retention periods of commercial and tax law: annual financial statements and books are kept for 10 years, accounting records and invoices for 8 years (reduced from 10 as of 2025; banks and insurers remain at 10 years), and commercial correspondence for 6 years (§ 257 HGB, § 147 AO, § 14b UStG). Further statutory retention duties may apply and must be checked per processing purpose (e.g. anti-money-laundering law, social security law).
Next to it stands a second, equally central exception: Art. 17(3)(e) permits retention for the establishment, exercise or defence of legal claims. This is what typically justifies keeping contract, invoice and customer data until the civil limitation period expires (§ 195 BGB, generally three years; longer for warranty and liability claims).
The common middle case has its own mechanism. The original purpose has lapsed, but a retention period still runs: the answer is restriction of processing (Art. 18). The data is blocked, kept only for the retention purpose, and excluded from active use. Restriction is not optional: continuing to use data you only hold under a retention obligation is in turn a violation.
Building the Concept: Data Types, Deletion Classes, Deletion Rules
How do I turn the law into working rules?
The established method comes from ISO/IEC 27555, the international successor of the German DIN 66398 guideline: group your data types into deletion classes that share a retention period and a start trigger, then define one deletion rule per class - period, trigger, owner. The point of classes is scale: an SME holds dozens of data types but usually needs fewer than ten deletion classes, so ten rules cover everything.
| Data type | Deletion rule | Start trigger | Legal anchor |
|---|---|---|---|
| Applicant data (rejected candidates) | Delete after 6 months | Rejection sent | Art. 17(1)(a); AGG claim window (common German practice) |
| Invoices and accounting records | Delete after 8 years | End of the calendar year of issue | § 147 AO, § 14b UStG via Art. 17(3)(b) |
| Newsletter contacts (opt-in) | Delete on unsubscribe; a minimal suppression entry may remain to honour the opt-out permanently | Consent withdrawn (Art. 7(3)) | Art. 17(1)(b); Art. 21 applies only where marketing rests on legitimate interest |
| Personnel file after departure | Delete after 3 years; payroll and tax-relevant parts after 6-10 years | End of the employment year | § 195 BGB via Art. 17(3)(e); § 147 AO via Art. 17(3)(b) |
| IT-security logs | Delete after up to 90 days (documented justification) | Log creation | Art. 6(1)(f) security interest |
| General access and operational logs | Delete after 7-30 days | Log creation | Art. 5(1)(e) |
Read each row as one deletion class: the same pattern extends to every data type in your ROPA.
Building Your Löschkonzept, Step by Step
Where do I start?
1. Start from your ROPA. Every entry already carries a retention period. Group entries with the same period and start trigger into deletion classes.
2. Define one rule per class. Retention period, start trigger, and a named owner who executes the deletion and logs it.
3. Include backups and archives. A concept that covers only production systems is a classic audit finding. Define how deletion reaches backups, for example through rotation cycles and re-deletion after a restore.
4. Restrict what you must keep, delete the rest, and log it. Data under a statutory retention period is blocked (Art. 18); everything past its rule is deleted, and the deletion is recorded as proof. A third option is anonymisation: data that is fully and irreversibly anonymised falls outside the GDPR and may be kept, for example for statistics (Recital 26 GDPR). Pseudonymisation is not enough for this.
Löschkonzept Template (Excel)
How do I keep it current?
Review the concept whenever a new tool, data type or process arrives - the same trigger that updates your ROPA - plus one full review per year. The rules only protect you while they match reality.
the platform keeps retention periods next to each ROPA entry, reminds the named owner when a rule falls due, and your external DPO reviews the Löschkonzept before an authority does. Start with the free compliance check to see where your deletion routine stands today.