WhatsApp DSARs and the Right to Erasure: Deleting With Evidence

Data subject requests are where messaging architecture gets tested. A conversation thread is dense personal data — contact details, message bodies, media, timestamps, staff notes — and you have one month to produce it or erase it, and to show that you did. Most platforms make the first part easy and the second part quietly impossible.

What is actually owed

• Access (Article 15): a copy of the personal data you hold about the person, plus the purposes, recipients, retention periods and the source if it was not them.
• Erasure (Article 17): deletion where the data is no longer necessary, consent is withdrawn and there is no other basis, they object with no overriding grounds, or the processing was unlawful.
• Portability (Article 20): for data processed on consent or contract by automated means, in a structured, machine-readable format.
• Deadline (Article 12(3)): one month, extendable by two for complex requests provided you notify within the first month.

Erasure is not absolute. A legal retention obligation — tax, clinical records, an ongoing dispute — can override it for the specific dataset covered by that obligation. It rarely covers the whole messaging estate, so scope the exception rather than refusing the request wholesale.

The soft-delete problem

On a multi-tenant platform, "delete" is usually a flag. The row stays, because the vendor's schema, analytics pipelines and search index are shared across every customer and hard deletes are operationally awkward. Then there are backups: retained on the vendor's schedule, often 30 to 90 days or longer, across regions you did not choose. Regulators accept that data in backups cannot always be surgically removed immediately — but they expect the backup to be put beyond use and overwritten on a defined cycle you can describe. If you cannot say what that cycle is, you cannot answer the question.

The practical exposure is not the flag itself. It is that you told the data subject their data was deleted while it remained queryable in a system you do not control.

What a hard delete looks like

On a single-tenant instance, the database is yours, so erasure can be a real DELETE across every table that holds the subject: the contact record, message bodies and media objects, delivery logs, tags and segment memberships, staff notes, and any derived copies in search or analytics. Backups are on your retention policy, in your region, with a rotation window you can state in writing.

What survives is a deletion receipt: the request reference, the identity verification, the scope, the record counts and the timestamp — evidence of the erasure that contains no reconstructable personal data. The mechanics are documented in erasure requests.

A workflow that holds up

1. Log the request on arrival with its date, in one place, whatever channel it came through. The one-month clock starts here.
2. Verify identity proportionately. Confirm control of the phone number or account; do not demand a passport scan for a request about a phone number, which would collect more data than you are being asked to release.
3. Scope it. Resolve every record keyed to that person — contacts merged from multiple sources, historic numbers, threads on other channels.
4. Check for overriding obligations before deleting, and record which dataset each one covers.
5. Execute: export for access requests, hard delete for erasure, and redact third-party personal data in anything you hand over.
6. Respond and file the receipt within the month, keeping the evidence in the audit trail — see audit and evidence.

One note on transport

Erasing your records does not reach into Meta's transport layer or the recipient's own copy of the conversation on their phone — neither is yours to delete, and neither is expected of you. Your obligation covers the data you control as controller, which is everything downstream of delivery. Say so plainly in your response rather than over-promising.

The short version

Assume every request will one day be checked. That means deletion that reaches the actual records, backups on a retention cycle you can describe, an export path that does not require a database engineer, and a receipt at the end of each. For the wider framework, start with the GDPR position on WhatsApp.