The Laptop Left the Building. Your Data Didn't.
Here's a scenario I've watched play out more times than I care to admit: a company refreshes its fleet, ships 200 laptops off to an ITAD vendor — or worse, an e-waste drop-off — and nobody in security was ever in that conversation. The asset tag gets removed from the CMDB. The ticket closes. Six months later someone recovers an intact copy of your customer PII from a machine that got resold on eBay.
This isn't a hypothetical edge case. It's the Morgan Stanley situation, except most companies don't have $60 million sitting around to absorb the regulatory fallout. In 2022, the SEC fined Morgan Stanley $35 million — part of a broader $60M+ settlement — specifically because decommissioned equipment with unencrypted customer data ended up in the hands of a data center decommissioning firm that then sold the devices at auction. Unwiped. To the public. The underlying failure wasn't technical sophistication. It was a total collapse in asset decommissioning process and chain of custody.
And the frustrating part? The technical controls to prevent this are not exotic. They're documented. NIST SP 800-88 Rev 1 has been around since 2014. The problem is execution, accountability, and the fact that most organizations treat media sanitization as an afterthought that happens somewhere between "IT closet" and "recycling bin."
NIST 800-88 Isn't Optional Reading
NIST SP 800-88 Rev 1, Guidelines for Media Sanitization, gives you three categories: Clear, Purge, and Destroy. The distinctions matter enormously in practice, and conflating them is how you end up in a breach notification.
Clear is the lowest bar — overwriting logical storage to protect against simple recovery using standard read functions. Think a basic format or a single-pass overwrite. This is appropriate when media is being reused within the same security domain. Not for disposal. Not ever for disposal.
Purge is the standard you should actually care about for disposal. It applies techniques that protect against laboratory attacks — meaning a well-resourced adversary with forensic hardware. For HDDs, this means ATA Secure Erase or cryptographic erase where applicable. For SSDs and NVMe drives, the picture gets more complicated. For classified materials or particularly sensitive data, you go to Destroy — physical shredding, incineration, or disintegration to the point where recovery is computationally infeasible regardless of what resources you throw at it.
The mistake I see constantly is organizations treating a Windows format or a DBAN run as a "Purge-level" event. It's not. DBAN — Darik's Boot and Nuke — was a fine tool for spinning rust in 2008. It does not work correctly on SSDs. It does not work on NVMe drives at all without additional configuration. It has no idea about hidden areas like DCO (Device Configuration Overlay) or HPA (Host Protected Area). If you're still mandating DBAN as your standard decommissioning process and your fleet is even partially SSD, you have a gap.
SSDs Are Not Hard Drives. Stop Treating Them Like Hard Drives.
This is where I lose patience with people who copy-paste HDD sanitization runbooks onto mixed or SSD-dominant fleets without thinking about it.
TRIM on an SSD tells the controller which blocks are no longer in use so it can erase them in the background. This is an optimization for write performance — it is not a sanitization mechanism. The timing, completeness, and reliability of TRIM-based erasure is entirely controller-dependent. Some controllers batch it aggressively. Some defer it. Some skip it under load. You cannot audit TRIM completion. You cannot rely on it for sanitization.
What you actually want for SATA SSDs is hdparm --security-erase or hdparm --security-erase-enhanced. The "enhanced" variant is supposed to zero out all user data areas including reallocated sectors. Whether a given drive's firmware implements this faithfully varies by vendor and firmware version. Some drives fake ATA Secure Erase completion without actually doing the work — Samsung had well-documented issues with this on certain 840 EVO firmware versions. So you run it, it reports success, and you have no actual assurance. Lovely.
For NVMe, you're using the nvme format command from nvme-cli. Specifically, you want nvme format /dev/nvme0 --ses=1 for a user data erase, or --ses=2 for cryptographic erase if the drive supports it. The --ses flag is the Secure Erase Settings field in the Format NVM command. Again — firmware compliance matters. The NVMe spec says what should happen. The firmware on a cheap OEM drive does what it feels like.
And then there's wear leveling, which is the real nightmare. SSDs write data to different physical cells to distribute wear evenly. This means a "deleted" file may have copies sitting in cells that the logical address space no longer points to. Overwriting the logical address space does not overwrite those cells. The only reliable way to handle this is either cryptographic erase (if the drive supports it properly) or physical destruction.
Crypto-Erase Is Actually Good — When You Set It Up Beforehand
BitLocker and FileVault — when properly deployed with full-disk encryption from day one — give you a genuinely strong sanitization path: destroy the key, the data is cryptographically inaccessible. NIST 800-88 explicitly recognizes cryptographic erase as a Purge-level technique, provided the encryption was implemented correctly and the key is truly gone.
The operative phrase is from day one. If you encrypt the drive after the data is already written, unencrypted remnants may exist in unallocated space, bad sectors the OS can't see, or those wear-leveled cells I just described. Encrypt first, write data second — that's the only sequence that gives you a clean crypto-erase story.
For BitLocker deployments, you want to make sure the recovery key is stored in Active Directory or Azure AD and then — critically — that you can demonstrate key destruction when decommissioning. Just disabling BitLocker on the device is not key destruction. Wiping the TPM and ensuring recovery keys are removed from AD/Azure AD is key destruction. Document it. You'll need to prove it.
I've seen ITAD vendor contracts that claim "crypto-erase" as their sanitization method without any documentation of whether the devices were encrypted before they received them. That's not crypto-erase. That's a liability transfer exercise dressed up in technical language.
Degaussing: Fine for HDDs, Useless for SSDs
If you work in a government-adjacent or classified environment, you're familiar with degaussers. A properly rated NSA/CSS EPL-listed degausser will reliably destroy data on magnetic media by applying a strong magnetic field that randomizes the magnetic domains. It works. For HDDs. Full stop.
Degaussing does nothing to an SSD. Flash memory stores data as electrical charge in floating-gate transistors. There's no magnetic domain to randomize. You can run an SSD through a degausser and pull it out with every bit intact. I want to be unambiguous here because I've encountered organizations — including one large healthcare provider I consulted with — that were degaussing mixed media batches and signing off the SSDs as sanitized. Their auditor had no idea. The ITAD vendor didn't flag it. Nobody caught it until a tabletop exercise surfaced the process.
For SSDs requiring destroy-level treatment, you're looking at physical shredding — particle size matters, NSA/CSS EPL specifies 2mm x 2mm for flash media at the Top Secret level. Commercial shredders that advertise "SSD capable" vary wildly in their actual particle output. Verify the equipment spec before you sign the contract.
Your ITAD Vendor Is a Trust Boundary You're Not Treating Like One
The ITAD (IT Asset Disposition) industry is largely unregulated. Anyone can incorporate a company called "SecureDestruct Solutions LLC," print a certificate of destruction template off the internet, and start bidding on enterprise decommissioning contracts. The downstream handling of your hardware after it leaves your dock is almost entirely opaque unless you've specifically contractually required audit rights, third-party certification (R2/RIOS, e-Stewards), and serial-number-level certificates of destruction.
Morgan Stanley's ITAD vendor subcontracted work. The subcontractor sold the equipment. This is not a rare supply chain failure pattern — it's endemic to the industry. Resale value is high on enterprise SSD arrays, NVMe drives, and modern laptops. The financial incentive to not destroy and to resell instead is significant. Your certificate of destruction may have been generated by someone who never touched the physical hardware.
Chain of custody documentation needs to be treated with the same rigor as evidence handling. That means: manifest generated at pickup with serial numbers and asset tags, manifest reconciled against your CMDB before the vendor leaves your facility, signed transfer of custody, and a certificate of destruction that maps back to individual serial numbers — not just batch counts. If your vendor is handing you a document that says "We destroyed 47 hard drives" without a serial number list, that document is meaningless.
And on-site destruction? Always worth the premium for sensitive data. Watching a shredder take apart your storage media in your own parking lot eliminates the subcontracting problem entirely.
Enterprise SAN/NAS: The Problem Nobody Talks About
Everyone fixates on endpoints. Laptops, workstations, phones. But the decommissioning risk surface for enterprise storage arrays is genuinely massive and under-discussed.
A mid-size EMC VNX or NetApp FAS array will have dozens of hot-spare drives, failed drives in a "broken" state that the array flagged and stopped using but never zeroed, and potentially years of customer data across RAID sets that are not trivially addressable with any of the drive-level tools we've discussed. The array firmware manages the physical location of data. You can't just run nvme format on individual drives pulled from an active array and call it sanitized — the mapping between logical blocks and physical media across a RAID-6 set with hot spares and a dedup layer is genuinely complex, and naive overwrite approaches leave islands of data intact.
For SAN/NAS decommissioning, you're looking at either array-level secure wipe operations (most enterprise vendors provide these — NetApp has disk sanitize, EMC/Dell has sanitization workflows in Unisphere), or physical destruction of every drive in the chassis. Pulling drives from a partially-failed array and degaussing the "active" ones while assuming the hot spares are clean is exactly the kind of partial-measure thinking that ends in a breach.
Data remanence on enterprise storage is a real problem. Snapshots, clones, deduplicated blocks, tiered storage that moved data to a slower tier and left a reference — all of these create additional data copies whose locations are not obvious. An organization's storage team needs to be in the room for decommissioning conversations, not just IT procurement.
What a Defensible Program Actually Looks Like
Not a checklist. A few things that separate organizations who have this under control from those who don't:
- Encryption-by-default at provisioning. Every endpoint, full disk, key escrowed with documented destruction procedure. This is your backstop for every other failure mode downstream.
- Serial-number-level tracking from CMDB to CoD. If you can't reconcile decommissioned media back to individual asset records with individual destruction certificates, you don't have a program — you have a hope.
- Sanitization validation, not just execution. For drives being redeployed internally, run
hdparm -Iornvme id-ctrlto verify secure erase completion status. For drives being destroyed, require the vendor to shred in front of you or provide tamper-evident packaging with CCTV documentation.
The regulatory pressure here is intensifying. GDPR Article 5 requires data minimization and storage limitation — meaning you're not just responsible for how data is used, but for ensuring it's actually gone when retention periods expire. The FTC has been increasingly aggressive on disposal practices. And HIPAA's Security Rule has explicit requirements for media disposal under the Physical Safeguards standard. The Morgan Stanley fine was the SEC, but the legal theory — negligent disposal of customer data — applies across industries.
That decommissioned laptop with your customer database on it isn't a hypothetical. Right now, in some ITAD warehouse somewhere, there's a drive from someone's fleet that went through a process nobody really verified, that might get wiped properly and might get resold to a parts broker who sells it to someone who knows how to run testdisk. The only variable is whether it's your drive.
