Why 'Provable Data Erasure' Is Really Hard, Actually

Privacat Insights

SubscribeSign in

Why 'Provable Data Erasure' Is Really Hard<br>Or why most people probably shouldn't ask me questions if they want anything other than the brutal truth.<br>Carey Lening<br>Jul 13, 2026

Share

A few days ago, a very nice, earnest developer sent me a message. He was building a tool designed to ensure ‘provable data erasure’, but had the good (or perhaps, bad) enough sense to ask me for a sanity-check first.<br>It was an interesting problem, and he was quite flattering in his email, so I decided to engage. Originally, I dashed off a few thoughts, but I quickly realized that ensuring provable erasure, like so many things in data protection, is fractally complex:

On Fractal Complexity<br>Carey Lening<br>May 18, 2023

Read full story

I’m not here to lambast the developer. The reason I’m posting here today is because I think there’s a lot of knowledge that I’ve amassed being a bitter old data protection crone that might be worth sharing with others.<br>Tl;Dr: Most organizations can’t prove that data is for reals gone, and truly unrecoverable, for a few different, intractable, and overlapping reasons.

Finding data is hard. Unless you’re starting greenfield (most orgs that actually make money are not), setting up good data quality/management practices early before bad data practices ossify is hard. That usually makes finding data hard.

Even if you’ve gone and hired a good consultancy to help you, most modern companies no longer have a central source of truth. Say you’re a medium-sized software company. You’ve got an HR department, legal, engineering, product development, IT, finance, biz dev, etc. Within each of those organizations sit various data repositories, applications, SaaS tools, people’s individual file stores, shadow IT, etc. And then there’s all the centrally-managed stuff (email, SharePoint, CRM, etc.)

Data can be copied. Once a file can be copied, even if it’s encrypted, proving deletion or un-recoverability for all copies is hard, if not actually impossible, especially if you don’t have #1 nailed down. Unless you have a new process for handling information that does not involve classical file architecture, e.g., you’re doing some sort of quantum-encryption-state magic or weird blockchain/sharding thing where there’s no ‘file’ ever created in the first place, you’re going to have a time getting around the fact that 100 versions of HR_Org_Chart-2026-05-01(1)review (1)(2).docx are floating around in people’s OneDrives, Google Docs, Slack threads, stored locally in C:/Users/Bob/Documents, etc.

Even if you do something like key-based encryption for all files, you still need to prove that you have at least destroyed every copy of the key.

If you are doing fancy magic. Good luck getting everyone to migrate away from what they already know & use to some completely new architecture. Have you met lawyers or accountants ever? And good luck getting all the SaaS and application providers to shift from their proprietary / standard file formats (some of which have been functioning for 50+ years!) to your new hotness. Gonna take time and a lot of buy-in.

“Deletion” in general is tricky. Or rather, enforced hard (versus soft) deletion is trickier than most realize. Some data, either legally or practically can’t be deleted. Try as I might, I will never get the IRS to delete my tax data. Other data exists in read-only / immutable file systems, and the only ‘deletion’ you’ve got is to nuke the entire database (or retrain the model, but I’ll get to that below).

Some systems also have the added problem of making deletion really hard. I had a client once who was using a legacy database that no one in the organization knew how to maintain. You could add files to it forever, but no one knew how to delete anything from it. I mean, I’m sure it was possible to delete files, but the guys who coded the thing had long since retired/died and left no notes, so functionally for them, it was impossible.

Non-technical people. Within each of those organizations sit people who are primarily not technical, and couldn’t tell you what a database was, or where the audit logs were, who they were sharing files with, what retention policies apply, if retention policies were enforced, or even what to look for.

While some systems may be connected and thus manageable by IT (e.g., OAuth, integrations, SDKs, MCPs), loads aren’t. They’re siloed, specialized, unknown to the technical / compliance side, and locked down for folks with a need to know, but not necessarily the technical discovery skills to answer an erasure question.

Technical people also don’t know. But even technical people frequently don’t know what files exist in the organization because the organization is huge, has no coherent data structure, and do not hire the fancy data consultancies or people that can create and maintain such a system. No one is getting paid to think about whether a file is...