One Year After NIST SP 800-88 Rev. 2: A Wipe Result Is Not a Sanitization Record

A wipe certificate usually shows that a tool reported success. That is useful, but it answers only one of the questions an auditor, customer or downstream buyer can ask. Which drive was it? Was that the right method for that drive and that data? Who checked the result, and who accepted it? What happened to the drive afterwards?

NIST published SP 800-88 Rev. 2 in September 2025. One year on, the clearest change for ITAD is not a new erase command. It is that the guideline now treats sanitization as a program with records, and it separates checking a result from accepting it. This article covers what the final text actually says, where R2v3 differs, and what a sanitization record needs to hold to survive scrutiny months later.

---

1. What changed in Rev. 2

NIST's publication page lists Rev. 2 as published September 2025, superseding Rev. 1 from December 17, 2014. In July 2026 NIST added a Frequently Asked Questions document (dated July 16, 2026), which is the clearest summary of the change. It says Revision 1 "focused heavily on hands-on, media-specific techniques" presented in tables, while Revision 2 focuses on:

• establishing an agency or enterprise media sanitization program;
• describing sanitization assurance;
• navigating modern logical storage architecture;
• the three methods (clear, purge, destroy) in more detail;
• a new term, information storage media (ISM), that covers cloud and object storage as well as physical drives;
• a decision flow based on data sensitivity and whether media will be reused inside or outside the organization.

Two points from the same FAQ matter directly to ITAD operators:

• Rev. 2 doesn't prescribe techniques per media type. For that it points to industry standards such as IEEE 2883 and, for highly sensitive government media, NSA policy manuals.
• Multi-pass overwriting is unnecessary. NIST says legacy multi-pass patterns "achieve very little confidentiality protection" on modern storage and can shorten flash media life. We covered the SSD side of this in NIST 800-88 vs DoD 5220.22-M.

2. The program now includes the records

Section 4 of Rev. 2 frames sanitization as part of data governance. Drawing on ISO/IEC 27040, it lists what the program should include, ending with "identifying the necessary records or evidence (i.e., documentation) to meet compliance obligations." Section 4.1 says the policy should cover, among other things, documentation and evidence requirements and specific validation and verification protocols.

Section 4.3 adds a step many facilities skip: once a sanitization decision is made, the organization "should record the decision." The method choice is itself part of the record, not only the command that ran.

3. Verification and validation are two different steps

This is the most practical change in Rev. 2. The FAQ describes sanitization assurance as two phases:

On verification depth, Section 4.5.1 is explicit: "Unless explicitly required by organizational policy, elaborate sampling of an ISM's contents (e.g., full or representative) after clear or purge sanitization techniques is not necessary." How much read-back you do is a policy decision, not a NIST requirement. A contract or certification scheme can still require it (R2v3 does, see section 5).

Validation is where a technically successful run can still be rejected. Section 4.5.2 gives examples of a sanitization that completes but isn't effective:

• part of the media is no longer reachable through its interface because of errors, even though it appears to work;
• the method doesn't fit the media. NIST's example: degaussing an SSD "can complete successfully, but no sensitive data is sanitized";
• the work was done by unqualified personnel, or with tools that weren't approved or calibrated;
• the outcome misses the organization's minimum requirement, such as shred particles larger than policy allows;
• the scope was too narrow, such as a clear overwrite on a drive with overprovisioning that leaves user data untouched.

If the result isn't acceptable, NIST says sanitization is repeated, and that the repeat "should recheck the reusability of media," because the first attempt may have made it unusable.

Why this matters for records: a single "PASS" field can hold a verification result. It can't hold a validation decision, the person who made it, or a rejection followed by a second attempt. Those need their own fields.

4. What NIST says a certificate should contain

Section 4.6 says a certificate of sanitization "should be completed for each ISM that has been sanitized," per the organization's policies, and that it may be paper or an electronic record. NIST even describes scanning drive barcodes into a tracking application as the drive is sanitized. When complete, the certificate should record at least:

Two consequences follow. The certificate is per storage device, so a laptop with two drives needs two. And the tool's name and version are listed as one field among many: NIST treats the tool as something to record, not as the thing that makes a record trustworthy.

5. R2v3 is a separate rulebook

R2v3 and SP 800-88 are often mentioned together. They are not interchangeable.

SERI's Specialty Process Requirements page says R2v3 "no longer relies on external data security standards like NAID, ADISA, or NIST 800-88" and that the R2 Standard "now internally controls data sanitization requirements." It describes Appendix B as requiring "more robust security controls and enhanced traceability and record keeping," records created by data wiping software "for proof of sanitization for each device," and removal of cloud connections such as Find My so data can't be repopulated. (We covered part-level Activation Lock in our Apple parts article.)

A few R2v3 points that go beyond Rev. 2, as SERI describes them:

• Software records, not spreadsheets. SERI's Formal Interpretation #1.0 (effective November 29, 2022) defines "software" as applications that "automate, control, and record results of data sanitization for each unique identifier." Where no such software exists for a device, a software-controlled manufacturer-reset workflow can qualify. Operator-made spreadsheets are "not considered acceptable records."
• Independent sampling. SERI's quality controls article quotes Appendix B(13): a minimum of 5% of logically sanitized media "shall be routinely sampled by competent and independent party to demonstrate data is not recoverable by commercial software." SERI says this is more than checking the wiping software's own reports, and that the sample can drop toward 1% after sustained clean results.
• Annual process audit. The same article describes Core 7(c)(3) as an annual internal audit by a competent and independent auditor to validate the whole sanitization process, including whether all data devices were correctly identified.

One caution when reading SERI's pages: they were written in 2022 and compare R2v3 with Rev. 1 of SP 800-88, not Rev. 2. SERI also began its required five-year review of R2 in March 2025, and its estimated timeline puts a draft for public comment in early to mid 2027. Check the current text before relying on any detail.

The practical rule: "we follow NIST" does not mean "we meet R2v3 Appendix B," and the reverse is also true. Map each obligation to its own source.

6. What a defensible sanitization record should hold

The following is our recommendation. It starts from NIST's Section 4.6 fields and adds what an ITAD facility needs to reconstruct events without asking the technician.

Three design rules make these fields useful:

1. Record media identity before the wipe starts. A correct wipe attached to the wrong drive is an evidence failure. Scanning or reading the media serial at the start prevents it.
2. Never overwrite a failed attempt. A failed or rejected sanitization should stay in the history, with the retry, alternate method or destruction recorded as a new event. A record that only ever shows "pass" hides exactly what an auditor wants to see.
3. Keep verification and validation as separate fields with separate people. NIST's validation step and R2v3's independent sampling both assume someone other than the operator looks at the result.

7. Cryptographic erase needs context in the record

Cryptographic erase (CE) is fast and, used correctly, effective. Rev. 2 also makes it conditional. The NIST FAQ lists preconditions for CE to count as purge, including:

• no sensitive data stored on the media in plaintext before the encryption keys were established;
• algorithm strength of at least 128 bits;
• the target keys permanently sanitized by zeroization;
• for federal agencies, cryptographic modules validated to the current FIPS 140 standard.

A record that says only "crypto erase complete" can't show those conditions were met. At minimum, record the technique, the drive's encryption capability, how the result was verified, and whether policy accepted CE for that data category. Where a facility can't establish a precondition, such as whether data was ever written in plaintext, that is exactly the kind of residual risk NIST's validation step asks someone to accept or reject explicitly.

8. Where reCore fits

reCore is a processing and evidence platform for ITAD. Its sanitization records are built around the separation described above:

• One record per drive, tied to the device. Each wipe produces its own record with the drive's model, serial, capacity and interface, linked to the host device. A multi-drive laptop gets one record per drive.
• Failed attempts are kept. Every attempt is stored as its own record with the failure reason. A later success is a new record, not an overwrite.
• Verification depth follows a policy you set, and is recorded. By default the engine reads back at least 10 percent of the drive's user-addressable space. An organization can set its contractual assurance level (ADISA DIAL 1, 2 or 3) in its settings: DIAL 3 requires a hardware purge, failing the wipe rather than falling back to an overwrite, and a 100 percent read-back. The certificate reports the coverage achieved and any mismatches. For cryptographic erase the engine checks that marker data written before the erase is gone.
• Validation is a separate approval. A wipe arrives as pending. An administrator approves or rejects it, the approval is recorded with who and when, and the system checks that the approver isn't the technician recorded for the wipe. Approval freezes the certificate and stores a SHA-256 hash of its contents.
• Technicians are attributed. Wipes run under a technician's PIN-login session on the station, and every action lands in an audit trail.

There are limits, and the article would be misleading without them. reCore does not record a drive's current encryption state, it doesn't apply a cryptographic signature to certificates (the hash is a fingerprint of the content, not a signature), and NVMe Format and Sanitize run from the Linux boot environment only. It does not set your sanitization policy, perform independent R2v3 sampling for you, or certify anything on NIST's behalf. More on the engine is on the data wipe page and the NIST SP 800-88 standards page.

9. A quick self-check

If your current record answers "yes" to all of these, it is in good shape:

• Each certificate covers one storage device and names its serial.
• The method choice is recorded with the rule or instruction behind it.
• Tool name and version are on the record.
• Verification method and result are recorded separately from the approval.
• A named person other than the operator approves or rejects.
• Failed and rejected attempts remain visible after a retry.
• Final disposition is recorded against the same drive.
• You can map each field to the obligation that requires it: NIST guidance, R2v3, or a customer contract.

Conclusion

Rev. 2 didn't make the wipe method irrelevant. It still asks for the option that gives the most confidentiality protection. What it changed is where the weight sits: on a documented decision, a verified result, a separate acceptance, and a per-device record that ties them together. The question worth asking of any sanitization program a year on is not "did the tool say pass?" but "could someone who wasn't there reconstruct what happened to this drive, and why it was accepted?"

---

Sources

• NIST, SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025), full text. Sections 4, 4.1, 4.3, 4.5 and 4.6.
• NIST, Frequently Asked Questions for NIST SP 800-88r2, July 16, 2026.
• SERI, Specialty Process Requirements.
• SERI, R2v3 Formal Interpretation #1.0: Data Sanitization Software, effective November 29, 2022.
• SERI, Verifying the Effectiveness of the Data Sanitization Process, updated June 14, 2022.
• SERI, Discussion on Logical Data Sanitization in R2v3, updated November 29, 2022.
• SERI, R2 Five-Year Review.