Secure Data Erasure: A Briefing for Non-Technical Trustees

The requirement they are assessed against is a single line: evidence that data wiping is carried out securely in accordance with IEEE 2883 or NIST SP 800-88. One line, two standards, and no indication of what either of them asks for. That gap is what the note fills.

The underlying problem is the one nearly everybody gets wrong. Deleting a file does not remove it. Neither does emptying the recycle bin, formatting the drive, or reinstalling Windows. All of those mark the space as free for reuse while leaving the data exactly where it is, and free software will recover it. Reinstalling Windows over the top is one of the specific failure modes the standards exist to prevent.

Both standards use the same three levels, and picking the right one is itself a requirement. For any machine leaving the organisation's hands and going to somebody else, the level needed is the middle one.

Clear is a basic overwrite of the space the system can see, which stops everyday recovery software and nothing more. Purge uses the drive's own built-in erase commands, defeats laboratory recovery and leaves the drive usable. Destroy is physical, and is where any drive that reports a failed erase has to go, with its own written record. That exception needs to be in the policy rather than left to whoever is at the bench.

The most useful thing in the note is the part that catches people out, and it is a hardware problem rather than a paperwork one.

Overwriting a spinning hard disk reaches everything, because writing over the whole surface is exactly what it sounds like. Solid-state drives do not work that way. They shuffle data between cells constantly and hold a pool of reserve capacity the operating system cannot address, so an overwrite never touches it.

The fix is to send the drive its own built-in erase command and let the controller run it internally across the whole chip. That is the difference between Clear and Purge, and it is the single most common audit failure in this sector.

Not everything in the note is compliance, and I thought it mattered to say which was which. An assessor is checking against NIST SP 800-88r2 and IEEE 2883, and a fair amount of sensible practice sits outside both. It is still worth doing, but for different reasons. If the organisation runs short of time, the first group is the part that cannot slip.

Squarely required by the standards:

In scope but with no method given. The guidance is clear that the whole device has to be considered rather than just the obvious drive, but it stops short of saying how to handle the TPM beyond key sanitisation, the fingerprint reader's secure element, or other firmware-resident storage on the mainboard, because no general method exists.

The fingerprint reader is the one people query, so it is worth spelling out. The templates sit in permanent storage on the sensor and survive a drive wipe, and biometric data is special category under UK GDPR, so the case for covering it is strong. But IEEE 2883 is built around storage interfaces, SATA and NVMe and eMMC, and a fingerprint sensor is not a storage device on any of them. No erase command exists for it, and there is no way to read back and confirm the result. A framework built on evidence has nowhere to file that. The answer I gave was to follow the manufacturer's own instructions and record what was done.

Outside both standards entirely. None of this is data sanitisation, and I said so rather than dressing it up: removing a supervisor password, clearing the management engine and Secure Boot keys, checking for cloud enrolment, the donor declaration, the asset register, and taking the old organisation's stickers off. All worth doing, none of it required.

Erasing the drive is most of the job and not all of it. A laptop holds data in a few other places, and it can stay tied to its previous owner in ways no wiping tool can undo. Splitting the work into three is worth doing in the written policy, because it shows an assessor where the organisation's control ends.

Two explanations turned out to do the work. The TPM is a small chip that acts as a built-in safe for passwords and encryption keys: erasing the drive empties the filing cabinet but leaves the safe standing in the corner, still locked and still full. Cloud enrolment is the other one. Some business laptops are registered to their old company's IT system, and wiping the drive changes nothing, because the moment the machine reaches the internet it re-registers itself to them. It is a phone still locked to a stranger's iCloud account, and only they can release it.

Resetting the BIOS does not deal with any of this. Load setup defaults deliberately leaves the security items alone, because anything designed to stop a thief has to survive a reset too. Nor does taking the small round battery out. Modern laptops keep all of it in permanent storage.

All three tools I looked at can produce a compliant Purge and a certificate. What separates them is how much technical judgement they ask of whoever is at the bench.

I recommended Blancco or an equivalent validated product if the budget allows. The argument is not that the cheaper tools are broken. It is that they let a well-meaning volunteer do the wrong thing while everything on screen looks correct. Paying removes that failure mode, produces the certificates automatically, and gives the organisation a third party's validation to point at when it is assessed. At a few pounds per machine against the cost of a single breach, that is a reasonable insurance premium.

The fallback, if the money is not there yet, is to start on Parted Magic while volumes are low and one trained person handles every machine, then move to a validated tool as soon as the work is shared out. There is a compliance argument for paying as well: neither standard names a product, so no tool is ever mandated, but Revision 2 added an explicit expectation that you establish trust in the vendor's implementation of whatever technique you use. Independent validation is the most direct way to satisfy that, and it is a fair point to make when the cost is questioned.

The briefing is with RE(YOU)S and there is no decision yet. That one is not mine to make, and the point of writing it was that it could be made on the facts rather than guessed at. What I would want to do next is the setup: build the bench routine, write the work instruction that goes with it, and run the first machines through end to end.

I should be straight about the limits of this. I have researched and specified it, not operated it. I have not yet purged a drive to this standard, produced a certificate or been assessed against either document. It is the same gap as everywhere else on this site, and the same reason I want an apprenticeship.