The right to erasure (Article 17 GDPR), often called the right to be forgotten, sounds simple on paper: a user asks to be deleted, you delete. In practice, every SaaS that grows past 1,000 users hits the same wall. Without a clear workflow, DSARs pull product engineers off roadmap to dig through services that should never have stored anything in the first place. The GDPR.eu primer covers the legal basics; this article covers the operational version.
The legal scope, in two sentences
A user can request erasure of their personal data when one of six grounds applies: the data is no longer necessary, consent withdrawn, objection sustained, unlawful processing, legal obligation, or child-collected data. You have 30 days to respond, extensible to 90 days for complex cases.
The grounds matter operationally because some erasures require pseudonymisation of legacy records (financial obligations) while others require full deletion. Your workflow needs to distinguish them.
The 5-step workflow that does not break your roadmap
Step 1: a single intake channel
One email or one form. Not three. Publish it in your privacy policy, your legal center and your in-app account page. Auto-acknowledge within 24 hours so the 30-day clock starts cleanly.
Step 2: identity verification proportionate to risk
Do not ask for a passport copy. The GDPR requires "reasonable measures" to verify identity. Email confirmation from the address on file plus a recent activity question is enough for most B2C cases. B2B with admin accounts may need a second factor.
Step 3: scope determination, by category
Personal data in your stack lives across categories. Map them once:
| Category | Default action | Exceptions |
|---|---|---|
| Account profile | Delete | None for B2C |
| Content created (posts, files) | Anonymise (replace user_id with deleted-user-N) | Public content needs takedown notice |
| Financial records (invoices) | Retain | Tax law typically requires 5-10 years |
| Logs / analytics | Pseudonymise then expire | Security incidents may extend retention |
| Backups | Document, do not restore deleted users | Some EU authorities accept tombstones |
Step 4: execution via a single internal script
One internal admin endpoint that, given a verified user id, executes the per-category action above and writes an audit row. Engineers build this once. Support runs it on every request. No more digging.
Step 5: confirmation letter with what stayed and why
Tell the user what you deleted, what you retained, and the legal basis for any retention. Generic confirmation emails fail audits. Specific ones build trust.
The most common failure mode is incomplete deletion in sub-processors. Stripe still has the customer, HubSpot still has the contact, your transactional email vendor still has the address. The endpoint script must trigger deletions in every sub-processor, or document why a particular sub-processor needs to retain (Stripe holds invoices for tax compliance, etc.).
The 30-day budget, broken down
- Day 1: acknowledge receipt, start clock
- Day 2-3: verify identity
- Day 4-7: scope review and decision
- Day 8-15: execute deletion across categories and sub-processors
- Day 16-25: buffer for complex cases or back-and-forth with the user
- Day 26-30: confirmation letter
If you are routinely using the full 30 days, the workflow needs work. Most SaaS that get this right close DSARs in 5-10 days.
When you can refuse erasure
- Freedom of expression and information (publishers, journalism)
- Legal obligation requiring retention (tax, anti-fraud)
- Public interest or scientific research with appropriate safeguards
- Establishment, exercise or defence of legal claims
Refusals must be documented and the user must be told within the same 30 days about their right to complain to the supervisory authority.
The GDPR.eu primer notes that the right to be forgotten "is not absolute". The operational corollary: clear refusal criteria save more time than aggressive deletion. Document the grounds you will not honor, and your team stops second-guessing every edge case.
Conclusion
A working DSAR workflow is the difference between an inconvenient request and a roadmap-killer. The five-step process above handles 95% of cases without engineering involvement after the initial setup. The remaining 5% (legal complexity, multi-account merges) deserve human review anyway.
If you want a privacy policy that already includes the right-to-erasure disclosure, contact channel, and timing commitment that match this workflow, try Termerly free and publish the version your team will actually execute.
