Decommissioning a server estate is where a data destruction policy written for laptops falls apart. Server data sanitisation involves RAID sets that spread one file across six drives, storage arrays whose disks never leave the rack until the array is retired, self-encrypting drives whose keys live in a controller, and increasingly cloud volumes where nobody in your organisation will ever touch the physical media. NIST's current revision of its media sanitisation guideline, SP 800-88 Rev 2, was rewritten with exactly these architectures in mind, and in July 2026 NIST published a FAQ that answers the storage questions directly. This guide works through them.
Key facts: server data sanitisation under NIST 800-88 Rev 2
- Revision 2 introduces the term "information storage media" (ISM) so that cloud, container and object storage are covered alongside physical drives, according to NIST's FAQ of 16 July 2026.
- Sanitising the whole device is "always preferred"; partial sanitisation of a shared drive is allowed only through cryptographic erase with "absolute confidence" the data never left the encrypted boundary (FAQ Q5).
- Cryptographic erase counts as a purge only with a validated cryptographic module, no prior plaintext, at least 128-bit strength and zeroised keys (FAQ Q9).
- For cloud storage the data owner cannot overwrite or destroy anything physical, so cryptographic erase "is often the only viable purge method" (FAQ Q13).
- Assurance is now two steps, verification by the operator and validation by the organisation, and both belong in your decommissioning record (FAQ Q7).
What does NIST 800-88 Rev 2 change for server data sanitisation?
It moves the emphasis from technique tables to a programme. NIST's FAQ says Revision 1, which NIST's publication page lists as superseded, "focused heavily on hands-on, media-specific techniques" while Revision 2 shifts to establishing an enterprise sanitisation programme, describing sanitisation assurance and "navigating modern logical storage architecture", with a decision flow based on data sensitivity and whether media is reused inside or outside the organisation.
For a server estate that is the right shape of question. The per-drive technique matters less than whether your organisation can say, for every volume that held sensitive data, which of the three methods (clear, purge or destroy) was applied, by whom, with what evidence, and who signed off that the residual risk was acceptable. Our general explainer on NIST 800-88 Rev 2 covers what changed for laptops and desktops; the rest of this guide is about the parts of the estate that do not fit in a laptop bag.
What is information storage media, and why does it matter for a SAN?
ISM is NIST's new umbrella term for anything that stores data, physical or logical. The FAQ explains that it replaces the older "electronic (soft copy) media" to account for "physical hardware devices (e.g., SSDs, magnetic tape) as well as virtual or logical storage systems (e.g., cloud, object storage) that abstract the underlying physical media".
A storage area network is the textbook case of abstraction. The LUN your database wrote to is a logical object; the bytes sit on stripes across many physical disks, with parity, snapshots, replicas and hot spares that the application never sees. Treating "the server" as the unit of sanitisation misses all of that. Under the ISM framing, the array, its spare drives, its snapshot store and any replication target are each media that held the data and each need a decision. The same applies to backup tape, which is physical ISM and is routinely forgotten when the front-end estate is decommissioned.
Can you sanitise one tenant's data on a shared drive?
Only in a narrow case. The FAQ states that sanitising the entire ISM device is "always preferred due to data spilling risks, overprovisioning, and bad-block remapping". Partial sanitisation, for example in a multi-tenant cloud environment or a shared data centre drive, is permitted only by using cryptographic erase on the keys assigned to that partition or file, and only with "absolute confidence that target data never escaped that encrypted boundary".
In practice that rules out the comfortable answer for most shared infrastructure that was not encrypted per tenant from the start. If a drive in a shared array held your data in plaintext at any point, the honest position is that the whole drive is in scope when it leaves service. That is not a reason to panic; it is a reason to record, at decommissioning, which drives are shared, which were encrypted from first use, and to route the rest to whole-device purge or destruction rather than a partial wipe.
When is cryptographic erase valid for self-encrypting drives?
When four conditions are all met. NIST's FAQ lists them: the cryptographic module is validated to the current FIPS 140 standard (a federal requirement that is a sound benchmark elsewhere); no sensitive data was ever stored on the media in plaintext before the keys were established; the algorithm has at least 128-bit security strength with matching entropy; and the target keys are permanently sanitised by zeroisation.
The second condition is the one that catches server estates. A self-encrypting drive that was installed, populated, and only later had encryption switched on does not qualify, because plaintext existed before the key. The FAQ also explains why NIST gave cryptographic erase specific treatment when it declined to prescribe techniques for other media: its "ubiquitous use for all modern SSDs, which are self-encrypting". If you intend to rely on it, the evidence that all four conditions held has to exist before the drive is pulled, not be reconstructed afterwards.
How do you sanitise storage you do not own, such as cloud volumes?
Through the keys, because that is all you can reach. The FAQ is direct: in a virtual or cloud environment "traditional physical destruction or overwrite commands are impossible for the data owner to execute", so cryptographic erase "is often the only viable purge method", and organisations "must review their cloud service agreements to ensure that keys are securely managed and that zeroization can be traceably validated".
The practical consequence for a hybrid estate is that the decommissioning plan has two halves that produce different evidence. The on-premises half produces drive serial numbers, erasure reports and certificates. The cloud half produces key management records and the provider's contractual commitments about zeroisation. Both belong in the same file, because an auditor asking "where did the customer database go?" will not accept an answer that covers only the racks you could see.
What is the difference between verification and validation?
Verification is the technician's check; validation is the organisation's decision. The FAQ defines verification as "the operational step of inspecting the immediate outcome of a sanitization technique" for errors or anomalies, and validation as "a higher-level decision-making process" in which the organisation reviews the verification data against the sensitivity of the data and formally accepts any residual risk.
This is where a disposal partner's certificate fits. On our process, drives that leave a server estate are either wiped to NIST 800-88 (Rev 2) compliant, verified erasure or destroyed by video-recorded shredding at our facility, and each drive is matched by serial number on the certificate. That certificate is verification evidence. Validation still has to happen on your side: someone with authority looks at the report against the data classification and signs. Our secure data destruction page explains the routes, and the SSD guide covers why flash media needs its own handling.
What should a server decommissioning plan include?
An inventory that follows the data rather than the hardware, a method decision per media type, and a place for both halves of the assurance record. The list below is the version we work through with customers before a data centre decommissioning project starts.
- List every ISM that held the data: array disks, hot spares, snapshot and replica targets, backup tape, boot drives and cloud volumes
- Classify the data on each by sensitivity and decide clear, purge or destroy accordingly
- Record which drives are shared or multi-tenant and treat them as whole-device scope unless encrypted per tenant from first use
- For cryptographic erase, evidence all four conditions before the drive is pulled
- For cloud volumes, obtain the provider's key zeroisation confirmation and file it with the contract clause that requires it
- Keep the erasure reports and serial-matched certificates as verification, then have an owner sign the validation decision
Book a Free Collection Call 0151 355 5482
Innovent Recycling decommissions server and storage estates for UK businesses, with free collection nationwide from Ellesmere Port, including the Midlands and computer recycling in Birmingham. Drives are wiped or shredded at our facility with serial-matched certificates; where drives must not leave your premises, on-site destruction by crushing is available and is chargeable, from £5 per drive, as set out on our secure data destruction page.
Frequently asked questions
Does a RAID array need every disk sanitised, or just the data disks?
Every disk that was ever a member, including parity disks and hot spares that were swapped in at any point. Striping spreads fragments of every file across the set, and a spare that rebuilt once holds a full copy of a member's data. Treat the set, its spares and its snapshot store as one unit of scope.
Is a factory reset of a storage array a NIST-compliant sanitisation?
Not on its own. A reset clears the configuration, not necessarily the data on each drive. NIST's programme approach asks which method, clear, purge or destroy, was applied to each ISM and what verification evidence exists. Unless the reset performs a documented cryptographic erase that meets the four conditions, the drives still need to be purged or destroyed individually.
Can we keep the array and just have the drives shredded?
Yes. Drives are removed, matched by serial number and either wiped to verified erasure for reuse or destroyed by video-recorded shredding at our facility, with the certificate listing each serial. The chassis, controllers and networking equipment are then assessed for reuse or recycled separately, and they carry no customer data once the drives and any cache modules are out.
What evidence should we keep for cloud volumes we have deleted?
The provider's confirmation that the encryption keys for those volumes were zeroised, the contract clause that obliges them to do it, and your own record of when the request was made and by whom. NIST's FAQ says key management and traceable validation of zeroisation are what the data owner must be able to show.