← All guides
GDPR9 min read19 May 2026

GDPR Right to Erasure: How to Handle 'Right to be Forgotten' Requests in SaaS

GDPR Article 17 gives users the right to delete their data. Here's exactly when you must comply, when you can refuse, and how to build a deletion workflow for your SaaS.

The right to erasure — commonly called the "right to be forgotten" — is one of the most operationally challenging GDPR rights for SaaS founders. It sounds simple: a user asks you to delete their data, and you delete it. In practice, it's far more nuanced.

This guide covers exactly when the right applies, when you can lawfully refuse it, and how to build a deletion workflow that keeps you compliant without breaking your product.

What GDPR Article 17 actually requires

Article 17(1) sets out six grounds on which a data subject can request erasure:

  1. The personal data are no longer necessary for the purpose they were collected or processed
  2. The data subject withdraws consent (and there is no other lawful basis for processing)
  3. The data subject objects under Art. 21 and there are no overriding legitimate grounds
  4. The personal data have been unlawfully processed
  5. Erasure is required to comply with EU or Member State law
  6. The data relate to a child and were collected in the context of information society services (Art. 8)

For a typical SaaS, the most common triggers are (1) — a user closes their account and there is no ongoing contractual or legal reason to hold the data — and (2) — a user withdraws marketing consent and asks you to delete their email address from your list.

When you can refuse: the Art. 17(3) exemptions

Article 17(3) explicitly carves out situations where you do not have to erase data, even on request:

  • Freedom of expression and information — rarely applies to B2B SaaS
  • Compliance with a legal obligation — if you are legally required to retain data (e.g., tax/accounting records, financial transaction logs), you can refuse to delete that specific data for the legally required retention period. You must still delete everything else.
  • Public interest / scientific / historical / statistical purposes — narrow; unlikely to apply to most SaaS
  • Establishment, exercise, or defence of legal claims — if a user is in a billing dispute and you need their transaction records to defend the claim, you may retain that data. This is a temporary exception, not a permanent one.

Practical upshot: You can refuse to delete billing records that you're legally required to keep for 7 years. You cannot refuse to delete a user's profile, usage data, or marketing preferences just because it would be convenient for you.

The partial erasure problem

GDPR doesn't require you to delete data you genuinely cannot identify as belonging to the requester, or data that has been properly anonymised. But it does require you to erase personal data even if deletion is technically inconvenient. Common SaaS scenarios:

  • Database records: straightforward — delete the row and cascade to related tables
  • Backups: this is where most SaaS stumble. GDPR requires deletion from backups — but not necessarily immediately. The accepted approach is to delete from live systems promptly, flag the backup for deletion on its next rotation, and document this procedure in your Data Retention Policy. If a backup is only kept for 30 days, the personal data will be gone within 30 days.
  • Logs: application and access logs often contain email addresses or user IDs. Your retention policy should set a short TTL for logs (e.g., 90 days). Until rotation, document that logs are operational and not used to re-identify users.
  • Third-party sub-processors: you must also instruct your sub-processors (email service, CRM, analytics) to delete the user's data. Include this in your DPA chain.
  • Aggregated / anonymised data: if the data has been properly anonymised (not just pseudonymised), GDPR no longer applies. You don't need to delete aggregate analytics that cannot identify the individual.

The response timeline

Under GDPR Article 12, you must respond to a right-to-erasure request within one month of receipt. You can extend by two additional months for complex or numerous requests — but you must notify the person within the first month that you are extending and explain why.

If you refuse, you must notify the person within one month, give reasons, and inform them of their right to lodge a complaint with the supervisory authority.

Building your deletion workflow

A practical deletion workflow for SaaS:

  1. Intake: provide a clear mechanism for submitting deletion requests — typically an email to privacy@yourdomain.com or an in-app form. Document every request with a timestamp.
  2. Identity verification: confirm the requester's identity before deleting anything. For logged-in users, the session is sufficient. For emailed requests, ask them to confirm from the account email address.
  3. Scope assessment: identify all systems that hold the user's personal data. Don't forget: your primary database, your email service provider (email history), your CRM (lead/customer record), your error tracker (if user context is logged), your analytics tool (user profile), your support system (tickets).
  4. Execute deletion: delete from live systems. For most SaaS, this means: delete the user record and cascade (or anonymise) related data, unsubscribe from email lists, delete from CRM, remove from error tracker, remove from support platform.
  5. Flag backups: document that the backup rotation will clear the data. If you have manual backups, plan for deletion on restoration or next rotation.
  6. Respond: confirm completion to the requester within one month. A simple email confirmation is sufficient.
  7. Log it: keep a record of deletion requests and your responses. If you're ever audited, you'll need to demonstrate you process these requests.

Anonymisation vs deletion

In some cases, full deletion is technically complex (e.g., it would corrupt relational data integrity). An alternative is anonymisation — replacing all identifying fields with anonymised tokens or NULL values so the record can no longer be attributed to an identifiable person. This satisfies GDPR if done properly.

Pseudonymisation (replacing names/emails with random tokens you can reverse-lookup) does NOT satisfy an erasure request. Anonymisation must be irreversible.

What to put in your Privacy Policy

Your Privacy Policy must explain:

  • That users have the right to request erasure
  • How to submit a request (email address, in-app mechanism)
  • Any applicable exceptions (e.g., legally required retention of billing records)
  • Your response timeline (one month)

Common mistakes

  • Treating erasure as optional: it isn't. Refusing or ignoring valid requests is a GDPR violation.
  • Forgetting sub-processors: deleting from your database while leaving the user's record in HubSpot, Intercom, and SendGrid is not sufficient. You must delete everywhere.
  • Using legal obligation to block all deletion: "we have to keep records" only covers data legally required to be retained. It doesn't cover your entire database.
  • No documentation: if a DPA asks whether you process erasure requests, "we handle it case by case" is not an acceptable answer. Keep a log.
  • No deletion from backups plan: "we can't delete from backups" is not an excuse. Document your backup TTL and rotation policy.

Tools to build on

ComplyKit can help you build the foundational documents for GDPR compliance:

More guides