Your “deleted” data isn’t deleted. It’s just inconvenient to find.

When two MIT graduate students bought 158 used hard drives off eBay and at secondhand computer shops, they recovered medical records, love letters, and over 5,000 credit card numbers. Only 12 of the drives had been properly sanitized. Blancco Technology Group ran a near-identical experiment in 2018 with 159 used drives across the U.S., U.K., Germany, and Finland — every seller insisted the drives had been “wiped.” Researchers recovered passport scans, spreadsheets full of customer data, and intimate photographs. The drives weren’t broken. They had been deleted, formatted, emptied, and reset by their previous owners. The data was still there, sitting in plain bytes, waiting for anyone willing to run a recovery tool.

This is what “delete” actually means on every consumer operating system: not erasure but de-indexing. The file’s pointer in the filesystem table is cleared, the blocks it occupied are flagged as available, and the operating system promises the user that the file is gone. The bytes themselves stay where they were until something happens to overwrite them — which may be in five minutes or five years. Everything downstream of that single design choice, from cloud version histories to courtroom forensics to the secondhand drive market, follows from this lie of convenience.

What pressing “delete” actually does

The filesystem on a typical computer — NTFS on Windows, APFS on macOS, ext4 on most Linux distributions — stores two things for every file: the file’s contents (in data blocks on the drive) and an index entry pointing to those blocks (in a table called the Master File Table, or its equivalent). When you delete a file, the system modifies the index entry — typically by marking it as free or removing it from the directory listing — and updates a bitmap that says “these blocks are now available for reuse.” The actual data blocks are untouched. As one filesystem engineer put it, Windows “removes the pointer and marks the sectors containing the file’s data as available.” Nothing is overwritten. Nothing is zeroed. The blocks are simply demoted from “in use” to “could be used.”

Until the OS happens to need those blocks for something else, the file is fully recoverable using commodity software — PhotoRec, R-Studio, Autopsy, or any of the dozens of forensic suites available for under $200. This is why every “undelete” utility exists. It is also why every digital forensics examiner’s first move on a suspect drive is to image it bit-for-bit before doing anything that might write to it.

The recycle bin and trash folders make the situation worse, not better. They are not a separate storage area — they are just a hidden directory the OS treats as a holding pen. “Emptying” the recycle bin does the same thing as deleting a file directly: clears the pointer, marks the blocks free. Nothing is destroyed. The data just becomes slightly less obvious.

Why SSDs change the math — but not the conclusion

Solid-state drives broke the old model and introduced a new one with different problems. On a traditional spinning hard disk, deleted data sits in identifiable sectors until overwritten, which makes recovery easy and reliable. On an SSD, the controller actively shuffles data around through wear leveling — a process that spreads writes evenly across flash cells to prevent any one cell from wearing out faster than the rest. This means a “deleted” file may exist in a physical block the operating system can no longer address, hidden in the controller’s translation layer.

Modern SSDs also support the TRIM command, which the operating system issues when a file is deleted to tell the drive controller: these blocks are no longer needed, feel free to erase them at your convenience. The controller then runs garbage collection in the background, reclaiming those blocks for future writes. After TRIM has run and garbage collection has completed, the data is typically unrecoverable through normal forensic acquisition.

The complication is “typically.” SSDs reserve between 7 and 28 percent of their capacity as overprovisioned space — physical storage the user cannot address directly. This region is invisible to standard forensic tools but accessible to anyone with vendor-level firmware tools or factory access mode equipment, of which firms like ElcomSoft sell commercial versions. A 2011 University of California San Diego study tested whether software-based overwriting reliably sanitized SSDs and found that even after 20 full-drive overwrites, recoverable data fragments remained in overprovisioned and wear-leveled blocks. The drive controller’s firmware was lying to the operating system about what had actually been written.

For SSDs, the only reliable sanitization is the ATA Secure Erase or NVMe Sanitize command, which instructs the drive’s firmware to reset every flash cell — including the regions the host cannot see. Standard file shredders that work fine on hard disks cannot reach overprovisioned space on an SSD and therefore cannot guarantee anything.

The cloud is worse, not better

Cloud storage replaces one deletion problem with several. When you press delete on a file in Google Drive, Dropbox, OneDrive, or iCloud, you are not deleting the file — you are moving it to a soft-delete state with a provider-specific retention window. Once that window expires, the provider’s deletion process begins, but the provider is also running version history, server-side replication, and backup retention on schedules independent of your action.

Here is what actually happens after a “delete” in the major services:

Even after retention expires, the data is not necessarily gone from the provider’s infrastructure. Geo-replicated copies, asynchronous CDN cache invalidation, backup snapshots, and audit-log entries all operate on independent schedules. AWS publishes that EBS volumes are zeroed before reallocation; most providers make similar promises about disk-level reuse. None of those promises is a sanitization certificate. If you wanted forensic-grade proof that a file is unrecoverable from a cloud provider, you would need to encrypt the file before upload and destroy the key locally — the technique known as cryptographic erasure, which NIST SP 800-88 Rev. 2 formally endorses.

What “actually deleted” looks like under NIST 800-88

NIST SP 800-88 is the federal standard for media sanitization. Its first revision was published in December 2014; Revision 2 was finalized September 26, 2025, formally superseding Rev. 1 after more than a decade. The document defines three sanitization categories that escalate in assurance:

Standard file deletion does not even meet the Clear tier. It is not on the ladder. For SSDs, Rev. 2 emphasizes that overwriting is unreliable and recommends cryptographic erase or firmware-level commands as the baseline Purge technique. For organizations, the most consequential change in Rev. 2 is procedural: it shifts the focus from individual sanitization techniques to building an organization-wide sanitization program with validation, separating “verification” (the technique ran) from “validation” (the data is actually gone) and requiring sampling and audit trails.

What this means in practice

Treat every drive you have ever owned as still containing the data you put on it. That includes the old laptop in the closet, the work device you returned, the phone you traded in, the external drive you lent to a friend, the USB stick that ended up in a junk drawer. Unless one of three things happened — the disk was overwritten enough times to defeat recovery, the firmware-level Secure Erase command was issued, or the physical drive was destroyed — the data is recoverable. Almost certainly by a professional. Often by a curious buyer with a YouTube tutorial.

The same logic applies to anything you have ever put in a cloud account. Soft-delete windows are floors, not ceilings. Enterprise retention rules, version history features, and backup vault policies can keep data alive for years past your “delete.” If you want a specific file gone from a cloud account, you have to do three things: delete it, empty the trash or “permanently delete” it, and check that your account or workspace has no retention policy or backup product retaining versions. Most users do only the first.

If you want a drive actually clean before you sell or recycle it: for an SSD, issue an ATA Secure Erase or NVMe Sanitize command through the vendor’s official utility — not a file-shredder tool. For a hard disk, a single full-drive overwrite is sufficient for Clear-tier sanitization; if you want Purge-tier assurance, use a NIST 800-88-compliant tool that verifies the wipe. For end-of-life or visibly damaged drives, the only certain answer is physical destruction. Industrial shredders are not theatrical — they are the only method NIST guarantees against future technique.

The convenient lie that “delete means gone” exists because the alternative would be slow. Genuinely erasing data is expensive in time, write cycles, and complexity. Operating systems chose the fast path, and users get a UX promise instead of a data operation. That tradeoff is fine for everyday convenience and disastrous the moment a device leaves your custody. The fix is not to distrust the delete button — it’s to understand what it actually does and reach for the right tool when “harder to find” isn’t the same as “gone.”