“Delete Account” Is Not Enough: The Technical Erasure Test for Websites and SaaS

A user clicks “Delete account.” The profile disappears, sign-in stops working, and the application shows a confirmation.

Behind the interface, however, their email address remains in a support ticket, an exported CSV sits in a team folder, uploaded files survive in object storage, product events remain in analytics, a subscriber exists at the email provider, and an identity object is still active in the authentication service. A later restore from an older backup may even bring some of the deleted data back.

That is not necessarily deletion. It may be only the removal of the visible account surface.

The gap is particularly relevant in 2026. On 18 February 2026, the European Data Protection Board published the outcome of its coordinated action on the right to erasure. Thirty-two data protection authorities participated and 764 controllers responded. Recurring challenges included missing internal procedures, insufficient information for individuals, and ineffective anonymisation being used as an alternative to deletion.

The useful technical question is therefore:

Can your system remove personal data across the entire data chain, or does it delete only the most obvious database row?

Erasure is not one SQL statement

In a small application, the operation looks straightforward: DELETE FROM users WHERE id = ....

Real websites, shops, and SaaS products distribute identity across many systems:

• user and profile tables
• identity providers and active sessions
• orders, bookings, or contract records
• form submissions and CRM
• support and ticketing tools
• newsletter and marketing platforms
• uploads, avatars, documents, and audio
• analytics and product events
• search indexes, caches, and warehouses
• email providers and delivery records
• application, security, and infrastructure logs
• exports, reports, and local working copies
• backups
• external processors

A deletion workflow does not always have to destroy every record immediately and indiscriminately. The right to erasure is not absolute; retention duties and other exceptions may apply to particular data. The system therefore needs an explicit decision for each data category: erase, effectively anonymise, retain under restriction, or continue processing for a documented reason.

What is not a reliable strategy is leaving data untouched because nobody knows where it lives.

The dangerous difference between an account and a person

Many systems model an account without modelling every piece of data associated with the person.

For example:

• The account uses internal ID usr_2841.
• The CRM knows only jenny@example.com.
• The support platform assigns its own contact ID.
• File names contain the old email address.
• Analytics uses a pseudonymous device or user ID.
• Invoices reference a payment-provider customer ID.
• Logs contain request paths, IP addresses, or submitted fields.

Deleting only usr_2841 leaves those relationships behind. A complete workflow needs identity resolution: which stable and permitted identifiers connect records across systems, and how can the application find them without creating unnecessary new copies of personal data?

That work is less visible than a new settings button. It is also the difference between a UI feature and an operationally credible process.

Nine red flags in account-deletion implementations

1. The button only disables sign-in

The account receives a deleted_at timestamp while profiles, files, events, and processor data remain unchanged. Soft deletion may be useful for recovery or review, but it is not a complete erasure strategy by itself.

2. Email addresses are replaced with placeholders

max@example.com becomes deleted-user-123@example.invalid, while names, free text, IP addresses, order history, and uploads remain. This is not effective anonymisation when the person can still be identified.

3. Background jobs can fail partially

The identity account is removed, but the CRM call fails. The system still marks the entire request as complete. Without per-step state, retries, and escalation, partial success becomes invisible.

4. Processors depend on somebody remembering

Newsletter, CRM, support, hosting, analytics, or file-processing providers retain data because there is neither an API action nor an owned manual task. CNIL developer guidance explicitly recommends providing for automatic notification of processors as part of an erasure implementation.

5. Backups can resurrect deleted records

A restore loads an older data set and no deletion tombstones or post-restore actions run. Previously handled personal data becomes active again.

6. Logs copy the complete erasure request

To prove that deletion occurred, the application writes the person's name, email, request body, and data snapshot into a long-lived audit log. The deletion process creates a new and unusually persistent personal-data archive.

7. Exports are invisible to the source system

Sales, support, or finance exported a CSV. The primary application no longer knows it exists. Without export inventory and expiry rules, nobody can reliably identify every copy.

8. The next sign-in recreates the account

Social login or an external identity provider automatically provisions a new local record. Old marketing state, identifiers, or events reconnect to it.

9. Nobody tests the end-to-end path

The happy-path test removes one user from the main database. It never covers processor outages, large file collections, in-flight jobs, parallel sessions, restores, or delayed webhooks.

A defensible technical erasure workflow

1. Build the data map before automating

Create an inventory for every relevant data category:

• system and owner
• identifiers
• purpose
• storage location
• retention rule
• possible exception
• technical action
• evidence
• failure and escalation path

Without that map, teams automate only the systems they happen to remember.

2. Verify the request securely

An account-deletion endpoint is a high-impact function. Knowledge of an email address must not allow an attacker to destroy someone else's account.

Depending on risk, controls may include:

• an authenticated session
• password or MFA re-authentication
• CSRF and session-hijacking protection
• a defined recovery path for compromised or inaccessible accounts
• rate limits and abuse detection
• secure manual review for exceptional cases

Verification should remain proportionate. It must not become deliberate friction that makes the right practically impossible to exercise.

3. Orchestrate a workflow instead of one long request

Cross-system erasure takes time and services fail. A resilient implementation creates a dedicated case with its own identifier and explicit states, such as:

• requested
• identity verified
• processing
• partially failed
• pending manual review
• completed
• partially retained under a documented exception

Every action should be idempotent. A retry must not create duplicate side effects or an ambiguous state.

4. Apply the correct action in each system

Different stores require different treatment. Actions may include:

• deleting a record
• removing a file and its derivatives
• updating the search index
• invalidating caches
• revoking tokens, sessions, and API keys
• deleting or suppressing a marketing profile
• calling a processor API
• effectively anonymising data
• isolating legally retained records and restricting access

“We anonymise everything” is not a specification. Teams need to verify whether direct and indirect identifiers genuinely prevent re-identification.

5. Track every processor separately

Each processor should have a visible outcome inside the erasure case:

• confirmed
• API failed
• manual task created
• not affected
• retention documented
• further review required

A successful API response is not always proof that the provider completed the requested action. Where supported, process webhooks, status checks, or documented confirmations.

6. Keep evidence without building another data lake

OWASP recommends logging user-administration and deletion events, while also advising against putting sensitive personal information directly into logs without necessity.

A useful audit record may contain:

• internal case identifier
• timestamp
• authenticated actor or role
• affected system class
• action
• result
• error code
• release version
• final state

Names, full email addresses, content, and tokens do not belong automatically in every log entry. Evidence should prove that the workflow ran without preserving the data it was meant to remove.

7. Give backups their own lifecycle

CNIL guidance describes two implementation paths: erase data from backups as well, or ensure that erased data is not restored.

Modifying immutable backup archives in place may be impractical or undermine their integrity. In that case, the control set should include at least:

• a documented retention period
• tightly restricted access
• no ordinary operational use
• automatic expiry or overwrite
• deletion tombstones or a reapplication ledger
• a restore-runbook step that removes erased identities before release
• a test proving that the protection works

A backup must not become a time machine that silently reverses completed erasure work.

8. Test the workflow as a real user journey

A meaningful test creates a synthetic user with unique markers and deliberately distributes data across every expected system:

1. Create the account and profile.
2. Submit a form, upload a file, and open a support case.
3. Trigger newsletter or CRM integration.
4. Generate analytics events and logs.
5. Request erasure.
6. Verify every system status.
7. Search storage, indexes, caches, and processor data.
8. Simulate one failing dependency and test retry behaviour.
9. Restore an isolated backup.
10. Confirm that the deleted identity is not reactivated.

“The user row is gone” is only one assertion in that test.

What Website-Pflichtencheck would inspect

A technical erasure and data-lifecycle review can examine:

• visible deletion and rights-request routes
• secure identity verification
• the data inventory and identifier mapping
• the primary database, authentication, files, and search indexes
• CRM, newsletter, support, and analytics integrations
• sessions, tokens, and webhooks
• orchestration, retries, and partial outcomes
• logging and data minimisation
• backup and restore behaviour
• exports and manual working copies
• user-facing status and communication
• automated regression tests

The outcome should not make an unsupported promise that “everything is deleted.” It should explain, system by system, what was removed, what remains for a documented reason, who owns each action, and how failures become visible.

A delete-account button is quick to build. A deletion workflow that can find data across years of accumulated integrations, handle it correctly, and stop it returning from backups is real product and operational quality.

When you cannot identify which systems still know a user after account deletion, you do not have a completed erasure process. You have a hopeful button.

Note: This article is a technical overview and not legal advice. Whether particular data must be erased or retained should be assessed for the specific circumstances.