Handling GDPR Right to Be Forgotten Requests: A Practical Workflow for Compliance Teams

Handling a GDPR right to be forgotten request comes down to four moves: verify the requester's identity, assess whether the request is valid under Article 17 and whether any exception in Article 17(3) applies, execute erasure (or issue a reasoned refusal) within one month, and document everything you did and why. This article walks through each step for DPOs, compliance leads, and operations managers at SaaS companies — including the genuinely tricky case where the data subject's personal data lives inside signed contracts and audit trails you may not be allowed to delete.

This guide is educational and reflects publicly available GDPR provisions (Art. 12(3), Art. 17, Art. 17(3), Art. 5(2)). It is not legal advice; confirm edge cases with your own counsel or supervisory authority guidance.

What the GDPR Right to Erasure Actually Covers

Article 17 of the GDPR gives any EU/EEA data subject the right to obtain erasure of their personal data "without undue delay" when one of six grounds applies. In practice, the grounds that matter most to business teams are:

• The data is no longer necessary for the purpose it was collected for.
• The data subject withdraws consent and there is no other legal basis for processing.
• The data subject objects to processing and there are no overriding legitimate grounds.
• The data was processed unlawfully in the first place.
• Erasure is required to comply with a legal obligation.
• The data was collected from a child in relation to information society services.

Two scoping points trip teams up early. First, the request applies to personal data — information that identifies a natural person — not to companies, not to anonymized data, and not to data you never actually held. Second, the right applies to data held anywhere you control it: production databases, CRMs, marketing automation tools, support tickets, e-signature platforms, backups, and any downstream processors you've shared it with. Article 17(2) adds that if you've made the data public, you must take reasonable steps to inform other controllers processing it that erasure was requested.

The One-Month Clock (and When You Can Extend It)

Article 12(3) sets the deadline: respond without undue delay, and in any event within one month of receiving the request. The clock starts on the day you receive the request, not the day your ticketing system routes it to the right queue — which is why intake discipline matters so much.

You may extend the deadline by up to two additional months, but only when the request is complex or you have received a number of requests. If you extend, you must tell the data subject within the first month, explain why, and state the new deadline. "We were busy" is not a complexity justification. Multi-system reconciliation, large data volumes, or genuinely conflicting legal obligations can be.

Treat the deadline as a hard operational constraint: acknowledge receipt within a few days, target completion well inside the month, and build the extension letter as a template so invoking it is a decision, not an ad-hoc scramble.

Verifying the Requester's Identity Before You Delete Anything

Erasure is irreversible, which makes identity verification the highest-stakes step in the workflow. Article 12(6) lets you request additional information necessary to confirm identity where you have reasonable doubts about who is asking.

Proportionality is the governing principle: ask for enough proof to be confident, but do not demand more data than you already hold, and never use the request as an excuse to collect new personal data. Practical approaches that scale well include confirming control of the email address on file, asking for a transaction or account reference only the data subject would know, or using an existing verified login. If the person is contacting you through the same authenticated channel they used before, that channel itself is usually sufficient.

If you still cannot confirm identity, you can decline to act — but say so, explain why, and tell the requester what would resolve the doubt. Note the parallel with signing workflows: the same verification techniques used to authenticate signers, such as two-factor authentication for signers, are useful precedents for how much assurance is "enough" when someone asserts an identity remotely.

When You Can Refuse or Restrict an Erasure Request

Article 17(3) lists the situations where the right does not apply. The table below maps the most common business cases, whether refusal is generally defensible, and what you should put in the record.

Two habits keep refusals defensible. First, refuse partially where you can: erase marketing data and support correspondence even if contract records must be retained. Data minimization applied to the refusal itself is exactly what regulators expect. Second, always respond — a refusal is a response, and it must cite the exception relied on and inform the requester of their right to complain to a supervisory authority or seek a judicial remedy.

The Signed Contract Problem: Erasure vs. Signature Evidence

The sharpest tension in practice involves signed agreements. A former customer exercises Article 17, and their name, email, IP address, and signing events sit inside executed contracts and audit trails. Deleting them feels wrong; keeping everything feels like ignoring the request.

The usual resolution is layered. First, signed contracts that document obligations between parties generally fall under the legal-claims exception or a statutory retention obligation — you keep them, and you say so in your response. Signature evidence exists precisely to prove who agreed to what; e-signature audit trails like the certificate of completion attached to every envelope are designed as tamper-evident records of exactly that.

Second, apply minimization to everything around the core record. Marketing profiles, product analytics, support chats, and draft or unexecuted documents tied to the person can typically be erased. Third, where a document must be retained but the person's ongoing identification isn't needed, consider anonymization or pseudonymization of non-essential fields — redacting a personal email while retaining the signed instrument, for example — rather than wholesale deletion of evidence you may later need in a dispute. Properly anonymized data falls outside GDPR scope entirely; the bar for "properly" is high, so treat it as a legal call, not a technical default.

This is also a procurement lesson. When evaluating platforms, check how vendors handle retention, deletion, and residency before you sign — resources like the GDPR and eIDAS buyer checks for Adobe Sign users and guides to eIDAS-compliant electronic signatures show the questions mature buyers ask about exactly these controls.

A Step-by-Step Workflow for Handling Erasure Requests

Use this checklist as a repeatable operating procedure.

1. Intake and log. Record the request, receipt date, channel, and requester details in a dedicated register the same day it arrives. Assign an owner.
2. Acknowledge. Confirm receipt to the requester, state the one-month deadline, and set expectations.
3. Verify identity. Apply proportionate verification. Pause the substantive work only if verification genuinely fails, and document the doubt.
4. Scope the data. Query every system where the person's data lives — CRM, billing, support, marketing, product analytics, e-signature platform, data warehouse, and backups. Include processors and sub-processors.
5. Assess grounds and exceptions. For each data category, record the erasure ground, any Art. 17(3) exception, retention obligations, and litigation holds. Get legal sign-off on contested items.
6. Execute. Erase what must go, anonymize where appropriate, retain what you must keep. Issue deletion instructions to processors and confirm completion.
7. Respond. Tell the requester what was erased, what was retained, the legal basis for each retention, and their right to complain to a supervisory authority.
8. Document and review. File the full record in the register; note any extension invoked; schedule deletion of retained data at the end of its retention period.

Documentation and Accountability Under Art. 5(2)

Article 5(2) — the accountability principle — means you must be able to demonstrate compliance, not merely achieve it. Your request register is the core artifact: each entry should capture receipt date, identity verification method, systems searched, decisions per data category, exceptions cited, actions taken, processor confirmations, response date, and response content.

Two supporting controls pay off disproportionately. A data map kept current makes step 4 of the workflow fast instead of forensic. And vendor diligence ensures your processors can actually honor deletion instructions — security attestations such as a SOC 2 Type II report tell you a vendor's controls are independently examined, and platform features like e-signature solutions with audit trails keep the evidence side of your records defensible even as you minimize personal data elsewhere.

Finally, reconcile erasure with fraud risk: deletion requests are a social-engineering vector, so route unusual requests through the same skepticism you'd apply to e-signature fraud risks in general — verify before you act.

Simplify Compliance Workflows with Nota Sign

Handling erasure requests well depends on knowing where personal data sits in your document stack — and on platforms that give you clear audit trails, retention controls, and regional data residency options. Nota Sign, FaDaDa's global e-signature platform, is built for exactly this operating environment: IDC-ranked #1 in China's e-signature software market for consecutive years, with legal coverage across 100+ countries and regions and deep APAC compliance capabilities including iAM Smart, Singpass, SES/AES/QES signature levels, and regional data centers.

Nota Sign's pricing model also stays compliance-team friendly: there are no per-seat fees, so small teams can roll out governed signing without headcount-based cost creep, while mid-market and enterprise buyers can get tailored plans matched to their data residency and workflow requirements.

If you're reviewing how your e-signature stack handles audit trails, retention, and cross-border data, talk to the Nota Sign team about your compliance requirements.