Article 17: Right to erasure (‘right to be forgotten’)

GDPR Article 17 requires you, as a controller, to erase a person’s personal data “without undue delay” when a valid erasure ground applies, and to operationalize a repeatable process to find, delete, and confirm deletion across systems and third parties. Your job is to make erasure decisions defensible, consistent, and auditable. ¹

Key takeaways:

• Build an erasure workflow that ties intake, identity verification, decisioning, deletion execution, and confirmation into one tracked case.
• Erasure is conditional; you must evaluate whether an Article 17 ground applies and document exceptions and legal holds.
• Map data locations and third-party disclosures so deletion reaches production systems, downstream recipients, and key backups where feasible.

Article 17 (“right to be forgotten”) is easy to describe and hard to execute. The requirement is simple on paper: a data subject can request erasure, and the controller must erase personal data without undue delay when one of the grounds applies. ¹ The operational reality is a cross-functional workflow that touches customer support, privacy, engineering, security, data governance, legal, and procurement/third-party management.

As a Compliance Officer, CCO, or GRC lead, your goal is not to hand-write legal memos for each request. Your goal is to stand up a dependable operating model: clear ownership, scoped systems, standard decision criteria, and evidence that shows you executed the process consistently. Examiners and customers will focus on whether you can (1) find the data, (2) delete it correctly, (3) avoid accidental deletion when an exception applies, and (4) prove what you did.

This page translates Article 17 into requirement-level implementation steps, concrete artifacts to retain, and a practical execution plan that a serious operator can put in place and run.

Regulatory text

Regulatory excerpt (provided):
“1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:” ¹

What that means operationally:
You must run a process that (a) accepts and authenticates erasure requests, (b) determines whether a valid ground for erasure applies, and (c) executes deletion across the personal data footprint without undue delay, with a documented record of what was deleted (or why not). ¹

Plain-English interpretation (requirement-level)

Article 17 is a conditional deletion right. When a person asks you to delete their personal data, you are required to do so promptly if an erasure ground applies. If you cannot erase because an exception or conflict applies (for example, retention obligations or an active dispute), you still need a documented decision, and you should be prepared to explain and evidence the outcome. ¹

Think of it as a controlled “delete order” with governance:

• Front end: intake + identity checks + scope clarification (what data, what account, what relationship).
• Middle: decisioning + approvals + exceptions management.
• Back end: system actions + downstream notifications to third parties + confirmation + audit trail.

Who it applies to (entity and operational context)

Primary obligation holder: controllers. Article 17’s excerpt explicitly speaks to the controller’s obligation to erase without undue delay when a ground applies. ¹

Operational contexts where this shows up most:

• Consumer accounts: deleting profiles, preferences, device identifiers, support history, and marketing records.
• B2B SaaS: deleting end-user records within a customer tenant, plus logs/telemetry tied to identifiers.
• HR and recruiting: candidate and employee records subject to overlapping retention obligations.
• Marketing stacks: deletion across CRM, marketing automation, ad tech audiences, and analytics tools.
• Third parties: processors, sub-processors, and other recipients that hold copies of personal data you shared.

Key scoping decision you must document: are you acting as controller or processor for the data at issue, and which systems and third parties are in scope for erasure execution. This is a recurring failure point during assessments. ¹

What you actually need to do (step-by-step)

1) Establish role-and-scope for Article 17 execution

Create a living register that answers, for each processing activity/system:

• Your role (controller/processor) for the relevant dataset
• Data categories stored (account data, transactional data, logs, etc.)
• System of record vs copies
• Downstream disclosures (which third parties receive it)
• Deletion method available (API delete, hard delete, anonymize, suppression list)
• Known constraints (immutable logs, regulatory retention, security investigations)

This aligns directly to the best-practice control: maintain a GDPR role-and-scope register for this requirement. ¹

2) Define an Article 17 operating procedure with named owners

Write a procedure that an auditor can follow and an operator can run. Include:

• Intake channels: web form, email alias, support ticket, postal mail (as applicable)
• Case owner: privacy ops or DSAR team
• Required participants: Legal (exceptions), Security (fraud/abuse), Engineering/Data (execution), Procurement (third-party outreach)
• Decision authority: who can approve deny/partial grant and on what grounds
• Escalation triggers: high-risk identities, minors, regulated data, litigation hold

This is the second recommended control: define a requirement-specific operating procedure with named owners, trigger events, and required approvals. ¹

3) Intake and identity verification (avoid deleting the wrong person)

Operationalize a consistent identity verification (IDV) standard:

• Verify the requester controls the account or identifier in question.
• If no account exists, verify through reasonable means tied to the data you hold (for example, email ownership).
• Log the IDV method and result in the case record.

Common hangup: teams “helpfully” delete based on a name match. That is unsafe and hard to defend. Your evidence should show an IDV step happened before deletion actions.

4) Triage: define the deletion scope for the request

Before pushing delete buttons, confirm:

• Which products/tenants/regions are in scope
• Whether the user has multiple accounts
• Whether the request covers “all personal data” or specific datasets
• Whether you need to preserve minimal data to prevent re-contact (suppression) or manage fraud

Capture the scope statement in the case record. This prevents “we deleted one system” outcomes.

5) Decision: determine whether an erasure ground applies and document it

Article 17 requires erasure “where one of the following grounds applies,” so your process must include decisioning, not automatic deletion for every request. ¹

Minimum decision outputs to record:

• Outcome: granted / partially granted / denied
• Rationale: the ground relied on (or the reason erasure does not apply)
• Approvals: who approved the decision and when
• Constraints: legal hold, security investigation, statutory retention, etc. (record the constraint, not privileged legal analysis)

If you operate multiple product lines, require business owners to attest the applicable retention constraints for their datasets so privacy ops isn’t guessing.

6) Execute deletion across systems (with engineering-grade rigor)

Create a standard deletion runbook per system:

• System owner
• Exact deletion action (API endpoint, admin console steps, SQL job, queue message)
• Expected completion signal (job status, event log)
• Known propagation delays (cache, search index)
• Data types handled (structured tables vs unstructured blobs)
• What “erased” means for that system (hard delete, irreversible anonymization, key destruction)

Track each system action as a checklist item in the case. Attach screenshots/log extracts where feasible.

Backups and logs: define and document your position. Many teams cannot surgically delete from backups. Your defensible stance is to (a) ensure production is erased, (b) ensure backups are protected and rotated per retention, and (c) ensure restored data does not re-materialize into production without controls. Write this into the runbook and keep it consistent.

7) Downstream recipients and third parties: propagate erasure

If you shared the data externally, you need an operational path to notify relevant recipients/processors so deletion follows the data. Maintain:

• A list of third parties per processing activity
• Contact/portal method for deletion requests
• SLA expectation (contractual if possible)
• Confirmation capture (ticket closure, email confirmation, portal export)

This is where Daydream fits naturally: teams use it to keep the role-and-scope register, third-party mappings, and evidence packets in one place so privacy ops and procurement are not rebuilding the map for each request.

8) Confirm, respond, and close the case with an evidence packet

Close-out steps:

• Validate deletion success signals for each in-scope system
• Validate third-party confirmations where required/feasible
• Send a response to the requester consistent with your procedure
• Package the evidence so you can reproduce it later

This is the third recommended control: retain auditable evidence packets (decision record, control outputs, exceptions, and remediation) on a recurring cadence. ¹

Required evidence and artifacts to retain

Retain artifacts that prove execution, not just intent:

Artifact	What it should show	Where teams store it
Article 17 procedure	Owners, steps, approvals, escalation	Policy/GRC system + version control
Role-and-scope register	Controller/processor role, systems, data categories, third parties	GRC register (Daydream), RoPA tooling, CMDB
DSAR/erasure case record	Intake, IDV, scope, decision, timestamps, communications	Ticketing system with locked fields
Deletion runbooks	Per-system deletion method + validation	Engineering docs + change control
Execution evidence	Logs, job IDs, screenshots, query results	Attached to the case record
Exception/hold records	Reason for denial/partial, legal hold reference	Legal hold system + case link
Third-party confirmations	Recipient notified and response received	Procurement portal + case link

Retention tip: define a consistent retention period for DSAR case files based on your overall privacy compliance recordkeeping approach. Keep it stable and documented.

Common exam/audit questions and hangups

Expect these, and prep short, evidenced answers:

• “Show me the last few erasure requests end-to-end. Where is the proof of deletion?”
• “How do you verify identity before deleting?”
• “Which systems are in scope for erasure, and how do you know you didn’t miss shadow IT?”
• “How do you handle data shared with third parties?”
• “What happens with backups and immutable logs?”
• “Who can deny an erasure request, and what approval is required?”

Hangup pattern: privacy has a policy, but engineering has no standardized delete mechanism. Fix that with runbooks and an ownership model.

Frequent implementation mistakes (and how to avoid them)

1. No controller/processor role decision per dataset.
   Fix: enforce the role-and-scope register and require product owners to maintain it. ¹

2. Treating erasure as a support task, not a controlled workflow.
   Fix: a dedicated case record with required fields, approvals, and evidence attachments.

3. Deleting in one system only (CRM) and missing product databases, logs, and analytics.
   Fix: system checklist driven by the scope register, not by memory.

4. No third-party propagation.
   Fix: contract language plus a maintained disclosure map. Build deletion request steps into third-party offboarding and ongoing governance.

5. Weak evidence.
   Fix: standard evidence packet format: decision + checklist + system proofs + third-party confirmations.

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog for this requirement, so this page does not cite specific regulator actions.

Practically, Article 17 risk clusters into:

• Regulatory complaints: individuals escalate when you delay or give unclear outcomes. ¹
• Litigation discovery and spoliation risk: deleting when a legal hold should apply can create separate exposure; your exception workflow must be real.
• Security and fraud impacts: erasure without safeguards can enable account-takeover cleanup; involve Security for suspicious requests.

Practical 30/60/90-day execution plan

First 30 days (stand up the operating model)

• Assign a single accountable owner for Article 17 execution (privacy ops or DSAR lead).
• Publish the Article 17 operating procedure with required approvals. ¹
• Build the role-and-scope register for your highest-volume products and core systems (prod DB, CRM, support desk, marketing platform). ¹
• Define the case record template (required fields + evidence checklist).
• Pick a single intake channel and route everything into the same workflow.

Days 31–60 (make deletion real across the footprint)

• Write deletion runbooks for each in-scope system and validate them with engineering.
• Add third-party deletion steps for your key processors and data recipients.
• Run tabletop exercises: simulate one clean request, one identity dispute, one legal hold scenario.
• Start retaining evidence packets for each request as a non-negotiable output. ¹

Days 61–90 (operational hardening and audit readiness)

• Expand the scope register to include analytics, data lake, and internal tooling used by Sales/CS.
• Build monitoring: aged cases, missing evidence, third-party confirmation outstanding.
• Review a sample of closed cases for completeness and consistency; fix runbooks and required fields based on findings.
• Implement governance cadence: periodic refresh of the scope register and third-party mapping, tracked in Daydream so you can answer audits without rebuilding the story.

Frequently Asked Questions

Do we have to delete everything immediately when someone asks?

Article 17 requires erasure “without undue delay” when an erasure ground applies, so you must first validate identity, scope, and whether the request qualifies. Your procedure should define the decision and approval path, then execute deletion with evidence. ¹

How should we handle backups for erasure requests?

Define a consistent, documented approach: erase from production systems and prevent reintroduction, while managing backups through access controls and rotation. Record your backup stance in the runbook and keep evidence of the production deletion actions.

What if we’re a processor and receive an erasure request directly?

Route it to the controller (your customer) under your contract and internal procedure, then execute deletion when instructed. Keep a record of the request, the controller instruction, and your completion evidence so your response is auditable.

Can we deny an erasure request?

Article 17’s excerpt makes erasure conditional on “one of the following grounds,” so your workflow must support deny/partial outcomes when the conditions are not met. Document the decision, approver, and the specific constraint (for example, legal hold) in the case record. ¹

Do we need to notify third parties we shared the data with?

If personal data was disclosed to third parties, you need an operational method to propagate erasure through those recipients where applicable. Maintain a disclosure map and capture confirmations or ticket closures as evidence.

What evidence do auditors usually want for Article 17?

They want proof you can run the workflow end-to-end: intake, identity verification, decisioning, deletion execution across systems, third-party propagation, and a closure record. Keep a standardized evidence packet per case. ¹

Footnotes

1. Regulation (EU) 2016/679, Article 17