Do I have to delete data from backups immediately?

Not in every case. First confirm that Article 17 requires erasure and that no exception applies. Delete appropriate active and readily editable copies without undue delay. If changing a backup would compromise its integrity, document that decision, restrict ordinary use, record the affected identity and ensure erasure is reapplied whenever restoration occurs.

Are backups exempt from the GDPR right to erasure?

No universal backup exemption appears in Article 17. The decision begins with the applicable erasure ground and every relevant exception, then considers each copy's function and integrity. A backup that cannot safely be edited still needs a controlled expiry path and a tested restore process that prevents erased personal data returning to ordinary use.

What grounds can trigger Article 17 erasure?

Grounds include data no longer being necessary, consent being withdrawn without another legal ground, a successful objection, unlawful processing, erasure required by Union or Member State law, and collection connected with specified information-society services. The request record should identify and evidence the actual ground rather than treating every request as identical.

Can a legal retention duty override an erasure request?

Article 17 contains an exception where processing is necessary to comply with a Union or Member State legal obligation, or for a public-interest or official-authority task. The organisation must identify the applicable rule, relevant data and required scope. There is no single EU-wide retention period to insert automatically into every assessment.

Is automatic backup rotation enough evidence of compliance?

Rotation can support eventual expiry, but a generic schedule is not evidence that a particular erasure request was assessed and controlled. The record should link the person, affected backup sets, expiry event, access restrictions and restore instruction. Long rotation increments also need an evidence-based assessment against the requirement to erase without undue delay.

What should happen when an old backup is restored?

The restore runbook should pause ordinary release, identify the restored snapshot, consult the erasure register, reapply deletions or restrictions and verify downstream replicas before service resumes. It should record both positive matches and a checked no-match result. A restoration drill demonstrates that this control works before a real recovery creates pressure.

Do I Have to Delete Data from Backups Under the GDPR?

Do I have to delete data from backups after a valid erasure request? The answer is neither “erase every recovery medium immediately” nor “backups are exempt”. The organisation must decide whether Article 17 requires erasure, classify every relevant copy, act without undue delay where deletion is appropriate, and prevent erased data from returning through a restore ¹^,3.

Quick Answer: First test every Article 17 erasure ground and exception. Delete appropriate active copies without undue delay. Where editing a recovery set would threaten integrity, record the affected data, control its expiry and access, and reapply the erasure before any restored data returns to use ¹^,3.

Last updated: 26 August 2026.

A backup is not automatically exempt or editable

The word “backup” describes a purpose, not one technical condition. One copy may be a live replica used every day, another a snapshot that can be edited safely, and another an integrity-protected recovery set whose alteration would undermine restoration. Treating all three alike hides the decision that must be made.

The first branch is legal: does an Article 17 ground apply, and does an exception require or permit continued processing? The second is factual: where does the personal data exist? Only then should the team decide what happens to each copy ³.

Copy and condition	Operational decision	Required evidence
Active system or ordinary replica, deletion appropriate	Delete without undue delay	Completion record and verification
Backup can be edited without defeating integrity	Delete or render the data unavailable, then verify	Backup identifier, method and integrity test
Integrity-protected backup should not be modified	Isolate from ordinary use, retain until controlled expiry and reapply erasure on restore	Reason, expiry event, erasure-register link and tested runbook
A legal or other Article 17 exception applies	Retain only the justified scope	Exception, applicable basis, owner and review point

Preserving integrity is not the end of the analysis. It is defensible only if the organisation can identify the affected backup, prevent routine access, know when it expires and stop the erased information from re-entering production. A statement that “IT handles backups” proves none of those points.

The request owner and recovery owner therefore need one connected record. The request owner supplies the identity, scope and decision. The recovery owner maps that decision to backup sets and restoration controls. Neither needs to rewrite the other's evidence, but both must be able to trace it.

Confirm that Article 17 requires erasure first

Article 17 gives a person the right to obtain erasure without undue delay and requires the controller to erase without undue delay where one of six grounds applies ³. The request record should test them separately:

the personal data is no longer necessary for the purpose for which it was collected or otherwise processed;
consent is withdrawn and there is no other legal ground for processing;
the person objects and there are no overriding legitimate grounds, or objects to direct-marketing processing;
the personal data has been unlawfully processed;
erasure is needed to comply with a legal obligation in Union or Member State law; or
the personal data was collected in relation to the offer of information-society services covered by Article 8(1) ³.

Identity and scope still matter. A request may name an account while relevant identifiers sit in order, support, analytics and recovery systems. The controller should obtain enough information to locate the data without collecting unnecessary new material. The search terms, systems queried and result should be recorded.

If the request rests on withdrawn consent, the reviewer checks whether another legal ground supports the processing. If it rests on necessity ending, the reviewer identifies the original purpose and why the data is no longer needed. An objection requires its own applicable branch. A label such as “customer asked for deletion” does not show which ground was assessed.

When the ground is established, create a copy inventory before actions diverge. The inventory prevents a live replica being mislabelled as a protected backup and prevents a recovery set from being overlooked entirely.

Test every exception before the copy branch

Article 17 does not require erasure to the extent processing is necessary for one of five exception categories. They cover exercising freedom of expression and information; compliance with a Union or Member State legal obligation or a public-interest or official-authority task; specified public-health reasons; archiving in the public interest, scientific or historical research, or statistical purposes under Article 89(1) where erasure would make the objectives impossible or seriously impair them; and the establishment, exercise or defence of legal claims ³.

Each is a scoped necessity test, not a status assigned to an entire database. A legal obligation may require particular transaction fields while unrelated profile data has no continuing justification. A legal-claims assessment should identify the claim context and relevant material rather than retaining every copy on a vague possibility.

Article 17(3)(b) is the branch commonly described as legal retention. The organisation must identify the Union or Member State law, the data it covers, the necessary processing and responsible owner ³. Because national rules and situations differ, there is no EU-wide number that can be inserted as a universal retention period.

Exception question	Evidence needed	Result
Is continued processing necessary for expression or information?	Defined activity and necessity reasoning	Retain only supported scope or continue erasure
Does a legal obligation or public task require processing?	Applicable rule, covered fields and period or criterion	Separate retained data from erasable data
Does the public-health branch apply?	Applicable conditions and necessity	Record narrow scope or reject branch
Does the Article 89 branch apply and would erasure defeat or seriously impair objectives?	Purpose, safeguards and impairment analysis	Retain supported scope or erase
Is processing necessary for legal claims?	Claim context, relevant data and control	Hold defined material; erase the rest

Only after this review should backup mechanics decide how an erasure outcome is implemented. Technical difficulty does not create a sixth exception.

Delete active copies without undue delay

Active copies include production databases, searchable archives, ordinary replicas, application caches and exports still available for routine work. Their labels may contain “backup”, but their accessibility and function can make them active in practice. The inventory should classify function, not rely on a folder name.

Deletion needs a completion test. Removing an account from the main interface may leave identifiers in a reporting table or a synchronised service. The owner should define the affected fields, execute the change, verify expected absence or restriction and record exceptions. Where another recipient holds data within the request scope, the workflow should address that recipient rather than assume the main-system deletion propagated.

Article 17 uses “without undue delay” for both the person's right and the controller's obligation ³. It does not create one universal number for every technical step. The team should sequence readily actionable copies promptly, document genuine dependencies and avoid holding simple deletions until an unrelated backup expires.

The completion record can be compact: request identifier, system, data scope, action, timestamp, operator, verification method and result. A failed verification remains open work. A successful live deletion then feeds the backup register so restoration controls use the same identity and scope.

Preserve backup integrity only with a restore control

Some recovery sets are designed as consistent, integrity-protected snapshots. Editing a single record inside them may make the set unreliable. The EDPB's coordinated-action report recognised that integrity concerns may make modification inadvisable, while also identifying a practical response: track erasure requests and reapply them if a backup is restored ¹.

That approach requires more than a ticket note. A backup-copy register should connect legal and technical facts:

Register field	Example of the required content
Request key	Stable internal identifier, not an ambiguous name alone
Matching identifiers	The minimum fields needed to find restored data
Backup set	Snapshot or media identifiers and systems covered
Integrity decision	Why editing is or is not appropriate, with owner
Ordinary-use control	How the set is isolated from production access
Expiry event	Rotation or destruction criterion and expected event
Restore action	Runbook step that reapplies deletion or restriction
Verification	Test method, last drill result and exception owner

The register should not copy more personal data than needed to enforce erasure. A stable request key plus suitable matching identifiers may suffice. Access belongs with staff who administer requests and recovery, and changes should be controlled because a stale identifier can make the restore check ineffective.

Isolation also needs a real meaning. An integrity-protected set should not become a convenient reporting archive or informal source for old customer details. If it is routinely queried, the “backup” classification should be reconsidered and the active-copy deletion branch may apply.

Expiry closes the dormant-copy path only when it can be evidenced. The register should show which event removes the affected set and whether replacement copies inherited the data before the live deletion. If new backups were created after live systems were corrected, their scope may differ from older sets; the inventory should capture that change.

Automatic expiry is not a request procedure

The 2025 coordinated action found concern among half of the responding supervisory authorities. Reported weaknesses included the absence of a request-specific procedure, reliance on generic automatic deletion or retention, default exclusion of backups without justification, and long deletion increments that could be problematic for the “without undue delay” requirement ¹^,2.

Automatic rotation can support implementation, but the request still needs its own traceable sequence. The record should identify the Article 17 ground and exception outcome; map the affected identity to active systems and named backup sets; verify deletion from appropriate active copies; record the integrity and expiry decision for each protected set; and link those sets to the restore instruction. A policy saying “backups expire automatically” proves none of these steps. If the organisation cannot move from the request key to the precise recovery sets and release gate, its schedule lacks the request-to-copy connection needed to prevent a later reversal.

Long increments deserve particular attention. A schedule may be suitable for recovery design yet leave erasable data dormant for an extended interval. The assessment should record why integrity prevents earlier change, what access restrictions apply, when the exact set expires and why the overall path meets the without-undue-delay duty. The report does not supply a universal maximum, and this article does not invent one ¹.

The evidence should distinguish planned expiry from completed expiry. Until the event is verified, the copy remains in the register and the restore control remains active. A missed rotation or duplicated media set should reopen the item rather than disappear behind the original schedule.

The coordinated action shows recurring control gaps

The 2025 coordinated enforcement action involved 32 supervisory authorities. Nine launched formal investigations and 23 conducted fact-finding. Across the exercise, 7,943 controllers were contacted and 764 responded ¹. Those figures describe the exercise as a whole; they do not establish the prevalence of a particular backup practice among all controllers.

The report and EDPB summary identify recurring implementation difficulties: organisations sometimes lacked defined procedures for individual erasure requests, relied on automatic schedules, or excluded backups by default without a case-specific justification. The backup findings matter because they point to missing decisions and evidence, not because “backup” itself answers Article 17 ¹^,2.

For a small organisation, the corrective action is tangible. One request record identifies the ground and exception outcome. One copy register maps active and recovery copies. One restore runbook prevents return. These documents can be maintained without a purchased system, provided ownership and testing are real.

The exercise also supports restraint in reporting. It should not be converted into a claim that every organisation failed or that authorities prescribed one technical design. The useful lesson is that generic retention language does not demonstrate request handling.

Run a restoration drill before an incident

A restoration is usually performed under time pressure. If the erasure control begins only after systems return to ordinary use, deleted data can reappear in user interfaces, replicas or outbound processes.

The runbook should therefore place the erasure check before release, with the restored environment isolated until the result is verified.

The recovery lead identifies the exact snapshot, systems and restore time.
Access remains restricted while the restored environment is verified.
The operator queries the erasure register for requests affecting that snapshot and system.
Positive matches are reapplied using the recorded identifiers and scope.
Exceptions and legally retained fields remain separated according to the request decision.
Downstream replicas, caches and queued exports are checked before connection.
The operator records positive matches, a checked no-match result, actions and verification.
Service resumes only after the recovery and request owners sign the release gate.

Drill event	Expected evidence	Failure response
Register contains an affected request	Data is found, erased or restricted, and verified before release	Hold environment and repair matching or action logic
Register has no affected request	Query scope and checked no-match result are logged	Hold if snapshot identity or register coverage is uncertain
A required-retention exception exists	Only defined fields remain controlled	Escalate scope mismatch to request owner
A downstream copy receives restored data	Erasure propagates and verification succeeds	Isolate downstream system and repeat control

A drill should use controlled test records, not revive real erased data merely for testing. It should exercise both a positive match and a genuine no-match path.

The no-match path matters because it proves the operator checked the correct snapshot and complete register rather than merely deleting a known example.

After the drill, record defects with owners and repeat the failed stage. A document marked “tested” without the snapshot, date, result and exceptions is weaker than a short ledger showing exactly what happened.

Close the request with evidence, not a promise

Closure should assemble the decision rather than claim that every byte disappeared instantly. The response record should show the Article 17 ground, every exception tested, active-copy actions, backup sets affected, integrity decisions, expiry events and restore controls. Any retained scope should be distinguishable from data scheduled for erasure.

The operational file should remain open while a failed active deletion, unknown copy, unsupported exception or missing restore control persists. Dormant integrity-protected backups can follow their recorded expiry path only while isolation and restore safeguards remain effective.

A short close-or-hold gate keeps the outcome explicit:

Close when the ground and exceptions are documented, appropriate active copies are verified, backup sets are registered, integrity decisions have owners, and the restore control has been tested.
Hold when system scope is unknown, a legal-retention claim lacks its applicable rule, active data remains without reason, expiry cannot be identified, or restored data could return before reapplication.
Reopen if media survives its expected expiry, identifiers change, a drill fails, a new copy is discovered or a restored environment bypasses the release gate.

The answer to “do I have to delete data from backups” is therefore a controlled set of branches. Article 17 decides whether erasure is required and what scope may remain. Copy function and integrity decide the implementation. The register and restore runbook prove that a dormant copy cannot quietly reverse the completed request.