Right to Erasure

For a long time there was no way to take back data once it had been handed over. Plenty of services shipped without a delete-my-account button at all, and the ones that had it never said what the button actually removed. Signing up took thirty seconds; getting out was not a defined operation.

The result looked like this. Someone closes an account with an online store and six months later receives a discount email from the same company. They write in and are told the account closure processed normally. The row in the member table was gone; the address in the email delivery list was not. From outside, there is no way to reconcile "you were deleted" with "mail keeps arriving."

Data persisting in search results widened the dispute further. Through the 2010s, demands in Europe to take down old records that surfaced under a person's own name were formalized as a right to be forgotten, and that shape spread into national laws elsewhere.

The right to erasure attaches a scope and a deadline to the word delete. A company that receives a request from a data subject has to find where the data actually sits, remove it, and, where something must stay for legal reasons, say what stays and why. The part that differs from before is that a notice claiming deletion is no longer the end of the transaction. What the company says it did and what its systems actually hold are now comparable, which is the whole point of the deadline and the disclosure.

Take the request, verify identity, separate out what has to be kept, delete the rest for real, and report back what was removed and what was not.

1. Intake and identity verification — through the channel named in the privacy policy. The check has to stop somebody deleting another person's account, while demanding excessive documentation counts as obstructing the right.
2. Find the scope. One person's data is not one row. It is spread across support threads, payment records, access logs, events sent to analytics tools, the email delivery list, and last night's backup. Without a map built in advance, building one becomes the first task on the day the request lands, which is how a ten-day clock gets spent on discovery rather than on deletion.
3. Separate what stays. Commerce rules commonly require payment records to be kept for five years, so those cannot go. The same applies while a contract is still running or a dispute is open. The usual handling is moving those items to restricted storage and deleting everything else.
4. Decide what deletion means. Either the record goes entirely, or anonymization strips it of anything that points to a person. When monthly revenue or usage figures have to survive, identifiers come out and the fields the aggregate needs stay.
5. Respond inside the deadline, commonly ten days. The response names what was deleted, what was retained, why, and for how long the retained items will be kept.
6. Push it outward. Vendors processing data on the company's behalf and any third parties that received it need their own deletion requests. Data deleted locally and still held by a processor is not deleted.

Four places where this right turns into product design.

1. The account closure flow — deletion can run the instant the button is pressed or after a grace period, commonly thirty days. A grace period rescues accidental closures, but the length and what the account can do meanwhile have to be stated on screen.
2. Logs and the analytics pipeline — events already forwarded to an external tool carry a user identifier. Each tool exposes deletion differently and some not at all, so the better decision is which values to send in the first place. Sending an irreversible hash instead of the user ID reduces how much has to be chased later.
3. Backups — yesterday's snapshot still holds the person deleted today. Rather than editing snapshots selectively, teams shorten the backup retention cycle and let rotation handle it.
4. History in collaborative products — remove one person from a document several people worked on and their name remains in the edit history and the comments. Replacing the name with an anonymous label and severing the account link is the common approach.

"Erasure request came in. Payment records are on a five-year hold, so I'll respond that those stay."

Not deleting everything, and disclosing the exception in the reply.

"If we treat account closure and an erasure request as the same operation, we'll get both wrong later."

The two requests cover different scopes.

"The analytics tool has no API for deleting an identifier. We need to stop sending it at all."

Where data cannot be deleted, not sending it is the fix.

Pagedeck built its account closure flow without designing this alongside it. Pressing the button set a closed flag on the member row and left the data in place. On the day the first erasure request arrived, Theo checked and found 1,400 closed accounts still fully present, marked and nothing more.

Grace split the two behaviors apart. Closure got a thirty-day grace period followed by automatic deletion, and an erasure request got a ten-day clock with payment records as the only exception. Writing down that the two procedures have different scopes took half a day. Building the deletion job took three.

The most common assumption is that a request obliges the company to delete everything, because that is how the word right sounds. Items a law requires to be kept, and items needed to perform a live contract, stay. Following an instruction to delete payment records would put the company in breach of a different statute. Refusing a request and disclosing an exception while deleting the rest are separate acts, and teams that miss the distinction reply that everything was deleted while quietly keeping some of it. The correct reply is dull and specific: these items are gone, this one stays until this date, here is the rule that requires it.

Treating account deactivation as deletion is the other frequent mistake. Setting a deleted flag and leaving the row in place is ordinary engineering practice, and since the record disappears from the interface it looks done. But flagged data is still queryable, still lands in backups, and still counts among the affected records in a breach. Once a user has been told their data is gone, data that is still there makes the response itself inaccurate, which is the heavier problem of the two. A flag is fine as a first step, provided a scheduled job actually removes the row afterward and somebody has checked that it runs.