NIST SP 800-88 Rev. 2: A Defensible Media Sanitization Process

Short answer

A defensible sanitization process connects four things: the data that must become inaccessible, a method appropriate to the actual medium, evidence that the operation completed, and an explicit decision accepting or rejecting the result. A successful tool message supplies only part of that chain.

NIST SP 800-88 Rev. 2, published in September 2025, supersedes the 2014 revision. Use it as program guidance, then select a technology-specific technique from an applicable approved standard and the exact device documentation. Do not treat a menu label such as “NIST wipe” as proof that the required process occurred.

Who this is for

This workflow is for an authorized organization preparing storage for internal reuse, external transfer, or disposition. It is a process design guide, not a universal erase command or a claim that a particular drive has been sanitized. Actual commands depend on protocol, model, firmware, connection path, and policy.

Keep retention obligations and legal holds ahead of destructive work. Identify the person who can authorize disposal of the data and the person who can approve the result. They may be different people. Stop intake if ownership, asset identity, or the required retention decision is unresolved.

What changed in the practical reading of Revision 2?

The current revision emphasizes a managed sanitization program. Its operational value is the connection between method selection, execution evidence, and acceptance. It retains clear, purge, and destroy as distinct sanitization methods; they are not interchangeable names for increasing overwrite pass counts.

For technology-specific techniques, consult the referenced IEEE 2883 series or another organizationally accepted standard. Read the applicable requirements before claiming conformance. This guide does not reproduce IEEE requirements or infer them from NIST's references.

One particularly useful distinction is verification versus validation. Verification inspects the operation's outcome. Validation decides whether that outcome is adequate for the target data and its confidentiality requirements. A technically successful operation can still be unsuitable for the medium or incomplete in scope.

Step 1: Define the target before choosing the method

Create an intake record that answers these questions:

1. Which physical item is involved? Capture manufacturer, model, serial number, asset ID, firmware, reported capacity, and connection path.
2. Which data is in scope? Include relevant namespaces, partitions, controller storage, encryption keys, and separate copies that belong to the disposal request.
3. Where will the medium go? Record internal reuse, external transfer, return to a supplier, recycling, or destruction.
4. What policy applies? Name its version, confidentiality category, accepted method, and approving role.

The following is an illustrative record layout, not a completed certificate or a mandatory NIST schema:

asset_id: REQUIRED
manufacturer_model_serial: REQUIRED
firmware_and_connection: REQUIRED
target_data_and_storage_scope: REQUIRED
destination_and_authorization: REQUIRED
policy_version_and_required_method: REQUIRED
approved_technique_and_tool_version: REQUIRED
execution_evidence_and_exceptions: REQUIRED
verification_outcome: PENDING
validation_decision_and_approver: PENDING

Avoid using an operating system device name as the only identity. A name such as a numbered disk can change after reconnecting. An enclosure may expose only a virtual disk while hiding physical members. Resolve that mapping before authorizing an operation.

Step 2: Document why the technique fits the medium

Build a short method-selection record rather than choosing a familiar pass count. State the approved method, the exact technique, the supporting device documentation, and any storage regions whose coverage depends on the controller implementation.

Intake finding	Question to resolve before execution
Rotating HDD	Does the selected operation cover the required data and any inaccessible regions?
SSD or flash device	What happens to remapped and overprovisioned storage under this operation?
Encrypted storage	Was all target data encrypted appropriately, and which key copies must be sanitized?
Array or external enclosure	Does the command reach the intended physical media or only a logical presentation?
Damaged or intermittently accessible device	Can completion and coverage be established, or is another approved disposition needed?

These are decision prompts, not declarations that a method is acceptable for every device in a row. A host overwrite's address coverage and a controller sanitize operation's scope require different evidence. Neither can be substituted for the other merely by renaming a report.

For cryptographic erase, trace the relevant key hierarchy and copies. “Encryption enabled now” does not establish how the target data was stored earlier. Resolve those facts before accepting key removal as the chosen technique.

Workflow

Use the approved tool and procedure for the identified device. Preserve its version, selected options, start and finish times with timezone, reported completion state, errors, and any device-specific status evidence. Do not retain secrets or customer data unnecessarily in the report.

If power or connectivity is lost, mark the operation interrupted until the procedure establishes its actual state. Do not convert a missing result into success. If a bridge hides required status, move to an approved connection path or quarantine the asset for review.

Keep the working record beside the asset throughout the process. A complete report attached to the wrong serial number is not evidence for the drive leaving the bench.

Step 4: Verify execution, then validate the decision

Verification should establish what actually completed and identify errors, anomalies, or health issues. Validation then asks whether those results satisfy the selected policy and the target-data scope. Record a reasoned accept or reject decision.

Revision 2 does not make elaborate full or representative content sampling a universal requirement after clear or purge; organizational policy can require it. If your policy does, define the sample population and acceptance rule before execution. The companion guide on HDD overwrite sampling explains the limits of that evidence.

Use three separate questions in review: Did the intended operation finish? Was that operation appropriate? Is its coverage sufficient for this disposal decision? A green completion indicator answers neither of the last two by itself.

Verification note: acceptance criteria for this workflow

This article reports a document-based workflow, not a bench test or a sanitized device. Before marking an asset accepted, check that its identity matches the report, the selected technique has documented applicability, required status evidence is present, exceptions have been resolved, and an authorized reviewer has recorded the validation decision.

Reject or quarantine records with conflicting serial numbers, unexplained capacity changes, incomplete completion status, unsupported coverage claims, or an unresolved key-copy question. An operator can correct documentation errors, but cannot turn an evidence gap into proof by issuing a certificate.

Resale and evidence checklist

Keep an asset-level record of the chosen method and technique, tool version, verification evidence, validation decision, responsible people, dates, exceptions, and destination. Track custody through the handoff so the record remains connected to the physical item.

For an example of organizing related evidence without confusing a configuration reset with complete data sanitization, see sanitization evidence for network assets. Apply the same discipline here: state exactly what was covered, what was checked, and what remains outside the claim.

When to use this

Use this process when writing a storage disposition policy, reviewing a sanitization tool's evidence, or handing an authorized asset to another custodian. It applies to the decision and record, while the medium-specific procedure supplies the actual operation.

When not to use this

Do not use the example record as an erase command, a certificate of completed work, or a substitute for an applicable contract or retention decision. Do not release an asset whose required sanitization cannot be established.

Verification checklist

• Match the physical asset, reported identity and evidence record.
• Confirm the selected method and exact technique are approved for the scope.
• Preserve completion status, anomalies and unresolved limitations.
• Record an authorized validation decision before disposition.

What not to publish

Keep customer data, recovery keys, credentials and sensitive asset identifiers in the approved internal evidence system. Public examples should describe the evidence structure without exposing the material being removed.

Common mistakes

Avoid treating a factory-default screen as a complete storage inventory, equating more passes with a different sanitization method, or accepting a certificate detached from its underlying result. A clean-looking filesystem cannot settle hidden-area or key-lifecycle questions.

CliDeck workflow fit

This guide describes an evidence process that can accompany a documented asset workflow. It does not establish that any CliDeck product implements a particular disk erase command, supports a drive model, or holds a sanitization certification. Verify product capabilities separately from this process guidance.

FAQ

Does Revision 2 make my wipe report a certification?

No. Identify the actual requirements and retain the evidence and acceptance decision. A report title cannot establish conformance.

Must every asset use the same technique?

No. Media technology, confidentiality requirements, device support and destination affect the decision. Document the approved choice for the actual scope.

Related guides

Use the sampling calculation guide when your policy calls for an additional logical read sample. Its probability model does not replace method selection or validation.

Safety note: This guidance applies only to devices your team owns or is authorized to process. Use the approved, device-specific procedure, customer policy, and your organization’s sanitization and evidence procedures.