Deleting data from an analytics stack is hard because the same record lives in raw tables, derived tables, snapshots, caches, extracts and model training sets. A workable approach is to define retention per dataset, keep lineage so you can find derivatives, and test deletion end to end.
Why one DELETE is not enough
Suppose you remove a customer from the main table. Their data may still sit in:
- Raw landing zones that keep every file.
- Staging and intermediate tables.
- Aggregates that include them, which may be fine, or may be small enough to identify someone.
- Time travel or backup features that keep old versions for a period.
- Notebook caches and exported spreadsheets.
- Partner extracts and BI tool caches.
- Training sets and features derived from them.
Check your platform's documentation for how long deleted data stays recoverable, and decide whether that period fits your obligations. Do not guess.
Set retention per dataset
For each dataset, write down: the purpose, how long it is needed, the deletion mechanism, and the owner. Raw logs with personal data often need a much shorter life than curated aggregates. Retention that exists only in a policy document, with no job enforcing it, is not retention.
Make deletion findable
Lineage tells you which tables derive from a source. Without it, you search by memory. See what to record for ML data lineage and how to find PII before it spreads.
Design choices that make deletion easier
- Keep personal identifiers in a small number of tables and use surrogate keys elsewhere, so deleting the mapping cuts the link.
- Partition raw data by date so old partitions drop cleanly.
- Avoid copying to desktops and shared drives.
- Give training sets an expiry and a rebuild plan.
- Prefer aggregates for long term analysis.
Be careful: a surrogate key with a surviving mapping is still personal data, as explained in our pseudonymisation guide.
Test it
Run a deletion drill. Create a synthetic person, let it flow through the pipelines, delete it using your procedure, and then search every store, including snapshots and extracts. Each remaining copy is a gap to close. Repeat after major changes.
Log what you did
Record request, scope, systems touched and completion time. Auditors ask for it, and so will you when something goes wrong. Do not keep the deleted person's data in the log.
Models
If personal data shaped a trained model, deletion questions get hard. Decide your policy with legal and privacy colleagues. This article does not give legal advice.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you retain proof that reviews and drills happened, and asset discovery can help you find the systems involved. Free scan: https://gold.safeguard.sh/scan.
Quick check
Is deleting from the main table enough?
Usually not. Derived tables, snapshots, caches, extracts and training sets may still hold the data.
How do I know deletion works?
Run a drill with a synthetic person and search every store afterwards, including snapshots.
Last reviewed: 19 October 2026.
