“Data is a toxic asset. We need to start thinking about it as such, and treat it as we would any other source of toxicity.”Bruce Schneier · Data Is a Toxic Asset, So Why Not Throw It Out? · 2016 · Data Is a Toxic Asset, So Why Not Throw It Out? — eseu, CNN / schneier.com, martie 2016
Deleting a person is destroying their key, not rewriting history.
Schneier flips the intuition that "data is the new oil": what you do not have cannot be stolen from you, cannot be subpoenaed and does not need an explanation for why you kept it. For the warehouse this becomes a four-stage cycle. Inventory: where the personal-data columns are, marked by classification (direct identifiers, quasi-identifiers, sensitive), discovered automatically where possible. Minimisation: collect only what serves a declared purpose; a full date of birth when you need an age band is a spare column. Retention: every dataset has a deadline and a reason, and deletion is a scheduled job, not a promise. Deletion: provable, including from backups and derived data. This is also where immutability (lesson 10) makes peace with the right to erasure: crypto-shredding. Each person's data is encrypted with their own key; deleting the person means destroying the key. The rows physically remain in the immutable files and in backups, but can never be read by anyone again. A log that cannot be rewritten and a deletion that cannot be undone, at once.
A warehouse that already applies minimization and retention still has one problem: old data does not vanish on its own. So Schneier moves responsibility from policies into code. A rule written in a document can be ignored; a scheduled job that runs weekly cannot. The difference is not technical, it is evidentiary. When a regulator or a customer asks what you deleted and when, the right answer is not a promise but an execution log. Think of your fridge at home: deciding to throw out expired milk is not enough; you must actually look inside every Sunday. Likewise, demonstrable deletion turns data hygiene from an intention into a verifiable fact. The next step is seeing what happens when the columns you did keep end up in immutable files, where nothing can be physically deleted.
The previous passage ended exactly at the sticking point: immutable files and backups allow no physical deletion. This is where crypto-shredding changes what "deleted" means. Each person gets their own encryption key, and their data is written encrypted with it. The rows stay in the file, but the key is the only door. Destroy the key and the data becomes noise to everyone, forever. Deletion no longer means hunting copies across backups; it is a single act: destroying one key. It is like a safe you cannot demolish, but whose only key you can throw into a river. An immutable log and an irreversible deletion, at once. One practical question remains: what do you do when keys and data sit with different custodians?
Why it matters Every personal-data column you do not use is risk without benefit. Its cost does not show on the storage bill, but on the day of the incident.