Data Deletion Policy Under DSGVO (GDPR): Retention Periods, Deletion Rules and Implementation

Why a Deletion Policy Is Mandatory

Personal data must not be stored forever. That sounds self-evident, but in practice it is one of the most commonly neglected data protection principles. Many companies accumulate data for years without ever systematically reviewing whether the storage is still justified. The GDPR takes a different view.

Art. 5(1)(e) GDPR establishes the principle of storage limitation: personal data must be kept in a form that permits identification of data subjects only for as long as is necessary for the purposes for which the data are processed. Once the processing purpose ceases and no statutory retention obligation remains, the data must be deleted.

Art. 17 GDPR supplements this principle with the right to erasure, often referred to as the "right to be forgotten." Data subject rights such as access, erasure and data portability allow individuals to request the deletion of their data when one of the grounds listed in Art. 17(1) applies. The most common case: the data are no longer necessary for the purposes for which they were collected.

A deletion policy is the tool you use to implement these requirements systematically. It defines what data you hold, how long you may or must retain it, when and how it is deleted, and who is responsible. Without such a policy, implementation of the storage limitation principle is left to chance — and that is exactly the problem that supervisory authorities routinely criticize.

The German Conference of Independent Data Protection Supervisory Authorities has repeatedly emphasized that a documented deletion policy forms part of the accountability obligation under Art. 5(2) GDPR. You must not only delete, but also be able to demonstrate that you do. The data protection officer also monitors compliance and advises on implementation. The absence of a deletion policy is therefore not merely an organizational shortcoming — it is a compliance violation that can result in fines.

Retention Periods at a Glance

Before you can delete, you need to know how long you may — or even must — store data. In addition to the storage limitation principle, there are numerous statutory retention obligations that take precedence over deletion. These obligations prevail: as long as a statutory retention period is running, you must not delete the data concerned, even if the data subject requests it.

The most important retention periods under German law:

Commercial Retention Obligations (HGB)

Under Section 257 HGB, commercial books, inventories, opening balance sheets, annual financial statements, management reports and group reports must be retained for 10 years. Commercial and business correspondence as well as accounting vouchers are subject to a 6-year period. The period begins in each case at the close of the calendar year in which the last entry was made, the financial statement was prepared, or the business letter was received or sent.

In practice this means: an invoice dated 15 March 2026 must be retained until 31 December 2036. It may be deleted from 1 January 2037.

Tax Retention Obligations (AO)

Section 147 AO contains virtually identical periods to the HGB: 10 years for books and records, accounting vouchers, annual financial statements and inventories; 6 years for commercial letters received and sent and other documents relevant for taxation. Important: where a tax audit is ongoing or legal proceedings are pending, the periods are extended until the proceedings have concluded. This so-called suspension of limitation under Section 171 AO must be reflected in the deletion policy.

Employment Law Retention Obligations

The Working Hours Act (ArbZG) requires in Section 16(2) that records of daily working hours be retained for 2 years. Payroll records and social security contribution statements fall under the 6-year tax retention period where they are relevant for taxation.

Application documents of rejected candidates should generally be deleted 6 months after the conclusion of the recruitment process. This period derives from the limitation period under the General Equal Treatment Act (AGG), which is 2 months after receipt of the rejection, plus a reasonable period for assertion and judicial enforcement.

Other Relevant Periods

Retention obligations extend across many areas of law. Some additional important periods:

• Works Constitution Act (BetrVG): Election documents for works council elections must be retained for the duration of the electoral period — in practice 4 years.
• Product Liability Act: Product documentation obligations apply for 10 years from the date the product was placed on the market.
• Building law: Construction files and structural calculations must be retained for 5 to 30 years depending on the state building code.
• Medical law: Medical records must be retained for 10 years after the conclusion of treatment under Section 10 of the Model Professional Code.
• Anti-Money Laundering Act (GwG): Records under Section 8 GwG must be retained for 5 years after the end of the business relationship.

The retention period defines the earliest possible deletion date, not the latest. Once the period has expired and no other legal basis justifies further storage, deletion must take place. This is the critical point that many companies overlook: the period is not a license for unlimited storage, but a time-limited exception to the deletion principle.

Defining Deletion Classes and Deletion Rules

A deletion policy that treats every single data category separately will fail in practice. No company can individually monitor hundreds of different retention periods. The solution is to group data types with comparable retention periods and deletion requirements into deletion classes.

What Is a Deletion Class?

A deletion class groups data types that share the same retention period and the same deletion rule. For each deletion class you define:

• Name: A descriptive label that identifies the class (e.g., "accounting vouchers," "applicant data," "working hours").
• Included data types: Which specific data belong to this class?
• Legal basis for retention: Which law mandates retention?
• Retention period: How long must the data be retained at minimum?
• Period start: When does the period begin (end of calendar year, end of business relationship, completion of the process)?
• Deletion rule: What exactly happens after the period expires?
• Responsible party: Which person or role is responsible for carrying out the deletion?

Example Deletion Classes for a Mid-Market Company

Deletion class 1: Accounting vouchers (10 years) Contains invoices, bank statements, accounting vouchers, annual financial statements. Legal basis: Section 257 HGB, Section 147 AO. Period start: end of the calendar year in which the voucher was created or received. Deletion rule: complete deletion of all digital copies and destruction of physical documents per DIN 66399.

Deletion class 2: Business correspondence (6 years) Contains commercial and business letters, quotations, order confirmations, general business correspondence. Legal basis: Section 257 HGB, Section 147 AO. Period start: end of the calendar year in which the letter was sent or received.

Deletion class 3: Personnel files after departure (3 years + variable) Contains employment contracts, references, warnings, salary records. Legal basis: limitation periods under the German Civil Code (BGB), tax retention obligations. Period start: end of the calendar year in which the employment relationship ended. Deletion rule: complete deletion after expiry of the longest applicable period.

Deletion class 4: Applicant data (6 months) Contains application documents, interview notes, test results of rejected applicants. Legal basis: Section 15 AGG (limitation period), Section 26 BDSG. Period start: receipt of rejection. Deletion rule: complete deletion of all documents and interview notes.

Deletion class 5: Working hours records (2 years) Contains timesheets, electronic time-tracking data, overtime records. Legal basis: Section 16(2) ArbZG. Period start: date of recording.

Deletion class 6: Contract data after contract end (3 years standard, 10 years tax-relevant) Contains customer contracts, supplier contracts, service agreements. Legal basis: limitation periods under BGB, HGB, AO. Period start: end of the calendar year in which the contract ended.

Deletion class 7: Log data and log files (6 months) Contains access logs, firewall logs, server logs with personal data. Legal basis: Art. 6(1)(f) GDPR (legitimate interest in error analysis and attack detection). Period start: creation of the log entry.

Deletion class 8: Newsletter subscribers (until withdrawal) Contains email addresses and consent records for newsletters. Legal basis: Art. 6(1)(a) GDPR. Deletion rule: deletion after withdrawal of consent. The consent records themselves must be retained longer (proof obligation).

Formulating Deletion Rules

Each deletion class needs a clear deletion rule that describes what concretely happens after the retention period expires. A deletion rule answers four questions:

1. What is deleted? (Which data, in which systems, in which formats?)
2. When is it deleted? (After which period expires, at which review date?)
3. How is it deleted? (Technical method: deletion, overwriting, anonymization, destruction?)
4. Who carries out the deletion and who approves it?

A deletion rule for the "applicant data" class might read: "6 months after receipt of the rejection, all application documents, interview notes and test results of the applicant are deleted from the applicant management system, from the email inboxes of the involved managers and from local storage locations. The HR department carries out the deletion. The deletion is recorded in the deletion log."

Deletion Routines and Responsibilities

A deletion policy that exists only on paper is worthless. Implementation requires clear responsibilities and fixed routines embedded in day-to-day operations.

Roles in the Deletion Process

Data owner: The business unit that collects and uses the data is typically also responsible for deletion. Sales owns customer data, the HR department owns personnel files, accounting owns accounting vouchers. The data owner decides whether the retention period has expired and whether a deletion impediment exists.

IT department: Carries out the technical deletion or provides the tools for it. IT ensures that deletion is complete — not just in the primary database, but also in backups, replicas, archives and test systems.

Data protection officer: Monitors compliance with the deletion policy, advises in doubtful cases and reviews the deletion logs. The DPO has no operational deletion responsibility but a supervisory function.

Management: Approves the deletion policy and provides the necessary resources. Management bears overall responsibility for GDPR compliance.

Setting Review Cycles

Deletions should not be event-driven but carried out regularly and systematically. A quarterly review cycle has proven effective: each quarter, the data owner checks whether data in their deletion classes have exceeded the retention period and initiates deletion.

For data types with short periods (e.g., log files with a 6-month retention period), a monthly or even weekly cycle may be appropriate — ideally automated. For data types with long periods (e.g., accounting vouchers with 10 years), an annual review run is sufficient.

The review cycle should be anchored in the company calendar with fixed dates and clear deadlines. If the review only takes place when someone remembers, it will eventually be forgotten.

Technical Implementation: Automated vs. Manual

The technical implementation of deletion depends heavily on which systems you use and how data are stored within them. There are fundamentally three approaches, which are usually combined in practice.

Automated Deletion

Many systems offer the ability to configure retention periods and automatically delete data after expiry. Email servers can archive or delete old emails after a defined time span. Log management systems like Elasticsearch or Graylog support retention policies. CRM systems can automatically anonymize customer data after the end of the business relationship and expiry of the retention period.

Automated deletion is the gold standard because it minimizes human error and works consistently. However, it requires that systems provide the necessary features and are correctly configured.

Semi-Automated Deletion

Many companies use a middle ground: a system regularly generates deletion lists — overviews of records whose retention period has expired. An employee reviews the list, confirms that no deletion impediments exist (e.g., ongoing litigation or tax audits), and approves the deletion. The deletion then proceeds automatically.

This approach combines the efficiency of automation with the safety of manual review. It is especially suitable for data types where deletion impediments are more common, such as contract data or tax-relevant documents.

Manual Deletion

For data stored in unstructured locations (network drives, local hard disks, physical folders), manual deletion is often the only option. The data owner searches the storage, identifies data ready for deletion, and deletes them. Physical documents are destroyed per DIN 66399, with the security level depending on the confidentiality of the data — guidance on this can also be found in the article on secure disposal of hardware and documents.

Manual deletion is error-prone and labor-intensive. Therefore, you should try to keep data in structured systems as much as possible that enable automated or semi-automated deletion.

Special Challenge: Backups

Backups are a notorious problem in deletion policies. When you delete a record in the production database, it is typically still present in one or more backups. These backups have their own lifecycle: daily backups may be retained for 30 days, weekly backups for 3 months, monthly backups for 1 year.

The common practice is that deletions are not individually tracked in backups, because this would be extremely complex technically. Instead, it is accepted that deleted data may still be present in backups until the backup is overwritten or deleted on schedule. The backup policy should therefore be aligned with the deletion policy. This approach must be documented in the deletion policy and defensibly justified to the supervisory authority.

Important: backup retention periods should be kept as short as possible. A backup retained for 7 years undermines any deletion policy.

Logging Deletions

Every deletion must be verifiable. That sounds paradoxical — you are supposed to prove that data no longer exists. But that is exactly what the GDPR's accountability principle demands: you must document that you have deleted.

Mandatory Information in the Deletion Log

A deletion log should contain at least the following information:

• Date of deletion: When was it deleted?
• Deletion class and data type: Which data were deleted?
• Number of deleted records: How many records were affected?
• Affected systems: In which systems was data deleted?
• Deletion method: How was it deleted (automated, manual, destruction)?
• Responsible person: Who carried out or approved the deletion?
• Legal basis for deletion: Why was it deleted (period expiry, withdrawal, deletion request)?
• Deletion impediments: If data were not deleted — why not?

What the Deletion Log Must Not Contain

The deletion log must not contain information that allows conclusions about the deleted data. You document "42 applicant records from 2025 deleted," not the names of the applicants. Otherwise, you would not have truly deleted the personal data, but merely moved them.

Retention of Deletion Logs

The deletion logs themselves must be retained to provide evidence in case of a supervisory complaint or audit. A retention period of 3 years is standard practice, aligned with the general limitation periods.

Practical Example: Deletion Policy for a 100-Employee Company

Let us examine what a pragmatic deletion policy might look like for an SME with 100 employees. The company is an IT service provider based in Germany, with B2B customers, its own accounting department, and a typical IT landscape comprising an ERP system, CRM, email, file server and applicant management software.

Step 1: Create a Data Inventory

The first step is to take stock of all personal data. Ideally, you use your existing record of processing activities under Art. 30 GDPR as a basis. Each processing activity already contains details on the processed data categories and the retention periods.

The company identifies the following key data holdings:

• Customer master data and contract data (CRM and ERP)
• Invoices and accounting vouchers (ERP and Datev)
• Business correspondence (email and file server)
• Personnel files and payroll records (HR system and file server)
• Application documents (applicant management software and email)
• Working hours records (time-tracking system)
• Access logs and server logs (SIEM and log server)
• Website analytics (Matomo, self-hosted)
• Newsletter subscribers (email marketing tool)

Step 2: Assign Deletion Classes

The inventory yields 9 deletion classes following the patterns described above. The company documents the retention period, period start, affected systems and responsible department for each class.

Step 3: Define Deletion Methods and Automation

For each deletion class, a decision is made on whether deletion is automated, semi-automated or manual.

Automated: Log files (retention policy in the SIEM), website analytics (Matomo setting), applicant data (automatic deletion in the applicant tool after 180 days). The IT department configures the systems accordingly and reviews the configuration annually.

Semi-automated: Accounting vouchers (annual deletion list from ERP, approved by head of accounting), business correspondence (archiving policy in the email system, annual file server review), customer contract data (quarterly deletion list from CRM).

Manual: Personnel files (semi-annual review by HR), email inboxes of managers regarding applicant data (quarterly reminder from HR).

Step 4: Review Cycle and Calendar

The company establishes the following fixed dates:

• Monthly: Automated deletion of log files and website data is checked for correct functioning (spot-check by IT).
• Quarterly: HR reviews applicant data in email inboxes. Sales reviews the CRM deletion list. IT reviews log file retention.
• Semi-annually: HR reviews personnel files of departed employees.
• Annually: Accounting reviews the deletion list for accounting vouchers and business correspondence. IT reviews the file server for outdated data. The DPO performs a spot-check across all deletion classes.

Step 5: Set Up Logging

The company maintains a central deletion log in which all completed deletions are recorded. Automated deletions are evidenced through system logs (e.g., log entries from the retention policy). Manual and semi-automated deletions are recorded in a simple form containing the date, deletion class, number of records, systems and responsible person.

The deletion log is stored in the ISMS and is accessible to the DPO and management at all times.

Common Mistakes and How to Avoid Them

Mistake 1: Creating the deletion policy and then forgetting about it. A deletion policy is not a one-time project. When the system landscape changes, a new tool is introduced or a process is restructured, the deletion policy must be updated. Schedule an annual review.

Mistake 2: Miscalculating periods. The most common calculation error: the retention period does not begin on the day the document was created, but typically at the end of the calendar year. An invoice from January 2026 has a 10-year retention period that begins on 31 December 2026 and ends on 31 December 2036.

Mistake 3: Ignoring backups. Data rarely exist in only one location. Check whether deleted data still reside in backups, replicas, archives, test systems or local copies, and document how you handle this.

Mistake 4: Not checking for deletion impediments. Before you delete, you must verify whether a deletion impediment exists. Ongoing litigation, tax audits or pending data access requests can postpone deletion. This check must be part of the deletion process.

Mistake 5: Forgetting physical data. Not all personal data are digital. Paper files, printouts, notes and business cards are subject to the same deletion obligations. Physical documents must be destroyed per DIN 66399 — a regular waste bin is not sufficient.

Mistake 6: Confusing deletion and anonymization. Anonymization is not deletion, but it can be an alternative in certain cases. Anonymized data are no longer subject to the GDPR because they no longer contain a personal reference. However, anonymization must be irreversible. Pseudonymization is not sufficient, because pseudonymized data can be re-linked with the appropriate key.

Linking the Deletion Policy and the Record of Processing Activities

The deletion policy and the record of processing activities under Art. 30 GDPR are closely linked. The record of processing activities already contains information on retention periods per processing activity. The deletion policy specifies these periods and adds the operational implementation.

In practice, it is advisable to maintain the deletion policy as a supplement to the record of processing activities. Each processing activity in the RPA references the corresponding deletion class in the deletion policy. This avoids redundancies and ensures that both documents remain consistent.

When you create a new processing activity in the RPA, you simultaneously check whether it can be assigned to an existing deletion class or whether a new class is required. This process ensures that the deletion policy keeps pace with reality.

Next Steps

Start pragmatically. You do not need a perfect deletion policy on day one, but you need one that works and that you continuously improve. In ISMS Lite, deletion classes, retention periods and deletion records can be documented centrally so that everything is at hand during an audit. Take your record of processing activities as a starting point, group processing activities by retention periods, define deletion classes and set up the first automated deletion routines. Then build out the process step by step — review quarterly, revise annually, update when changes occur.

The deletion policy is not a bureaucratic monster. With 8 to 12 deletion classes, clear responsibilities and a fixed review calendar, you cover the requirements of the GDPR and can demonstrate during an audit by the supervisory authority or an internal audit that you have not only accepted storage limitation as a principle, but also implemented it operationally.

Further Reading

• Record of Processing Activities (RPA) Under Art. 30 GDPR
• Documenting Technical and Organizational Measures (TOMs)
• Data Processing Agreements: Reviewing DPAs and Evaluating Processors
• Reporting a GDPR Data Breach: When, How and to Whom
• Creating an Access Control Policy: Managing Permissions Properly

The GDPR does not require you to know every retention period by heart. It requires you to have a systematic process for determining the correct periods, planning deletion and documenting execution. A sound deletion policy is exactly that process.