Does GDPR erasure apply to backups, logs and replicas?
If a controller must delete a person's data, that duty reaches every copy where the data is still personal data, including backups, activity logs and replicas. A fixed fee or timeline cannot be quoted in advance, because the work depends on how many copies exist, where they sit and how they are structured. The controller owns the decision on what must be erased, how far it must go and what is justified as an exception under Article 17(3). An implementation partner can prepare systems, backup and log designs, and the evidence that shows what was done, but it cannot decide the legal position or certify the result. Only an independent auditor or a supervisory authority assesses compliance.
The EDPB's 2025 coordinated enforcement action on the right to erasure covered 32 DPAs and 764 responding controllers, with findings announced on 18 February 2026. Two recurring problems matter here. Controllers struggled to delete personal data held in backups, and they relied on ineffective anonymisation in place of deletion. The EDPB's position is that pseudonymised data remain personal data, and that anonymisation must make re-identification unlikely by all means reasonably likely to be used, so a copy that can still be linked back to the person is not anonymous. Read the EDPB news release on erasure challenges before deciding how each copy will be handled.
Start by listing every backup set, log store, search index, analytics export and replica that holds the data subject's information, then record the retention period and deletion method for each one. Confirm with your counsel and backup vendor whether individual records can be removed from backup media or whether restoration must be followed by reapplying the erasure, and document that process. Keep the evidence (the request, the search results, the deletion or suppression steps and the notices to recipients under Article 19) because a supervisory authority can order erasure under Article 58(2)(g) and will ask for it.
Where erasure fails in backups, logs and replicas
Erasure requests rarely fail in the primary database. They fail in the copies around it: restored backups, logs, replicas and analytics extracts that were never placed on the deletion path. The cards below cover the failure points regulators and enforcement teams keep finding, with the fix and what to confirm in your own environment.
Restored backups re-introduce deleted records
A backup taken before an erasure request still holds the deleted data. If a disaster recovery restore brings that backup back without replaying deletions, the records return to production and the erasure is undone. The fix is a restore procedure that re-applies a log of erasures against any restored dataset before it goes live. Confirm with your backup owner whether restores are ever run from snapshots that predate recent erasures, and who signs off on that step. Restores are the moment erasure most often fails.
Activity and search logs hold personal data
Application logs, access logs and search query records often contain user identifiers, IP addresses or the search terms a person entered. The EDPB's guidance treats these as personal data within scope of erasure. The fix is to define which log fields carry identifiers, shorten retention for those fields, and pseudonymise or remove them before they reach long-term storage. Confirm which logging pipelines capture identifiers and whether any erasure request procedure searches them at all.
Replicas and analytics copies off the path
Read replicas, data warehouse extracts, reporting tables and exports made for analysts are often created by jobs that nobody added to the erasure workflow. The record remains in those copies after the source is cleaned. The fix is to list every downstream copy in the data inventory, assign each one a deletion job or a documented reason it cannot be deleted, and pass erasure to recipients under Article 19 where data was shared. Confirm which copies exist, who created them and whether they refresh from the source or persist indefinitely.
Anonymisation used in place of deletion
Replacing names with hashes, dropping direct identifiers or aggregating a record is often treated as erasure. Pseudonymised data remain personal data while anyone can link them back to a person, and the GDPR does not apply only once data is truly anonymous. The fix is to delete the record where erasure is due and reserve anonymisation for data that can no longer be attributed to anyone, judged by all means reasonably likely to be used. Confirm whether the anonymisation method has been tested for re-identification by someone with access to other datasets.
Retention periods never set
Many backup, log and replica stores were configured with no defined retention period, or with a default that no one reviewed against the purpose of the data. Without a period, a controller cannot show that a copy is still needed, and erasure requests have nothing to be checked against. The fix is a retention schedule per data category and per store, with automated expiry where possible and an owner who approves exceptions. Confirm the retention setting on each backup policy, log index and replica, and whether any of them is set to keep data indefinitely.
Why anonymisation rarely replaces deletion
Pseudonymisation is not a way out of erasure. Recital 26 of the GDPR states that pseudonymised data which could be attributed to a person using additional information remain personal data, and that the Regulation does not apply to information that is truly anonymous. For a backup or log that holds a hashed user identifier, a tokenised email address or a record keyed by an internal customer number, the question is whether the controller, or anyone it could reasonably use, can still link the record back to the person. If the answer is yes, the record stays in scope and an erasure request still applies to it.
The test is identifiability by all means reasonably likely to be used, judged with regard to cost, time and available technology. A hashed key looks opaque, but if the same hashing function and salt are available to the operator, or a mapping table sits in the same database, a log archive or a backup set, the key is only one lookup away from the person. The same applies to a retained lookup table kept "for restoration purposes". Ask the engineering team to list every place where a key, salt, token vault or join table exists, and to state who can reach each one. Each one that can re-link records is a place where erasure must still reach. Anonymising fields such as IP addresses or free text is a separate exercise, and the result must be tested against the same reasonableness standard rather than assumed.
The EDPB's 2025 coordinated enforcement action on the right to erasure, covering 32 data protection authorities and 764 responding controllers and announced on 18 February 2026, listed ineffective anonymisation used in place of deletion among its seven recurring challenges. Controllers often treated a masked or hashed copy as having left the GDPR, when the copy still allowed re-identification. Before relying on anonymisation for any dataset that holds an erasure obligation, document the re-identification analysis, record who holds any key material, and treat the result as personal data if the analysis cannot show otherwise. Where deletion is the only defensible answer, plan the deletion path instead of substituting a transformed copy.
How backup and log design affects restoration and deletion
Crypto-shredding encrypts each data subject's records under a per-subject key, or under keys grouped by a defined scope, and stores the keys apart from the backup media. Deleting the key makes the ciphertext in every backup unreadable, which can address erasure without rewriting immutable backup sets. The approach depends on keys being genuinely destroyed everywhere they exist, including key escrow, hardware security modules and replicas.
- What it helps with: erasure in immutable or append-only stores where individual records cannot be removed from backup sets.
- Restoration cost: restoring a backup now also requires key retrieval, so key availability becomes a recovery dependency and must be tested.
- Key management load: per-subject keys multiply key counts, so key lifecycle, rotation and destruction logs need tooling and ownership.
- What to document: the key hierarchy, which systems hold keys, the destruction procedure, and how destruction is verified.
- Limit to confirm: whether the chosen platform or backup tool supports per-subject encryption natively. Confirm this with the vendor before designing around it.
Ask the team to show, for one test subject, which copies remain encrypted after key destruction and which plaintext copies still exist.
Short retention sets backup and log retention periods so that copies expire on a defined schedule, and records are gone once the last backup containing them rolls off. This does not remove data immediately, so it works best where the controller can justify the retention period and communicate the timeline to the requester. The retention period is itself a decision the controller must justify under the storage limitation principle.
- What it helps with: predictable deletion for data that does not need long-term recovery, and simple evidence of a defined schedule.
- Restoration cost: restores can only reach back as far as retention allows, which limits point-in-time recovery for ransomware and corruption events.
- Recovery planning: recovery point objectives must be set against the retention window, not against the business preference.
- What to document: the retention period for each backup tier, the justification, and the expiry job's logs.
- Limit to confirm: whether the backup tool enforces expiry in immutable storage and how it handles legal holds.
Check whether the requester's data can still be restored after the stated erasure date through any longer-retained archive or replica.
Logical deletion removes the record from live systems, and a suppression list records the identifiers of erased subjects. When a backup is restored, a documented step removes or re-applies deletions before the data returns to production. This keeps erased people out of the restored environment but requires that the suppression list itself be minimal and controlled.
- What it helps with: restores that might otherwise bring back deleted records, without rewriting old backup sets.
- Restoration cost: every restore needs a reconciliation step, which adds time and a point where errors can reintroduce data.
- Minimal identifiers: the list should hold the least identifying information needed to match records, stored with access controls.
- What to document: the reconciliation procedure, who runs it, how results are checked, and how long suppression entries are kept.
- Limit to confirm: whether the restore procedure can apply deletions automatically in your environment. Test this on a non-production copy.
Record each restore event and whether the suppression step was applied, since auditors will ask for that trail.
Logs often hold identifiers such as IP addresses, user IDs, search terms and request payloads, and the EDPB's coordinated action treats activity logs and search activity as potentially in scope. Minimisation reduces what is logged in the first place. Field-level redaction or pseudonymisation removes or replaces identifiers at ingestion or on a schedule. Pseudonymised data remain personal data, so redaction does not by itself take logs out of scope.
- What it helps with: reducing the number of logs that contain personal data and shortening the period in which they can identify someone.
- Restoration cost: redacted logs may lose the detail needed for incident investigation, so the trade-off needs a documented decision.
- Scope of redaction: map which log fields carry personal data across applications, proxies, databases and security tools.
- What to document: the logging standard, the fields redacted and why, retention per log source, and access rights to unredacted data.
- Limit to confirm: whether the logging platform supports field-level redaction at ingestion and whether that applies to every source.
Ask the team to demonstrate a search for one test identifier across the log platform and show what remains after the retention window.
Working through an erasure request across copies
This sequence turns an erasure request into a documented decision that covers every copy of the data, from the live systems to the backups and logs that hold it. Each phase closes with a record a regulator or assessor can follow from intake to closure.
Log the request and confirm the requester
The privacy team records the request, its date of receipt and the scope the requester asked for, then checks identity only as far as proportionality allows. Extra identity information should be limited to what is needed to confirm who is asking, and the team should not collect more than that. The step is done when the request has a unique reference and a confirmed or documented verification outcome.
Map every copy that holds the data
Using the record of processing and the system inventory, the team lists each place the person's data may sit: production databases, search indexes, analytics stores, exports, file shares, backup sets, log pipelines and replicas at processors. Activity logs and search histories can count as personal data, so they belong on the list. The step closes with a copy register that names each location, its owner and its deletion method.
Decide grounds and exceptions
The privacy lead checks whether one of the six grounds in Article 17(1) applies, such as data no longer needed for its purpose or consent withdrawn, and whether any exception in Article 17(3) keeps some data, for example a legal obligation or the defence of legal claims. The decision should be made per data set, since one copy may be retained for a lawful reason while another must go. The step closes with a written decision for each data set and its legal basis.
Delete or suppress in live systems
Engineers remove the data from primary stores and indexes, or where full deletion is not yet possible, suppress it so that it is no longer used for any purpose. Pseudonymised records stay personal data, so replacing identifiers with tokens does not complete the request. The step is done when a query or test run confirms the data cannot be retrieved from live systems, with the query output kept as evidence.
Handle backups on their expiry cycle
Backup copies are usually deleted by letting them expire under the retention schedule, while a restore procedure ensures that any restored set re-applies the suppression list before the data returns to use. The team records the expiry date for each affected backup set and documents the restore control. The EDPB's 2025 coordinated action found controllers struggling to delete data from backups, so this step should be designed and tested before a request arrives. It is done when the expiry dates and restore controls are on file.
Notify recipients of the erasure
Under Article 19, the controller tells each recipient the data was shared with that erasure has taken place, unless this is impossible or involves disproportionate effort. The team sends notices to processors and third-party recipients, asks them to confirm deletion, and records where a notice could not be given and why. The step closes with a confirmation log for every recipient.
Record the decision and close the request
The team writes a closure record that lists the copies covered, the grounds or exceptions relied on, the deletion or suppression method, the backup expiry dates, the recipient notices and the answer sent to the requester. Records should be retained so that the controller can show what it did if a supervisory authority asks, since authorities can order erasure under Article 58(2)(g). The request is closed when this record is approved and stored with the request reference.
Telling recipients under Article 19
Article 19 requires the controller to tell each recipient of the personal data about an erasure, unless doing so proves impossible or involves disproportionate effort. For this topic, that means the controller must be able to list every system, processor and third party that received the data, including copies that were shared downstream, and then decide which of them must be told. A recipient list kept only in the record of processing is rarely enough, because it seldom captures exports, replicas or one-off transfers. Before any erasure is closed, confirm that the recipient list is current for the systems in scope and that someone owns the notification step.
When the controller relies on the impossible or disproportionate exception, it should record the decision in the request file: which recipient it considered, what made notification impossible or disproportionate, what effort the controller weighed, and what it did instead, such as deleting from the source and letting a restored backup age out under a documented retention rule. The EDPB has said that controllers must be able to justify this kind of assessment, so the reasoning matters as much as the outcome. Ask your data protection officer or legal team to review the exception criteria before you use them as a routine shortcut for backups or logs.
Processors sit in a different position. A processor holding a copy of the data on your behalf is not usually a separate recipient to notify in the same way, because the deletion instruction flows through the processor contract. Check that your processing agreements oblige the processor to assist the controller in meeting its obligations, including erasure, and that they set out how and how quickly the processor acts on an instruction. Where a processor cannot delete a copy in a backup or log store it operates, the contract should say how that gap is handled and what evidence the processor returns.
Who owns what in an erasure programme
This table compares who does what across the controller's team, an implementation partner such as DeployOpen, and the independent auditor or supervisory authority. Read each row as a question of accountability: the controller decides and owns the outcome, the partner prepares systems and evidence, and only an independent assessor issues any report or certificate. DeployOpen prepares systems and evidence and does not issue reports or certificates.
| Area | Controller's team | Implementation partner (for example DeployOpen) | Independent auditor or supervisory authority |
|---|---|---|---|
| Retention decisions | Sets retention periods per data category and decides when erasure grounds apply or an Article 17(3) exception holds | Advises on how retention rules can be enforced in systems; does not decide the legal position | Tests whether decisions are documented, justified and applied |
| Inventory of copies | Owns the record of processing and confirms which backups, logs, replicas and processors hold personal data | Maps technical locations of copies, including snapshots, log indexes and search replicas, and documents them | Samples the inventory against system evidence and processor records |
| Backup and log redesign | Approves design trade-offs between restoration needs and deletion obligations | Designs and implements backup tiers, log retention settings, pseudonymisation and deletion procedures, then documents them | Reviews design documents and tests whether deletion holds across restore paths |
| Deletion evidence | Accepts the evidence standard and retains the records of each erasure decision | Produces run logs, job reports, restore-test results and tamper-evident deletion records from the platform | Checks that evidence is complete, consistent and traceable to individual requests |
| Recipient notices | Decides which recipients received the data and whether notification is impossible or disproportionate under Article 19 | Provides lists of processors and integration endpoints and helps automate notice workflows | Verifies that notices were sent or that the stated exception was reasonable |
| Assessment | Commissions any voluntary assessment, owns remediation and answers supervisory queries | Supports readiness reviews and remediation, and prepares the evidence pack for the assessor | Issues any audit report or certificate, or investigates and orders erasure under Article 58(2)(g) |
Questions buyers ask about erasure in backups
Can we delete personal data from backups immediately?
Usually not in the same step as the live system, and the GDPR does not ask for it. Article 17 requires erasure without undue delay, but backups are often written in sets that cannot be edited record by record. The practical question is whether you can stop the data from being restored or reused, and whether you can remove it when that backup set is rotated out or rebuilt. Document the approach for each backup type, record the date the erasure took effect in the live systems, and make sure restoration procedures re-apply pending erasures before any data returns to production. Confirm with your backup vendor how deletion from immutable or deduplicated stores works before you promise a timeline to a requester.
How long can backups keep personal data after an erasure request?
There is no fixed retention period in the GDPR for backups. The period must be justified by your retention schedule and by the purpose for which the data is kept, and it must not be longer than needed. The EDPB's 2025 coordinated enforcement action found controllers struggling to determine retention periods and to delete data held in backups, so regulators are looking at this gap. Set a documented backup retention period, decide what happens to personal data within it after an erasure request, and show that the period is proportionate. Ask your auditor or counsel to confirm the approach for your sector, because some obligations to keep records may apply.
Does anonymising logs count as erasure?
Usually no. Recital 26 explains that pseudonymised data remain personal data when they can be attributed to a person with additional information, and that identifiability is judged by all means reasonably likely to be used, including cost, time and available technology. Replacing a username with a hash, or truncating an IP address, often leaves the data personal if the key, salt or original source still exists. Anonymisation is only a substitute if the result truly cannot be linked back to the person. The EDPB's enforcement findings list ineffective anonymisation used in place of deletion as a recurring problem. Test your approach against the recital, and keep the logs needed for security monitoring under a documented legal basis rather than assuming they fall outside the regulation.
Do we have to tell every processor and recipient about an erasure?
Yes, unless it is impossible or disproportionate. Article 19 requires you to communicate erasure to each recipient to whom the personal data were disclosed, and to inform the data subject about those recipients on request. This includes processors that hold copies in their replicas, analytics platforms, search indexes and backup providers. Keep an inventory of where each record was disclosed so that you can notify recipients without a manual hunt. Where a recipient keeps data only in backups, agree in your processor contract how erasure will be applied and confirmed. Record each notification and any case where you judged it disproportionate, with reasons.
What does this work need from our own engineering and legal teams?
Erasure in backups and logs needs decisions that only your organization can make, plus technical work that depends on your architecture. Legal and privacy staff must set the grounds for erasure, the Article 17(3) exceptions you may rely on, and the retention periods for each data category. Platform and backup engineers must map where copies live, confirm how each store deletes or expires data, and design restoration so erased records are not reintroduced. Security staff must review log content and access. An implementation partner can prepare systems, scripts, runbooks and evidence for these decisions, but the controller remains responsible for the outcome. Ask any partner to state in writing which tasks are theirs and which remain with your team.
Can an implementation partner certify that our erasure process complies with the GDPR?
No. The GDPR requires no certificate, and Article 42 certification is voluntary and issued only by accredited certification bodies or supervisory authorities. DeployOpen prepares systems, controls and evidence for compliance assessments, including retention settings, deletion workflows and restoration tests. It does not issue audit reports, attestations or certifications. Certification, where you pursue it, does not reduce your responsibility as controller or processor. Before engaging anyone, confirm the scope in writing, agree the evidence you will keep, and ask your data protection officer or external auditor which assurance they will accept.
How DeployOpen prepares backup and log systems for erasure
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so backup, log and replica design can be set up to support erasure as well as restoration. The work is scoped in writing before it starts and leaves your organization with documented systems, controls and evidence.
How we scope
- Inventory every backup set, log store, search index and replica that holds personal data, with its retention period and owner.
- Record which systems restore whole datasets and which can delete individual records, so the written scope reflects real constraints.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
How we build
- Design backup rotation so expired copies age out on a defined schedule, and document how records are excluded when restored.
- Configure log pipelines with retention limits and pseudonymised identifiers where the business need allows it.
- Test restores and deletion steps in a non-production environment to confirm both still work before go-live.
How we hand over
- Document the erasure procedure for backups, logs and replicas, including who runs each step and how each run is recorded.
- Provide evidence artifacts such as retention configurations, deletion job logs and restore test records for your assessor or auditor.
- Confirm with your legal and privacy team which exceptions under Article 17(3) apply, since DeployOpen does not decide legal grounds.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Review backup and log configurations when platforms are upgraded or new recipients of personal data are added.
- DeployOpen prepares systems and evidence, while independent auditors and certification bodies issue any reports or certificates.
