Soft Delete vs Hard Delete for Privacy Requests

A user asks to be forgotten, and the product team's first instinct is a flag: deleted_at = now(), and the row stops showing up in the UI. That is a soft delete. It is convenient, reversible, and—for privacy purposes—largely useless. Here is the real trade-off.

What soft delete actually is

A soft delete does not remove data. It marks it so the application stops displaying it:

UPDATE users SET deleted_at = NOW() WHERE id = 42;

The row, and every column in it, is still there. It is still in your database, still in your backups, still queryable by anyone with SQL access. You have hidden it from the product, not removed it from the world.

Why soft delete is so popular

The reasons are practical and legitimate:

• Undo. A mis-clicked deletion can be reversed by clearing the flag.
• Audit. Deleted rows stay available for investigation or debugging.
• Analytics. Historical data is still counted, even if the user left.
• Cost of delete. Real deletion means touching every table, and engineers know how long that takes.

None of those reasons are about the user. They are about the product's convenience.

Why it fails a privacy request

A privacy request is not "stop showing this in the UI." It is "my data should not be processed by you anymore." A soft-deleted row is still processed data:

• It still appears in a database dump, export, or breach notification.
• It can resurface if a query forgets the deleted_at filter, and one always does.
• An auditor who finds the row sees that the "deletion" was cosmetic.
• A restore from backup brings it back, flag and all.

The classic failure mode: the company claims "deleted," the user's data leaks or gets exported, and the flag is exactly the evidence that the deletion never happened.

When soft delete is the right call

Soft delete is a product pattern, and it has a legitimate home—for data you are allowed to keep. Holding a row for an undo window, or for a defined retention period where you have a lawful basis, is fine as long as it is a policy decision, not an accident. The problem is treating soft delete as the answer to a deletion request, which it is not.

If you soft-delete as part of a request, you need a second, hard step on a schedule: after the retention window expires, actually remove the row and its copies. The flag is a staging area, not a final state.

The middle path: anonymization

Between keep and delete sits anonymization: replace identifying fields so the row no longer points at a person.

UPDATE users
SET email = 'deleted@example.in',
    name = NULL
WHERE id = 42;

This preserves aggregate value while cutting the link to the individual. It is a real option, but only if the anonymization is thorough—an email left in a comment column or a phone number in a log defeats it. And it is still not "deletion" in the strict sense, so check what your policy and the law actually require before you rely on it.

What evidence of deletion looks like

Whichever path you choose, you should be able to show what you did: the request, the verification, the tables and systems acted on, and the outcome. If your policy says "deleted," the record should show rows removed, not flagged. This is the difference between an operational record and a claim.

Erasure's Rights product runs hard deletes against mapped systems and records the outcome honestly—completed, failed, or partial—with exportable evidence. It does not ship an anonymize action yet, so if anonymization is your requirement, that is a decision you make in your own data layer. The deletion requests guide covers the full workflow, and the data deletion hub collects the related material.