Home / Prove tenant deletion

How to prove you deleted one tenant's data

A customer invokes their right to erasure. You run a delete. Weeks later an auditor asks: prove it — every row, every file, and prove you didn't touch anyone else. Running the DELETE was the easy part.

Under GDPR's right to erasure (Article 17), CCPA, and most data-processing agreements, "we deleted it" is not enough. You need defensible evidence of what was deleted, that the deletion was complete, and that it was contained to the one tenant. In a pooled Postgres database where every customer shares the same tables, containment is the hard guarantee.

Why deletion is harder than it looks

Completeness: the tenant's rows spread across foreign keys, join tables, and denormalized columns. A naive delete leaves orphans that still contain personal data.
Files: uploads, invoices, and exports sit in S3-compatible object storage. Deleting database rows leaves the documents behind.
Containment: cascades, triggers, and shared sequences can quietly affect other customers. You have to prove they didn't.
Evidence: a log line saying "deleted tenant 42" is not proof. You need counts, hashes, and a signature an auditor can independently verify.

A provable erasure sequence

1. Plan the deletion and count the blast radius

Before deleting anything, compute the exact set of rows and object keys the deletion will remove, per table. This blast-radius count is the "before" side of your evidence and the sanity check that the deletion matches the tenant closure — no more, no less.

2. Require approval on the exact plan

Pin the deletion plan to a hash and require a second authorized person to approve that hash. Erasure is irreversible; a four-eyes gate on the exact plan prevents an over-broad delete from ever executing.

3. Execute with containment verification

Run the deletion inside a transaction that verifies non-target tenants are unchanged. If the actual blast radius diverges from the approved plan — a cascade reaching further than expected — it rolls back instead of silently harming another customer.

4. Clean up object storage

Delete the linked object-storage keys in the same operation, tracked against the same manifest, so files don't outlive the database rows.

5. Emit signed proof

Produce a signed evidence artifact: rows deleted per table, object keys removed, confirmation that non-target tenants were unchanged, and a cryptographic signature. That artifact is what you hand the auditor or attach to the erasure request — verifiable without trusting your logs.

What "proof" actually means: not a log entry, but a signed record an auditor can verify independently — showing the deletion was complete, contained, and covered files as well as rows.

The evidence artifact

A good erasure record reads back like a receipt: signature valid, tenant rows removed, object keys removed, non-target tenants unchanged. TenantUndo generates this as a signed bundle you can verify offline. See the security posture and signed evidence model.

Rehearse the deletion path too

Erasure obligations have deadlines — usually 30 days. Discovering mid-request that your schema has ambiguous relationships, or that cascades reach shared tables, turns a routine compliance task into an incident. The same tenant graph that powers single-tenant restore powers provable erasure — map it once, use it for both.

Prove your erasure path before an auditor tests it

Send a schema and one representative tenant. TenantUndo returns the deletion blast radius, the containment risks, and a signed proof of what a real erasure would remove.

Run a recovery drill