Not a vulnerabilityNothing fails and nothing is attacked. The backup does what a backup does; the objection is that the erasure procedure was never designed to survive it.
What it is
The erasure is carried out in the live system. Backups made before it keep the record and nothing marks it as erased. When a backup is restored, in part or in whole, the record comes back, and from that moment it is live again: indexed, exported, included in the next backup. Where no register of erasures is kept, the restore cannot even be corrected afterwards, because nobody knows what was supposed to be gone.
Why it is a separate entry
The person was told the data was gone. It was not, and the moment it returns has nothing to do with anything they can see or ask about. The same holds for scheduled deletion: a record removed on time reappears from a backup whose cycle is longer than the period it was meant to enforce.
How it arises
erasure implemented as a delete in the application, with backups outside the scope of the procedure
no register of erasures, so a restore cannot re-apply what was erased
a backup cycle longer than the retention period it is supposed to serve
test and analysis environments refreshed from the same backup
Not to be confused with
A record kept too long in the live system is an ordinary retention finding. This entry is about the second copy: the live system is right and the store behind it is not. A log holding content is Logs recording content, not events, where the fault is what gets written rather than what fails to be removed.
How to establish it
The organisation's own answer states either that backups are out of scope for erasure, or that no register of erasures exists from which a restore could be corrected. In a system you administer yourself the behavioural check settles it directly: a record erased on request is present again after a restore, with no re-application step in between.
method document-comparisonQoD 75
Requirements on the measurement
ask in writing what happens to backups on an erasure request, and keep the answer with its date
ask whether a register of erasures is kept and whether it is applied after a restore, and by whom
where you administer the system, test on a copy: erase, restore, look
record the backup cycle and the retention period next to each other; a cycle longer than the period settles the scheduled-deletion half on its own
What would refute it
by handA register of erasures is kept and re-applied after every restore, and the procedure names who does it.finding falls
by handBackups are encrypted per record with a key destroyed at erasure.The restore then returns something nobody can read, which is a defensible implementation of erasure.finding falls
by handBackup retention is shorter than the period after which the record would have been deleted anyway.weakens
by handThe erasure request was refused on a stated ground, so nothing had to be erased.finding falls
Where this plugs into existing processes
The one question that surfaces itYou restore last month's backup tonight. Which erased records are back tomorrow?
In a DPIA, verify this
Verify what happens to backups on an erasure and whether a restore re-applies past erasures, instead of recording that erasure is supported.
As a procurement clause
The supplier states in writing how an erasure survives a restore, and demonstrates it on a test restore at delivery.
With a complaint, hand over
The erasure confirmation, the written answer about backups, and the backup cycle set against the retention period.
Reproduction
METHOD.md · by hand · no dedicated reproduction exists yet; follow the general method and the indicator above
Legal framing
eu-gdpr-17
eu-gdpr-5-1-e
eu-gdpr-5-2
Objections, and the answer
“A backup cannot be edited, that is what makes it a backup.”
Nobody asks for it to be edited. What is asked is that the erasure survives a restore, which a register applied on restore achieves without touching the backup at all.
“The backup is only for disaster recovery.”
Then the disaster is the day the erased record comes back. What the copy is for does not change what happens when it is used.
“We keep no register of erasures, for privacy reasons.”
A list of identifiers with a date is less data than the records it stops from returning, and it is the only way the promise can be kept.
“It is a rare edge case.”
It is measurable rather than rare: the backup cycle and the number of restores per year are both known inside the organisation.
What this does not establish
harm; the catalogue standardises a finding so it can be referred to, it does not weigh it
severity; there is no score here, by design. Weighing belongs to whoever applies the entry to a concrete case
unlawfulness; that is for a supervisory authority or a court
intent; a fault is usually a build decision, not a plan
absence: not finding it in one capture is not evidence that it is not there
DPE Catalogue. DPE-2026-0035: Erasure that does not reach the backup. Schema 2.0, entry status active. Retrieved from https://totaledigitalewaarborging.nl/register/DPE-2026-0035
Measurement
When you publish a finding, cite the method version alongside the entry: “DPE-2026-0035, established under DPE Measurement Method 1.0”
Identifiers are permanent and are never
reused. An entry that is deprecated keeps its number and its address, with the reason attached, because
references to it exist elsewhere.