Crypto-shredding destroys the encryption key so every row that referenced it becomes mathematically unreadable — instantly, across every system that ever held a copy. No row scans. No missed backups. No race conditions with caches.
When a user asks for their data to be erased, the obvious answer is to find every row that references them and delete it. In practice, this fails in four predictable ways.
You can't find everything
Data pipelines copy rows into staging tables, derived tables, materialized views, and export files. A DELETE on the source table leaves copies untouched in every downstream location. You need a complete map of every destination — and that map is rarely accurate.
Backups preserve deleted rows
Warehouse snapshots and pipeline replay logs are often retained for 30–90 days. A row you deleted today still exists in last night's backup. Row deletion provides no guarantee until every backup that could contain that row has expired.
Row scans are expensive at scale
Finding a single user's rows across a 10-billion-row table requires a full scan or a complex index lookup per table. When deletion requests arrive in volume — DSAR batch, data breach response — row-delete workflows become a performance bottleneck.
You have to prove you got everything
A regulator or auditor won't accept 'we ran the DELETE query.' You need evidence that covers every system the data touched — which is exactly the thing you couldn't enumerate reliably in step one.
Instead of storing raw personal data, every field is encrypted with a per-user key before it reaches the warehouse. The encrypted bytes are meaningless without the key. When a deletion request arrives, you destroy the key — not the rows.
On write, the data pipeline calls the Key Vault to encrypt each PII field with a per-user data encryption key (DEK). The token or ciphertext is written to the warehouse. The plaintext never lands in storage.
Encrypted fields propagate through the normal transformation pipeline — staging tables, dbt models, derived marts. Every copy holds ciphertext. No copy holds plaintext. Backups inherit the same protection automatically.
On deletion request, the Key Vault destroys the DEK. The KMS key material is overwritten; there is no recovery path. Every encrypted row in every table and every backup that references this key is now cryptographically unreadable.
The Key Vault issues a signed certificate recording the key fingerprint, the destruction timestamp, and the lineage of systems that held the encrypted data. This is the evidence you produce to a regulator.
Yes. The European Data Protection Board guidance and multiple national DPA opinions accept that rendering personal data permanently inaccessible through key destruction satisfies the erasure obligation under Article 17, provided the encryption is strong (AES-256 or equivalent) and the key material is genuinely unrecoverable.
The practical requirement is evidence: you need to show when the key was destroyed, what data it protected, and that no copy of the key material remains. A signed, timestamped certificate from the Key Vault with the key fingerprint and lineage summary is exactly the evidence format auditors and DSARs require.