Article 17 GDPR right to erasure: requirements and evidence

What Article 17 GDPR asks for and why erasure is hard in systems

Article 17 requires a controller to erase personal data without undue delay when one of six grounds applies and no exception covers the data. In practice, a request or an audit asks a simpler question: can you prove that the data is gone from every place it lives? The six grounds are: the data is no longer needed for the purpose it was collected for, the person withdraws consent, the person successfully objects to processing, the processing was unlawful, a legal obligation requires erasure, or the data was collected from a child for an information society service. Each ground is a trigger your systems must be able to act on, so the decision to erase has to reach the data stores that hold it.

The hard part is that personal data rarely sits in one database. Backups keep copies of records that were deleted from production months earlier, and restoring an old backup can silently bring erased data back. Replicas, search indexes, caches, analytics warehouses and exports hold copies that a deletion job in the primary system never touches. Logs often record identifiers, IP addresses or payloads that remain for retention periods unrelated to the erasure request. Anonymization is sometimes proposed as a substitute, but it only counts if the data can no longer be linked back to the person, and the EDPB's 2025 coordinated enforcement action on erasure, which covered 32 supervisory authorities and 764 controllers and was announced on 18 February 2026, identified ineffective anonymisation used instead of deletion and deletion of personal data in backups among its seven recurring challenges.

Start by mapping every store that holds personal data about a person, including backup sets and log pipelines, and record how each one is erased, restricted or aged out. Ask your backup administrator how a restore handles records that were erased after the backup was taken, and confirm that the answer is written down. Where a copy must remain, such as a backup retained under a documented schedule, record the reason and the date it will expire. Auditors and supervisory authorities will ask for this map and for the proof behind it, so treat the erasure log as evidence from the start, not as something to reconstruct later.

Which systems, data and third parties fall in scope for GDPR erasure

Article 17 applies wherever personal data lives, not only in the main application database. Each scoping decision below changes what must be deleted, how deletion is proven, and who else must be told, so the inventory should be settled before the erasure workflow is designed.

Primary production stores

These are the systems of record: the customer database, document stores, CRM, HR platform and any file shares where personal data is created and updated. Deletion here is the visible part of an erasure, and it usually needs to cascade through linked tables and object storage. Check whether soft-delete flags, archived rows or cached exports leave the data readable, because a flag alone rarely satisfies a request. Confirm which store is authoritative for each data subject so the team knows where the deletion must be final.

Backups, replicas and analytics copies

Backups, read replicas, data warehouses and test copies hold the same personal data and are the hardest place to delete it. The EDPB's 2025 coordinated enforcement action identified deletion of personal data in backups as one of its recurring challenges. Decide whether backups will be purged on rotation, filtered at restore time, or documented as an exception with a retention rule. Confirm how a restore would re-apply erasures, so deleted records do not return silently.

Logs and audit trails

Application logs, access logs, audit trails and monitoring data often contain identifiers such as IP addresses, user names and request payloads. These records are usually needed for security and accountability, so the scoping question is which fields must be masked, pseudonymized or dropped at the point of logging. Set retention periods for each log source and confirm that erasure requests do not require rewriting immutable audit records. Document the reasoning, because a regulator will ask why a log still holds identifiers after a deletion.

Ticketing and helpdesk records

Support tickets, service requests and email threads routinely contain personal data that customers and staff volunteer, sometimes including attachments. Helpdesk platforms such as GLPI and Zammad keep these records long after the original issue closes, so they belong in the erasure inventory. Confirm whether the platform can redact or delete a single contact across tickets, attachments and notes, and whether the erasure itself is recorded without copying the deleted content into the audit log.

Processors and recipients

Article 17(2) and Article 19 require controllers to inform recipients and, where data were made public, other controllers processing them. Hosting providers, sub-processors, payment processors and integrated SaaS tools all receive copies or synchronized records. Maintain a current list of recipients per data category and confirm each processor's ability to delete on instruction. Where a recipient cannot be reached, document why the notification was impossible or disproportionate, since that justification is what an assessor will check.

When erasure applies and when Article 17(3) exceptions block it

Article 17(1) requires erasure without undue delay where one of six grounds applies: the data are no longer necessary for the purpose they were collected for, the data subject withdraws consent, a successful objection removes the basis for processing, the processing was unlawful, a legal obligation requires erasure, or the data were collected from a child in relation to information society services. For each request, the controller should map the ground to the specific data set and processing purpose, then record the decision. A system team cannot answer the request without knowing which purposes and lawful bases apply to each store, so the mapping belongs in the records of processing before the first erasure request arrives. Article 17(3) lists exceptions that can block erasure, including freedom of expression and information, compliance with a legal obligation or a task carried out in the public interest, public health, archiving in the public interest, scientific or historical research, and the establishment, exercise or defence of legal claims. Each exception must be assessed per case and the reasoning documented, and the exception covers only the data it actually protects. A tax retention duty may justify keeping invoice records for the period the law requires, but it does not justify keeping a marketing profile. Systems that hold data with no remaining basis are not excused by a general claim that the data might be useful later. Where the controller has made personal data public, Article 17(2) requires reasonable steps, including technical measures, to inform other controllers processing the data that the data subject has requested erasure of links, copies or replications. Reasonable steps depend on what is published, how widely it is shared and what technical means exist to reach downstream processors. Confirm with legal counsel which publication channels, such as public web pages, search indexes, open data feeds or syndicated feeds, fall under this duty, and keep a register of where published data was sent so that notices can be issued and logged.

How an assessor tests erasure and what evidence they request

This table sets out how a supervisory authority or independent assessor typically tests erasure, the evidence they ask for, and the findings the EDPB flagged in its 2025 coordinated action. Read each row as a test step: the approach tells you what they will trace, the evidence tells you what to prepare, and the finding tells you where organizations usually fail.

Test area	Evidence requested	Common findings
Request-to-erasure tracing	Intake records, ticket history, timestamps, and a log showing each system where erasure was actioned	Requests logged but never linked to the systems that hold the data, so erasure is incomplete
Sampling of closed requests	Sample of closed erasure tickets with proof of deletion in each affected store, selected by the assessor	Tickets marked closed before deletion was verified in primary stores
Verification in primary stores	Database queries or screenshots showing the record is absent, plus the data inventory that lists the stores	Copies in exports, spreadsheets, document stores or SaaS tools that were not in the inventory
Backups	Backup retention settings, documented restore-and-reapply procedure, and records showing deleted data is not restored into live use	Personal data kept in backups with no defined expiry or process to remove it on restore
Replicas and caches	Replica and cache configuration, replication lag records and purge logs	Erased records reappearing from read replicas, search indexes or caches
Logs and telemetry	Log retention policy, redaction or deletion evidence, and the rationale for any retained identifiers	Personal identifiers kept in application, audit or analytics logs beyond the stated retention
Anonymization claims	Written method, re-identification risk assessment and evidence the data cannot be linked back to the person	Pseudonymized or masked data described as anonymized, which the EDPB treats as ineffective anonymisation
Recipient notification under Article 19	Recipient register, notification records to each recipient and reasons for any impossibility or disproportionate effort	No record of which recipients received the data, or no notice sent to processors and sub-processors
Published data and links	Steps taken to inform other controllers where data was made public, including technical measures used	No documented steps for links, copies or replications of publicly posted personal data

How to implement erasure controls in order

This sequence turns Article 17 from a policy statement into a working erasure capability, moving from knowing where personal data sits to proving that deletion reached every copy, backup, log and recipient. Each step produces a record an assessor or supervisory authority can inspect.

Map where personal data lives
Inventory every system, database, file store, backup target, replica, log source and third-party service that holds personal data, and record which data categories and data subjects each one covers. The organization owns this inventory, and the privacy or data governance lead signs it off with the system owners. It is done when every system in the records of processing has a named owner and a documented location for its personal data, and when gaps found during the review have tickets open. The data map is the input every later step depends on.
Define retention and erasure triggers
For each data category, write down the retention period or the event that ends the need to keep it, and map the six Article 17(1) grounds to triggers the systems can detect, such as withdrawn consent, a successful objection or a closed account. Record the exceptions under Article 17(3) that the legal team has approved, so engineers know when deletion must be refused. The output is a retention schedule linked to the data map, and it is done when each trigger has an owner and a documented way to be detected.
Build the deletion workflow in primary systems
Implement the deletion path in each primary system, including the ability to delete or irreversibly anonymize records across related tables, files and caches. Route requests through a ticketing system so intake, verification, assignment and closure are tracked in one place. Tools such as GLPI's Assistance module or Zammad can hold the request record, but the organization must confirm that the chosen tool can link a ticket to the systems actually changed. It is done when a test request removes data from production and the ticket shows who ran the action and when.
Handle backups and restore-time re-erasure
Decide how backups will be treated: either retain them under a documented expiry rule that limits how long erased data survives, or keep a deletion list that is applied after any restore. Bareos can restore files from the current backup or from one before a given date and time, and restic supports snapshot-based repositories, so the team should confirm how each product handles removal of individual records. The runbook must state that restored data is erased again before the system returns to use. It is done when a restore test shows that an erased record does not reappear.
Extend erasure to replicas, logs and processors
Apply the same deletion or anonymization to read replicas, search indexes, analytics stores, caches, and application and audit logs where personal data appears. Where a processor or sub-processor holds data, send a documented erasure instruction through the processor contract and record the confirmation. Logs often need a specific decision, since some logging is required for security under Article 32, so the team should record the retention basis for each log type. It is done when a checklist for each system is completed and each processor confirmation is filed with the request.
Set up recipient notification
Where the data was made public, take reasonable steps, including technical measures, to inform other controllers that erasure of links, copies or replications has been requested under Article 17(2). For other recipients, notify each one under Article 19 unless this is impossible or disproportionate, and keep the reason where it applies. Maintain a recipient register so the organization can answer a data subject who asks who received their data. It is done when the register lists every recipient for each data category and notices are sent and logged.
Close requests with records and tests
Close each erasure request only after the ticket holds the verification result, the systems changed, the backup handling applied, the recipient notices sent, and any refusal with its Article 17(3) basis. Run periodic test requests against sample records and keep the output as a test log. The EDPB's 2025 coordinated enforcement action identified ineffective anonymization used in place of deletion and deletion from backups as recurring problems, so the test log should show both. It is done when a sample of closed tickets can be traced end to end by an independent reviewer.

Evidence that shows erasure works and how to keep it current

An erasure program is only as credible as the records behind it. The six artifacts below show a regulator or assessor what was requested, what was deleted, where copies lived, and why any data was kept. Each one needs a refresh cycle so the evidence still matches the systems as they are today.

Erasure request register

A single log of every erasure request with the date received, the identity check outcome, the Article 17(1) ground relied on, the deadline, and the date of completion or refusal. Timestamps must come from the ticketing system, not from memory. Check monthly that every open request has an owner and a due date, and sample closed requests against the deletion records to confirm the two agree. Ticketing tools such as GLPI or Zammad can hold this trail if their audit history is kept.

Deletion test results per system

For each system holding personal data, a documented test that a record marked for erasure is gone from the primary store, search indexes, caches and exports. Run the test on a copy of production data with a known test subject, and repeat it after each release that touches storage. Record the query used, the result and the tester. Gaps found here are the ones the EDPB's 2025 coordinated action flagged, so a clean test history is strong evidence.

Backup expiry and restore-erasure procedure

A written rule for how long erased data can survive in backups, and what happens when a backup is restored after an erasure has been completed. Document the backup retention period, the job that expires old sets, and a step that re-applies pending erasures after any restore. Bareos keeps a catalog of backed-up files that can help locate affected sets, and restic's check with read-data options can confirm the repository is intact. Verify the procedure with a restore test at least once a year.

Retention schedules

A schedule that states, for each category of personal data, how long it is kept and which trigger starts the clock, such as contract end or last customer activity. Erasure is most often refused or delayed because a retention period was never defined. Review the schedule against the record of processing whenever a new system is added, and confirm that automated deletion jobs match the periods written down. Legal retention duties should be cited by source.

Recipient notification logs

A record of each third party that received the data and was told about an erasure, with the date and method of notice. Article 19 requires this unless informing recipients is impossible or disproportionate, and Article 17(2) adds a duty to inform other controllers when data was made public. Keep the recipient list tied to data flows so new processors appear automatically. Review the list at each sub-processor change and retest the notices sent in the last cycle.

Exception decisions with reasons

A written decision for every request refused in whole or part, naming the Article 17(3) exception relied on, such as legal claims or compliance with a legal obligation, and the data it covers. Record who approved the decision and when it expires, so the retained data is reviewed rather than kept indefinitely. Assessors will test whether refusals are narrow. Re-review open exceptions on each retention schedule cycle and close those that no longer apply.

What meeting Article 17 costs in money and effort

This table compares the cost components of meeting Article 17 erasure duties, who is paid for each, whether it is one-time or recurring, and what drives it up. The GDPR requires no certificate, so every cost comes from the controller's own work, and the main takeaway is that the largest recurring costs sit in backups, replicas and evidence upkeep rather than in the first deletion job.

Cost component	One-time or recurring	Cost drivers	How to reduce it
Data mapping for erasure	One-time, then recurring as systems change	Number of systems holding personal data, undocumented copies, third-party recipients under Article 19	Keep a current map of stores and recipients tied to the record of processing; confirm ownership of each system
Engineering deletion across systems	One-time build, recurring maintenance	Number of data stores, foreign keys, search indexes, caches, files and logs that reference a person	Design a single erasure workflow with per-system connectors; prioritize stores where deletion is hardest
Backup and restore handling	Recurring	Backup retention periods, whether backups can be selectively purged, how restores re-introduce erased data	Ask the backup vendor whether single-record deletion is supported; document a restore procedure that reapplies erasure
Replicas, logs and analytics copies	One-time analysis, recurring checks	Number of read replicas, data warehouse copies, log retention and downstream exports	Set shorter log retention where lawful; propagate erasure to replicas automatically rather than by hand
Tooling and licenses	Recurring for commercial products, one-time for setup	Licensing model, seat counts, support tiers, storage for audit records	Compare open-source options for ticketing and backup against current licenses; confirm total cost with each vendor
Evidence upkeep	Recurring	Volume of erasure requests, depth of logs kept, retention of deletion certificates and exception decisions	Automate request logs and deletion confirmations; keep a short, standard evidence template
External testing or review	Periodic, usually fixed-scope	Number of systems in scope, whether deletion is tested end to end, whether backups are sampled	Agree a written scope that names systems and test cases before work starts; ask for a quote per scope
Auditor or regulator sampling	Recurring as the control is examined	Size of the request population, number of exception decisions, quality of recorded reasons	Keep request records complete and consistent so samples can be pulled quickly; ask advisers which records an assessor would request

Self-hosted open-source tools that support erasure evidence

Article 17 is tested through records: when a request arrived, what was decided, and where the data went. The four tools below cover two sides of that trail, the request and decision record and the backup handling record. Each one produces evidence, but none of them erases data on its own, so confirm fit for your environment before relying on them.

GLPI for request tickets

GLPI's Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics and a Kanban view. For Article 17, a ticket can hold the erasure request, the grounds claimed, the Article 17(3) exception considered, the systems searched and the date each step closed. Check whether your team will keep these tickets free of unnecessary personal data, and confirm that GLPI's licence, GPL-3.0-or-later, fits your distribution and internal use. Each ticket should record the decision, not just the closure.

Zammad for requester correspondence

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. For erasure requests that arrive by email or web form, it keeps the requester's messages, identity follow-up and replies in one place. That makes it easier to show when the request was received and when the response was sent. Confirm how your configuration handles deletion of ticket content, since the message history is itself personal data, and confirm that the AGPL-3.0-only licence fits your hosting and modification plans.

Bareos for backup catalogs

The Bareos Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. The catalog shows which files sit in which backup and can restore files from the current backup or one before a given date and time. Erasure teams can use it to see where a person's data may persist in older backups. Backups still need a documented erasure approach, such as a stated restore-and-re-erase procedure or a retention rule, because the catalog records that data exists rather than removing it. Confirm the AGPL-3.0-only licence fit before you deploy.

restic for snapshot integrity

restic check verifies the structural consistency of snapshots, trees and pack files. With --read-data or --read-data-subset, it reads pack files back to confirm the stored backup data is unmodified. This helps show that backup repositories are intact and that a restore will not bring back corrupted or unexpected content. It does not decide which records must be erased. Document how you handle personal data in retained snapshots, and confirm the BSD-2-Clause licence fits your environment before adoption.

Who owns erasure work, what partners can take on, and where the auditor stops

As controller, your organization remains responsible for every erasure decision under Article 17. Your privacy and legal staff, and the data protection officer where one is designated, decide whether a request is valid, which of the Article 17(1) grounds applies and whether an Article 17(3) exception keeps the data. Your team also keeps the record of each request and the reasoning behind every refusal, because that record is what a supervisory authority will read first.

Decisions and exceptions: Confirm which ground applies and document why any exception, such as a legal obligation or the establishment, exercise or defence of legal claims, keeps specific data.
Request records: Keep dated entries for receipt, identity checks, decisions, systems touched and confirmations sent to the requester.
Recipient notices: Decide which recipients must be told under Article 19 and, where notice is impossible or disproportionate, record the reasoning.
Backup and retention policy: Set how long erased data may persist in backups and state what must happen to restored data before it is used again.
Data inventory: Maintain the map of where personal data sits, since every other party depends on it.

Check that a named person signs off each refusal and that your written policy matches what the systems actually do.

Questions buyers ask about Article 17 cost, effort and outside help

How much effort does it take to make erasure work across our systems?

The effort depends less on the deletion request itself than on how many places personal data sits. A single database delete is quick. The work grows with each system that holds a copy: production databases, search indexes, analytics stores, file shares, email archives, support tools, and the backups and logs that keep older copies. No published figure for the effort of this work was supplied, so ask any partner to estimate it per system after an inventory. The useful unit to price is the number of data stores and recipients in scope, not the number of requests. Expect one-time effort to map the stores and build deletion paths, then recurring effort to run requests and test them.

How long does an erasure project take, and what changes the timing?

No duration for an erasure project was supplied, so treat any single number with caution. The timing is driven by four factors: how many systems hold personal data, whether deletion can be done by hand or needs code changes in products, how backups are handled, and whether vendors or sub-processors must be contacted. Article 17 requires erasure without undue delay, so the project should aim for a repeatable process that works within the response window set by Article 12. Ask for a written plan with phases, owners and dependencies before agreeing a date.

What must our team supply before an outside partner can start?

A partner can only prepare erasure controls if your team provides access and decisions. Expect to supply: a list of systems and vendors that process personal data, read-only access to those systems or their documentation, the retention rules and legal grounds your lawyers have set, named owners who can approve deletion in each system, and the backup schedule and retention settings. Your team also needs to decide how an erasure must be recorded and how exceptions under Article 17(3) are handled, since a partner cannot make those legal calls for you.

Can our own engineers and privacy team handle erasure in-house?

Many organizations can, especially when the number of systems is small and the data flows are well understood. Internal teams usually need help with three areas: finding every copy of personal data, designing deletion that reaches backups, replicas and logs, and testing that deletion actually happens. The organization always owns its controls and its decisions on what must be kept. An implementation partner can prepare systems, scripts and evidence, but it does not replace your privacy function. A useful test is whether your team can show, for a sample request, every place the data was removed and where the record of that action is kept.

Does an auditor certify that we comply with Article 17?

No. The GDPR requires no audit, attestation or certificate, and no certificate for Article 17 exists. Certification under Article 42 is voluntary, issued by accredited certification bodies or supervisory authorities, and it does not reduce your responsibility for compliance. Supervisory authorities enforce the rules and can order erasure under Article 58(2)(g). Any independent review you commission can test your controls and evidence, but it produces a report on those controls, not a GDPR certificate. Be cautious of any vendor who sells an Article 17 certificate. The GDPR text on EUR-Lex is the primary source to check.

How should we scope a fixed-scope quote for erasure work?

A fixed-scope quote is only as clear as its written scope. Ask for the scope to list: the systems and data stores covered, the deletion paths to build or test, how backups and logs are handled, the evidence to be delivered, what your team must supply and approve, and what is excluded. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and does not publish a price list, so a quote follows from that written scope. Compare proposals on the same list of systems and deliverables, and check whether ongoing request handling or testing is priced separately as a retainer.

How DeployOpen scopes and prepares erasure for self-hosted platforms

DeployOpen plans and builds the self-hosted platforms that hold personal data, then prepares the erasure workflow, backup handling and evidence that show Article 17 Right to erasure is applied inside your own infrastructure. The organization remains responsible for its decisions on each request, and an independent assessor or regulator judges the result.

How we scope

Map every system, replica, backup set and log store that holds personal data for the erasure scope
Record which grounds under Article 17(1) and which Article 17(3) exceptions your workflows must handle
Agree in writing which downstream recipients and public sources need Article 19 or Article 17(2) notices
Confirm the scope boundary, deliverables and timelines before any work starts, as engagements are fixed-scope

How we build

Configure ticket intake and routing for erasure requests in self-hosted helpdesk tools such as Zammad or GLPI
Set up backup retention and restore behavior in Bareos or restic so deleted records cannot silently return
Design deletion or anonymization steps per system, documenting where anonymization replaces deletion and why
Test erasure end to end in a non-production copy before rollout to the live environment

How we hand over

Deliver a written erasure runbook covering intake, identity checks, system-by-system steps and sign-off
Provide logs and request records that show who acted, when, and which systems were changed
Document backup expiry behavior and how restored backups are re-checked for requested erasures
Hand over configuration, test results and open items so your own staff can operate the workflow

How we support

Offer ongoing support and upgrades for the platforms and erasure workflows through a retainer
Review the workflow when new systems, recipients or backup locations are added to the environment
Prepare evidence packs for your independent auditor or supervisory authority, without issuing any attestation ourselves
Run periodic erasure tests against retained backups and replicas as part of continuous security testing

Article 17 Right to erasure