Organizations have a responsibility to protect data on endpoints at all times, including when they are transitioned from one employee to another, are retired, or donated to charities. Failure to protect sensitive and critical data including PII, intellectual property, trade secrets, and classified information is a violation of laws including HIPAA, GDPR, CCPA, etc. and is a risk to national security. Data loss puts IP at risk to competitors, leads to negative brand perception, costs millions of dollars per incident in fines and incident response, and in some cases can cause significant personal damage.
IT leaders know this and are diligent to take data removal seriously when a device is being repurposed or EOLed. Before endpoints and drives are transitioned, IT leaders follow industry best practices to wipe drives using ATA Security Erase, Sanitize, Format NVM, etc. or pay for managed services to perform certified drive wipes. Storage devices provide a response indicating the erase command completed successfully and, in theory, that all data was wiped successfully.
Unfortunately, research has shown that these drive erasure reports are falsely reporting the drive has wiped all the data. In 2017, NAID, the standard setting body advocating best practices in secure data destruction, commissioned a research project on 250 devices looking specifically for PII on storage found from public sites like eBay. The research showed that 44% of drives were found to have PII left on the drives. Disturbingly, the recovery process was “not sophisticated nor was advanced forensic training required. All methods leveraged downloadable shareware.” Further research by CPR Tools, leaders in advanced data discovery, destruction, and forensics, determined that 80% of Solid State Drives had recoverable sensitive (not just PII) data on them, using advanced data recovery techniques. As a result of this type of research, the NSA issued guidance requiring SSDs to be destroyed in PM9-12.
There are many reasons drives falsely report that the data was wiped. For example, in some cases the verification software doesn’t scan all of the blocks. In other cases, the commands were not implemented correctly due to multiple people working on the same code or developer attrition during software development. Other reasons include bad sectors, hardware failures, erasure program failures, and simply human error. An additional challenge, specifically with SSDs, is wear leveling and the need to have additional blocks to move data around that are often not scanned when an erasure verification command is issued.