GDPR and Backups: How to Handle Deletion Requests in 2026

When we first published this guide in 2020, the intersection of GDPR and backups was a grey area — one that regulators were only beginning to address. Four years later, it is no longer grey. In February 2026, the European Data Protection Board (EDPB) published its landmark Coordinated Enforcement Framework (CEF) report on the right to erasure, drawing on investigations by 32 Data Protection Authorities (DPAs) across the EEA. The findings are clear: erasure compliance is now firmly in regulators' crosshairs — and backup systems are explicitly on the list of concerns.

This updated guide incorporates the latest regulatory guidance, real-world enforcement findings, and practical operational advice for any organisation running backups of personal data. Whether you use ProBackup to protect your SaaS workspace data, or manage backups in-house, this article will help you build a defensible, GDPR-compliant approach.

Why GDPR and backups are a difficult combination

Backups exist precisely because data must not be lost. GDPR's right to erasure exists precisely because data must, in some circumstances, be deleted. These two requirements are structurally in tension, and that tension is not fully resolved by any single piece of guidance — including this one.

The practical difficulty is this: a backup tape or snapshot is designed to be a complete, point-in-time copy of a system's data. Surgically removing one individual's records from that snapshot is often technically impossible without restoring the entire backup, making the deletion, and then re-backing up. That is expensive, slow, and disruptive to the very purpose the backup serves.

GDPR regulators understand this. Their guidance consistently acknowledges the technical constraints. But understanding a constraint is not the same as exempting an organisation from the underlying obligation. The EDPB's February 2026 CEF report noted that difficulties with backup deletion were among the most common compliance failures observed across 764 controllers surveyed — ranging from no procedures at all to reliance on simple overwrite cycles with no documented rationale.

The Legal Framework: What the GDPR actually requires

Article 17: The Right to Erasure ('Right to be Forgotten')

Article 17 GDPR gives individuals the right to request deletion of their personal data when any of the following conditions apply:

• The data is no longer necessary for the purpose for which it was collected
• The individual withdraws consent (where consent was the lawful basis) and there is no other legal ground
• The individual objects to processing and there are no overriding legitimate grounds
• The data was processed unlawfully
• Deletion is required to comply with a legal obligation
• The data was collected in relation to an offer of information society services to a child

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 it is processed. Once the purpose is fulfilled — or where no purpose remains — the data must be deleted or anonymised. This applies equally to live systems and backups.

Article 30: Records of Processing Activities

Your Record of Processing Activities (RoPA) must document the envisaged time limits for erasure of each data category. If your backup retention schedule contradicts the deletion periods in your RoPA, you have a compliance gap that DPAs are specifically looking for.

Article 12(3): The One-Month Timeline

Erasure requests must be acted upon without undue delay and within one month of receipt. Controllers may extend this by a further two months where requests are complex or numerous, provided they inform the data subject of the extension within the first month.

Important: The one-month clock applies to the response — not necessarily to the physical deletion from every storage layer. Transparency about what has been done, and what will be done when, is what the law demands for backup-layer data.

The EDPB's 2026 findings: What regulators now expect

The EDPB's CEF 2025 action on the right to erasure — the results of which were published in February 2026 — is the most authoritative signal yet of what regulators consider compliant practice. Here are the key findings most relevant to backup systems:

Backup handling was a widespread failure

DPAs found a wide spectrum of practices. Some controllers had no procedures at all for erasure in backups. Others relied solely on automatic overwrite cycles with no documented policy or communication to data subjects. The EDPB specifically called out these approaches as inadequate.

The EDPB identified one best-practice model

One approach stood out in the report as exemplary: a controller that, upon reaching a data subject's retention end date, automatically extracted all personal data relating to that individual from all systems, moved it to an access-restricted environment, and permanently deleted it one month later. Some controllers also replaced personal data fields with random characters — achieving functional erasure within the backup structure without restoring the backup.

Anonymisation is often insufficient

Many controllers claimed to anonymise data as an alternative to deletion. DPAs found that most of these techniques were in practice only pseudonymisation — reversible masking that does not prevent re-identification. True anonymisation removes data from GDPR's scope entirely. The EDPB is currently developing new anonymisation guidelines following the CJEU's September 2025 ruling in Case C-413/23P (EDPS v. SRB). These guidelines will be critical for any organisation relying on anonymisation as an erasure alternative.

The volume of erasure complaints is rising

In the Netherlands, 580 complaints in 2024 — 18.6% of all DPA complaints — related to the right to erasure. In Ireland, more than 3,000 erasure complaints have been filed since GDPR came into force. Spain has received over 7,000 such complaints. This is not a niche issue.

Enforcement will intensify in 2026

Multiple DPAs — including CNIL (France), the Portuguese CNPD, and the Swedish IMY — have confirmed that the CEF findings will inform sector-specific inspections and supervisory planning in 2026. Nine DPAs launched or continued formal investigations as part of the 2025 action, with proceedings ongoing in Ireland, France, Portugal, Slovenia, and Germany.

Does a Deletion Request Include Removing Data from Backups?

Yes, but with important practical nuances that regulators have consistently acknowledged.

The Danish Data Protection Authority (Datatilsynet) has stated that deletion from backups is mandatory 'if this is technically possible.' The French CNIL has long held that data deleted from production systems may remain in backups temporarily, provided the organisation clearly communicates this to the data subject in plain language and specifies the retention time.

The UK Information Commissioner's Office (ICO) uses the concept of putting data 'beyond use.' For backup data that cannot be immediately overwritten, this means:

• The backup is not accessed for any operational purpose
• No one can retrieve and use the backed-up data
• The data will be deleted when the backup is next refreshed or overwritten on a documented schedule
• The organisation is transparent with the data subject about this timeline

The ICO also distinguishes between offline archiving and live backups — but critically, archiving offline is still processing under GDPR. It only remains lawful if you can justify it with a lawful basis.

What this means in practice: When you receive a valid deletion request, you should delete the data from your live systems immediately. For backup data, document the earliest point at which the backup containing that data will expire or be overwritten, and communicate this to the data subject. Then ensure the data is not accessed or restored in the interim.

The 'Zombie Record' Problem: What Happens When You Restore a Backup?

The second core problem — and one that has bitten many organisations — is the restoration scenario. Suppose a user's data has been legitimately deleted following an erasure request. Six months later, you suffer a data loss event and restore from a backup that pre-dates the deletion. That user's records are now back in your live system. You are immediately non-compliant.

This is not a hypothetical. It happens routinely in organisations that have not built a deletion-aware restore process.

The Deletion Index: The industry-standard solution

At ProBackup, we have always advised clients to maintain what we call a deletion index. Here is how it works:

• When you action an erasure request, you record a non-identifiable marker (such as a database row ID, a hashed identifier, or an internal record number — not the personal data itself) alongside the date of deletion
• That record is retained for as long as any backup exists that could contain the original data
• Your restore process includes a mandatory post-restore step: run the deletion index against the restored dataset and re-delete any records flagged for erasure
• Document this process in your data protection documentation

This approach was implicitly endorsed in the EDPB's 2026 report, which noted the best-practice examples involved tools that tracked data subject retention end dates and applied automated deletions at the point of expiry.

GDPR-Compliant Retention Periods for Backup Data

GDPR does not prescribe specific retention periods. It requires organisations to justify the period they choose based on the purpose of the data and any applicable legal obligations. The storage limitation principle under Article 5(1)(e) is the controlling rule: keep data no longer than necessary.

In practice, backup retention periods are often shaped by:

• Operational recovery needs: How far back do you realistically need to restore?
• Contractual or regulatory obligations: Do sector-specific rules mandate minimum retention?
• Legal exposure windows: The applicable limitation period for claims in your jurisdiction
• Cost and proportionality: Is the marginal compliance benefit of very long retention worth the increased data protection risk?

Common reference points from other applicable laws (which must be balanced against GDPR's minimisation principle) include:

These are indicative references only. Every organisation must document and justify its own retention schedule in its RoPA. The EDPB's 2026 report specifically criticised controllers for failing to define and document retention periods, calling this one of the seven systemic weaknesses identified across the survey.

Communicating With Data Subjects About Backup Retention

Transparency is a first principle of GDPR. Articles 13 and 14 require controllers to inform data subject (at the point of collection) about the envisaged period for which their data will be stored, or the criteria used to determine that period.

When it comes to backups, this means your privacy notice should not be silent on the subject. The CNIL guidance from 2018 — which remains the most widely-cited practical standard — says organisations must explain in clear and plain language:

• That data has been removed from production systems
• That a backup copy may remain temporarily
• The specific retention time of that backup (or the earliest point at which the backup will expire)

Here is a suggested template paragraph for your privacy notice:

"When we receive a valid request to delete your personal data, we will remove it from all live systems without undue delay. Your data may remain in encrypted backup copies for up to [X weeks/months], after which it will be automatically overwritten or deleted in accordance with our backup retention schedule. During this period, your data is not accessible for any operational purpose and will not be restored to live systems. You will receive a confirmation of deletion from our live systems within [X days] of your request, together with this explanation regarding backup retention."

This level of transparency achieves two things: it satisfies your Article 12 and 13 obligations, and it sets realistic expectations for data subjects that reduce the likelihood of complaints to DPAs.

Practical Compliance Checklist for Backup Systems

Based on the EDPB's 2026 findings and our own experience supporting thousands of clients at ProBackup, here is the operational checklist every organisation should work through:

Documentation

• Your RoPA documents the retention period for every category of backed-up data
• Your backup retention schedule is aligned with (and does not exceed) the deletion periods in your RoPA
• You have a written internal policy describing how erasure requests are handled in the context of backups
• Your privacy notice discloses backup retention timelines in plain language

Process

• You have a formal intake process for erasure requests (verbal or written requests both qualify — no 'magic words' are required by the ICO)
• You verify the identity of the requesting individual before acting
• You delete from live systems within one month of receipt
• You maintain a deletion index using non-identifiable markers
• Your restore procedure includes a mandatory post-restore deletion step based on the index
• You inform any third-party processors (including your backup provider) of applicable erasure requests

Technical

• Backup access is restricted to restore-only scenarios — no operational querying of backup data
• Your backup encryption keys are managed such that key destruction could, where practical, render data irrecoverable
• Where you use anonymisation as an erasure alternative, you have verified it constitutes true anonymisation (not merely pseudonymisation)
• Automated retention expiry is in place where technically feasible

Accountability

• You log erasure requests and record the steps taken, the systems affected, and any backup-layer timeline communicated to the data subject
• You can produce this log on request from a DPA
• Your retention schedule is reviewed at least annually

When You Can Refuse or Delay an Erasure Request

The right to erasure is not absolute. Article 17(3) sets out the exceptions. You may retain personal data — including in backups — where processing is necessary for:

• Compliance with a legal obligation under EU or Member State law (e.g., statutory accounting or tax records)
• The establishment, exercise or defence of legal claims
• Reasons of public interest in the area of public health
• Archiving purposes in the public interest, or scientific, historical or statistical research — subject to appropriate safeguards
• The exercise of the right of freedom of expression and information

The most commonly invoked exception in practice is legal obligation and defence of legal claims. Where this exception applies, document your reasoning explicitly. The EDPB's 2026 report found that controllers frequently misapplied exceptions - citing them without adequate justification. This is itself a compliance failure.

How ProBackup Supports GDPR-Compliant Data Management

At ProBackup, we back up SaaS workspaces — Asana, ClickUp, monday.com, HubSpot, Jira, Notion, Slack, and more — for thousands of teams across Europe. GDPR compliance is not an afterthought for us; it is built into how our product works.

Granular, point-in-time snapshots

Our daily snapshots create discrete restore points. This means that when a deletion request is actioned in your SaaS workspace, you can identify exactly which backup generations contain the affected data — and plan your retention timeline accordingly.

Defined retention windows

ProBackup gives you control over how long backup data is retained. We recommend aligning your ProBackup retention window directly with the backup retention periods disclosed in your privacy notice. When the retention window closes, the data is permanently removed from our systems.

Security architecture

All ProBackup data is encrypted at rest with AES-256 and in transit with TLS. Access to backup data is restricted and audited. ProBackup is SOC 2 Type II certified, which means our security controls — including access to backup data — have been independently verified.

Data Processing Agreement

As a data processor under GDPR, ProBackup provides a Data Processing Agreement (DPA) to all customers. This DPA formally documents our obligations in relation to the personal data we process on your behalf, including our obligations to assist you in responding to data subject rights requests.

Deletion support

When you action an erasure request and need to understand what backup generations may contain the affected data, our support team can assist. We can advise on the precise retention window for your account and confirm the date by which a given backup will expire.

Conclusion: The Regulatory Direction of Travel Is Clear

When we wrote the original version of this article in 2020, many organisations were still treating GDPR backup compliance as a theoretical concern. The EDPB's February 2026 report (i.e. the most detailed, evidence-based regulatory assessment of erasure compliance yet produced) confirms that those days are over.

Thirty-two DPAs investigated 764 controllers. They found widespread inadequacy. Backup handling was singled out as one of the seven systemic challenges. And multiple DPAs have now confirmed they will use these findings to drive sector-specific enforcement in 2026 and beyond.

The good news is that the compliance path is well-defined. You do not need to surgically remove data from every backup in real time. You do need a documented retention schedule, a deletion index, a transparent privacy notice, and a restore procedure that includes re-deletion of flagged records. These are achievable for organisations of any size.

At ProBackup, we are committed to making this as operationally straightforward as possible for our customers. If you have questions about how your ProBackup configuration aligns with your GDPR obligations, our team is available to help.

Sources and Further Reading

• EDPB CEF 2025 Report on the Right to Erasure (February 2026) — edpb.europa.eu
• ICO Guidance on the Right to Erasure — ico.org.uk
• CNIL Guidance on Backups and Erasure — cnil.fr
• heyData: GDPR Data Retention Periods: Key Rules and Best Practices (January 2026) — heydata.eu
• Danish Datatilsynet: Guidance on Backup and the Right to Erasure — datatilsynet.dk
• GDPR Regulation (EU) 2016/679 — Articles 5, 12, 13, 17, 30 — gdpr-info.eu
• Reed Smith: EDPB CEF 2025 Report Analysis (March 2026) — reedsmith.com

Disclaimer: This article is for informational purposes only and does not constitute legal advice. For advice specific to your organisation's circumstances, consult a qualified data protection professional.