Delete has always been a lie

Somewhere in your company, someone has told a client that their file was deleted.

They probably believed it. They dragged the file to the bin, emptied the bin, and watched it disappear. The screen agreed with them. The folder was empty. The promise felt honest.

It was not a lie in the moral sense. It was a lie in the technical sense, which is worse, because nobody involved knew.

1. What the delete button actually does

Deleting a file does not remove the file. It removes the pointer to the file.

A filesystem keeps two things: a directory of where everything lives, and the blocks of data themselves. When you delete, the operating system crosses the entry out of the directory and marks those blocks as available for reuse. The bytes are untouched. They sit exactly where they were, fully intact, until something else happens to be written over them.

That could be in ten seconds. It could be in ten months. On a drive with plenty of free space, it could be never. In the meantime, any recovery tool that reads blocks directly rather than asking the directory will read your file back in full. This is not hacking. It is a category of software you can download in a minute, and it exists precisely because this behaviour is the norm on every mainstream operating system.

The Recycle Bin makes it worse by adding a step that feels like finality. Emptying the bin does not overwrite anything. It is the same crossing out, performed twice.

2. Solid state drives did not fix this, they complicated it

The intuitive fix is to overwrite the file. On a traditional spinning disk, that worked, and a single pass is enough. The 35 pass rituals people still quote were designed for drive encodings that have not shipped in decades.

Solid state drives broke the assumption underneath. An SSD controller does not let the operating system write to a specific physical location. It spreads writes across the chips to stop any one cell wearing out, a technique called wear levelling, and it keeps a reserve of spare capacity the operating system cannot see at all. When you overwrite a file, the controller usually writes the new data to a fresh location and marks the old one for later cleanup. The original bytes are still on the chips, in a place your software cannot address in order to destroy them.

TRIM helps. It tells the drive which blocks are no longer in use so it can erase them during idle time. But TRIM is a hint, its timing is the controller's decision, it behaves differently across manufacturers, and it is frequently disabled or unsupported inside RAID arrays and virtual machines. Treating it as a guarantee of destruction is a guess wearing a technical vocabulary.

3. The copies you were never counting

Even a genuinely perfect deletion on one machine only solves one machine.

Last night's backup ran before you deleted anything, and it holds a complete copy. Your cloud storage kept version history, which is a feature you pay for specifically so that deletion is reversible. The file synced to a laptop, a phone and a tablet. Modern filesystems and virtual machine platforms take snapshots, and a snapshot exists to preserve the state of things before you changed them. Storage replicates across regions for durability, so the same object may be sitting in three data centres in two countries.

And then there is the copy you have no authority over at all. You emailed the document to someone in March. That copy is on their disk, in their backup, on their provider's servers, and in the forward they sent to a colleague you have never met.

Every one of those is a full, readable copy of a file you believe you destroyed.

4. This is a compliance problem, not just a technical one

Under Article 17 of the GDPR, a person can require you to erase their personal data, and you have to do it. Saudi Arabia's Personal Data Protection Law carries comparable obligations. Contracts routinely require destruction of confidential material at the end of an engagement. Retention policies exist in nearly every regulated business and specify that certain records must be gone by a certain date.

All of these ask for the same thing: destruction, evidenced.

Almost nobody can evidence it. The standard artifact is a certificate that says the deletion command was issued. That is a record of an instruction, not proof of an outcome. It tells an auditor what you asked the system to do. It does not tell them what the system did, and it says nothing whatsoever about the fourteen other copies.

The honest version of most destruction certificates would read: we ran delete on the copy we knew about, and we are assuming the rest.

5. What the standards actually recommend

This is well understood by the people who write the standards. NIST Special Publication 800-88 Revision 1, the United States guideline on media sanitization, separates sanitization into Clear, Purge and Destroy, and is explicit that the method has to match the media. It also recognises a technique that sidesteps the whole problem.

That technique is cryptographic erase.

If data was encrypted before it was ever written, then the data on the disk is already meaningless without its key. You do not need to reach the bytes. You do not need to defeat wear levelling, or chase snapshots, or phone the person you emailed in March. You destroy the key, and every copy of that data, everywhere it exists, in every backup and every region and every inbox, becomes noise at the same instant.

The bytes remain. They stop being a file.

This is why full disk encryption products can wipe a device in a second rather than an hour, and why cloud providers offer customer managed keys. The principle is proven and it is boring. What is not common is applying it at the level of individual files, for individual people, in a form where the key was never held by anyone but you.

6. The three questions worth asking

If a vendor, or your own IT team, tells you data was destroyed, three questions separate a real answer from a comfortable one.

6.1 Was it encrypted before it was first written, or afterwards. If afterwards, there was a window where a readable copy existed, and copies made in that window are still readable.

6.2 Who holds the key. If the answer is the vendor, then destruction is a policy they are choosing to honour, not a fact. Policies change, companies get acquired, and courts issue orders.

6.3 What is the proof. Not a log line saying delete was called. Something independently verifiable, that shows destruction occurred, without revealing what was destroyed.

If those three have good answers, the data is gone. If they do not, you are trusting a screen that showed you an empty folder.

7. Where we are

We are not going to claim we have solved this. It is a hard problem and anyone who tells you they have finished it is selling something.

What we will say is that at Silent Key we have been working on it for a long time, we have built on the approach above rather than on chasing bytes around a disk, and we believe we are getting there.

Delete was never the promise it looked like. That is worth knowing before you make it to someone else.

---

Sources

NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization: https://csrc.nist.gov/pubs/sp/800/88/r1/final
GDPR Article 17, Right to erasure: https://gdpr-info.eu/art-17-gdpr/
Saudi Personal Data Protection Law, SDAIA: https://sdaia.gov.sa/en/SDAIA/about/Documents/Personal%20Data%20English%20V2-23April2023-%20Reviewed-.pdf