Right to Erasure Explained

Q: Is the right to erasure the same as delete my account?

Not always. Account deletion removes access, but erasure may require deleting personal data across multiple systems and vendors. A good workflow coordinates account closure, deletion, and opt-outs together.

Q: What about backups—do we have to delete from backups?

Many organizations manage backups through strict retention, security controls, and processes that re-apply deletions upon restore. Document your backup approach and keep retention proportionate to risk.

Q: What is the biggest risk with erasure requests?

Deleting the wrong person’s data or missing scattered data across tools and exports. Identity verification, data inventory, minimization, and system runbooks reduce both risks.

What the right to erasure is

The right to erasure (often called the “right to be forgotten”) allows individuals to request deletion of their personal data in certain circumstances. Under the GDPR, this is set out in Article 17.

The right exists to prevent organizations from holding onto personal data unnecessarily, using it beyond its purpose, or continuing processing when the legal justification no longer applies.

Switzerland note: Swiss data protection law also includes rights that can lead to deletion or correction, depending on context. If you operate in Switzerland and the EU, design one workflow that can handle both.

When erasure applies (common triggers)

Erasure requests are valid in specific scenarios. Below are the most common triggers in real operations.

Trigger	What it means	Example
Data is no longer necessary	You no longer need the data for the original purpose	Old leads retained without purpose or retention rule
Consent withdrawn	Processing based on consent and consent is withdrawn	Newsletter signup withdrawn (where consent is the basis)
Objection to processing	Person objects and you have no overriding justification	Direct marketing objection
Unlawful processing	The data was collected or used unlawfully	Collected data without proper transparency
Legal requirement to delete	A law requires you to delete the data	Data collected in violation of internal policy and must be removed

Practical note: Many “erasure” requests are actually a mix: deletion + marketing opt-out + account closure. Handle them as one coordinated workflow to avoid gaps.

When you can refuse or limit erasure (common exceptions)

The right to erasure is not absolute. Organizations can keep certain data when there is a valid reason to do so. This is where retention rules and legal obligations become essential.

Common exceptions (high-level)

Legal obligations: e.g., tax/accounting retention requirements.
Establishing, exercising, or defending legal claims: e.g., disputes, litigation holds.
Public interest / official purposes: context-dependent (rare for most private companies).
Freedom of expression/information: more relevant for publishers/media contexts.

Operational best practice: If you can’t delete certain data, don’t just say “no.” Explain what you will delete, what you must retain, why, and for how long.

A step-by-step erasure workflow

Treat erasure requests as both a compliance request and a security-sensitive action (account deletion is a takeover target). Build a ticketed workflow with approvals and logging.

Recommended workflow

Intake and log: record request date, requester identity, scope, and systems involved.
Verify identity: proportionate verification before deleting anything.
Clarify scope: account deletion? marketing opt-out? all systems? specific time range?
Check legal holds and retention: determine what must be retained and why.
Execute deletion plan: delete/anonymize/suppress across systems per playbook.
Confirm and document: record what was deleted, what was retained, and retention timelines.
Notify processors: if vendors process data on your behalf, trigger deletion requests as needed.
Close request: provide confirmation to the requester and store evidence securely.

Quick win: Create an “erasure runbook” for each major system (CRM, support, billing, HR). Without runbooks, teams miss hidden data (notes, exports, attachments).

Deletion vs anonymization vs suppression

Not all “removal” actions are the same. Choose the method that matches your purpose and legal constraints.

Method	What it is	When to use
Deletion	Data is removed so it can’t be used or retrieved	When there’s no valid reason to retain personal data
Anonymization	Data is transformed so it no longer identifies a person	To keep aggregated insights without personal identifiers
Suppression / blocking	Data is retained but restricted (e.g., blacklisted from marketing)	To respect opt-outs while keeping minimal records to enforce them

Important: “Pseudonymization” is not anonymization. If you can still re-identify the person using keys or lookup tables, it is still personal data and remains in scope.

How to delete across systems (practical approach)

The hardest part of erasure is execution across tools, backups, exports, and third parties. The solution is a system approach.

Build an “erasure map”

Systems: where personal data lives (CRM, billing, support, product DB, HR).
Data types: identifiers, transactions, tickets, logs, attachments.
Deletion method: delete vs anonymize vs suppress (per system and data type).
Dependencies: downstream tools fed by exports/integrations.
Owners: who executes and who verifies completion.

Backups and logs (common confusion)

Many organizations cannot surgically delete a person’s data from immutable backups. The common control pattern is: keep backups for a limited time, secure them, and ensure restored systems re-apply deletion where required. Document your approach and keep retention short.

Helpful tools (optional)

If you need secure approvals, traceability, and audit-friendly documentation for erasure workflows:

SignNTrack – secure e-signatures & tracking Innopulse – erasure workflows & privacy governance support

Disclaimer: Links are for convenience; choose tools based on your requirements and compliance obligations.

Right to erasure checklist (copy/paste)

Use this checklist to handle erasure requests consistently and defensibly.

We logged the request (date, requester, scope, channel).
We verified identity before deleting anything.
We confirmed the lawful basis/trigger and checked for exceptions (legal obligation, legal claims, holds).
We identified all systems and vendors holding the person’s data (using an erasure map).
We executed deletion/anonymization/suppression per system runbook.
We notified relevant processors/vendors and tracked completion.
We documented what was deleted, what was retained, why, and for how long.
We confirmed completion to the requester via a secure communication channel.

Quick win: Reduce your erasure workload by enforcing retention: delete old data automatically so erasure requests become simpler and faster.

FAQ

Is the right to erasure the same as “delete my account”?

Not always. Account deletion often removes access and disables the profile, but erasure may require deleting personal data across multiple systems and vendors. A good workflow treats account closure + deletion + opt-outs as one coordinated process.

Can we keep invoices or payment records even if someone requests deletion?

Often yes, if you have a legal obligation to retain accounting/tax records. In that case, delete what you can, restrict access, and explain what must be retained and the retention period. Seek legal advice for your jurisdiction.

What about backups—do we have to delete from backups?

Many organizations handle backups through strict retention, security controls, and processes that re-apply deletions upon restore. Document your backup approach and keep backup retention proportionate to risk.

What is the biggest risk with erasure requests?

Deleting the wrong person’s data (identity verification failure) or missing data because it’s scattered across tools and exports. Data inventory, minimization, and runbooks reduce both risks.

About the author

Leutrim Miftaraj — Founder, Innopulse.io

Leutrim is an IT project leader and innovation management professional (BSc/MSc) focused on governance and compliance-friendly digital execution for organizations in Switzerland, including privacy-by-design, operational controls, and audit-ready workflows.

Governance Privacy-by-design Process design Swiss market focus

Reviewed by: Innopulse Editorial Team (Quality & Compliance) • Review date: February 22, 2026

This content is for informational purposes and does not constitute legal advice. For case-specific guidance, consult qualified counsel.

Sources & further reading

Use primary legal texts and regulator guidance for interpreting erasure obligations in your specific context.

Last updated: February 22, 2026 • Version: 1.0

Want an erasure workflow that is secure and actually works?

Innopulse supports organizations with data mapping, retention design, deletion runbooks, and privacy-by-design governance—so deletion requests are handled consistently, safely, and without operational chaos.

Book a consultation Back to Data Protection & Compliance pillar Business & IT Consulting

Right to Erasure