Is deleting the account row enough?

No. The account row is usually just the entry point. User data is copied into serving tables, files, logs, analytics, billing, support tools and derived datasets. A correct deletion process enumerates those locations and applies the right action for each, instead of assuming one database delete covers the product.

What is the difference between export and deletion?

Export is about collecting personal data into a readable package, often with explanations of what each record means. Deletion is about reducing or removing the ability to associate data with the user. They use a similar data map, but deletion has more store-specific choices: remove, anonymise, unlink, tombstone or wait for retention.

Can backups be deleted per user?

Usually it depends on the backup design. Many backups are not practical to edit for one person without weakening recovery guarantees. A common pattern is to protect them with strict access controls, expire them on a defined schedule, and ensure that if data is restored, the deletion request is replayed before the system serves it again.

Why is anonymisation sometimes used instead of deletion?

Some records must remain useful for accounting, abuse prevention, security investigation or aggregate reporting, but no longer need to identify the person. In those cases, deleting the identifier or replacing it with an irreversible value can preserve operational value while reducing privacy risk. Whether that is acceptable depends on the data, law and product context.

Privacy, Data Export & Deletion

Privacy, data export and deletion is the engineering discipline of finding, packaging, removing, anonymising or retaining all personal data connected to a user across a product’s systems. It treats the user record as only the starting point, then follows copies, derived data, logs, processors, caches and backups.

The hard part is that production systems deliberately spread user data around. A profile table may be obvious, but the same person can appear in object storage, support tickets, billing events, search indexes, fraud signals, telemetry, message queues and warehouse tables. Export and deletion requests become unsafe when teams answer from the schema they know best rather than from a complete map of where identifiers, content and derived facts actually travel.

A workable approach models user data as a graph. The account is the root, and edges point to orders, posts, sessions, devices, email events, audit records, feature data, file paths and third-party systems. Export walks that graph and assembles readable data with enough context for the requester to understand it. Deletion walks much of the same graph, but applies store-specific actions such as delete, unlink, redact, anonymise, tombstone or enqueue for later removal.

The trade-off is that not every copy can or should be handled the same way. Live serving data may be removed quickly, while derived tables need rebuilds, caches expire, analytics may need anonymisation, and queues require asynchronous processing. Backups and immutable logs are commonly misunderstood: they may be inaccessible to per-user deletion until normal expiry, so the honest design relies on retention limits, access control and restore-time deletion procedures.

Engineers meet this in privacy centres, data subject access request tooling, account closure flows, retention jobs and compliance reviews. The practical question is not simply whether the users table has a delete path. It is which systems are in scope, which processors must be called, what evidence is recorded, what remains for legal or operational reasons, and how restored or reprocessed data avoids resurrecting a deleted user.

Go deeper

User SystemsPrivacy, Data Export & DeletionEnumerate everywhere one user's data lives - primary tables, derived tables, caches, logs, analytics, backups - and say which of those a deletion request can and cannot reach.Open the lesson

Common questions

Is deleting the account row enough?: No. The account row is usually just the entry point. User data is copied into serving tables, files, logs, analytics, billing, support tools and derived datasets. A correct deletion process enumerates those locations and applies the right action for each, instead of assuming one database delete covers the product.
What is the difference between export and deletion?: Export is about collecting personal data into a readable package, often with explanations of what each record means. Deletion is about reducing or removing the ability to associate data with the user. They use a similar data map, but deletion has more store-specific choices: remove, anonymise, unlink, tombstone or wait for retention.
Can backups be deleted per user?: Usually it depends on the backup design. Many backups are not practical to edit for one person without weakening recovery guarantees. A common pattern is to protect them with strict access controls, expire them on a defined schedule, and ensure that if data is restored, the deletion request is replayed before the system serves it again.
Why is anonymisation sometimes used instead of deletion?: Some records must remain useful for accounting, abuse prevention, security investigation or aggregate reporting, but no longer need to identify the person. In those cases, deleting the identifier or replacing it with an irreversible value can preserve operational value while reducing privacy risk. Whether that is acceptable depends on the data, law and product context.

Every term