R2v3 Sanitization Records: Why Spreadsheets Fail the Audit

Spreadsheets fail an R2v3 audit because SERI has said, in writing, that they aren't acceptable sanitization records. Its Formal Interpretation #1.0 says simple operator created records on a spreadsheet "are not considered acceptable records of software sanitization as these are more vulnerable to errors and suspect results." So R2v3 sanitization records have to come from the software that did the wipe, one record per device, with the serial read by that software and the time set by the system.

This post is about those records: what the auditor will ask to see, where hand-kept logs break, and how to check your own before the audit. If you want the full Appendix B checklist (plan, sampling, physical security), that's in our R2v3 data sanitization guide. This one stays on the evidence.

---

1. What SERI actually said

SERI is the body that owns the R2 standard (how R2v3 compares with other ITAD certifications). Appendix B of R2v3 covers data sanitization, and its requirements (10) and (11) cover records and software. After hearing that facilities were struggling with the software requirement, SERI asked for a formal ruling on what "software" means. The R2 Standard Consensus Body approved the answer: Formal Interpretation #1.0, effective November 29, 2022.

Three lines in it matter most for records:

• What software is. "'Software' is intended to mean applications that automate, control, and record results of data sanitization for each unique identifier."
• What isn't a record. The spreadsheet line quoted above, under the heading "Evaluating Records required in Appendix B(10)".
• That it counts. "This Formal Interpretation is binding and auditable as part of a company's R2 Certificate."

So a spreadsheet isn't a weak record. It's a record SERI has told auditors not to accept for logical sanitization.

It's worth reading the reason SERI gives: "more vulnerable to errors and suspect results." That's two problems. People make typing mistakes. And a record someone typed can't show that a wipe really happened, because the person could type anything.

2. The fields SERI recommends for each record

The same interpretation lists recommended data points for a sanitization record. SERI says it modeled them on NIST SP 800-88 Rev. 1, Section 4.8. Here they are, with SERI's own notes in quotes:

• Device or media manufacturer, model, and serial number, "preferably read by the software and not manually entered"
• A unique identifier you assign, "preferably scanned from a label"
• Media type (magnetic, flash, hybrid) and media source (the user or computer it came from)
• Capacity
• Sanitization type: Clear, Purge or Destroy
• Method used: overwrite, block erase, crypto erase and so on
• Tool used, "including version"
• The sanitization person: name, position, date and time "automatically recorded from the system", location, contact details, signature
• Verification method, such as a verified sanitization record or sampling
• The verification person: the same details again

Notice the pattern in SERI's own notes. The serial should be read by the software. The identifier should be scanned. The time should come from the system. Every one of those is SERI asking you to take the human out of the typing.

And notice there are two people. The record has a block for whoever ran the wipe and a separate block for whoever verified it.

NIST has since published Rev. 2, which has its own list of certificate fields. Our certificate of sanitization template covers that list field by field.

3. Where a spreadsheet or paper log breaks

Here's each thing an auditor can ask for, why a hand-kept log struggles with it, and what a software record does instead.

None of this means the people keeping the spreadsheet were careless. A spreadsheet just has no way to prove where a value came from. The auditor can't tell a serial that was read from a drive from one that was typed in later, and neither can you.

4. Records feed the nonconformances SERI sees most

SERI's Podcast 19, recorded in late February 2023, went through the most common nonconformances from "more than 600 R2v3 audits." Three of the eleven came from Appendix B:

• No 60 days of video of the areas where data devices are received, stored or passed through (Appendix B, requirement 5(c)).
• No 60 days of video of physical data destruction (requirement 9).
• Not meeting requirement 13, "which calls for routine sampling of all logically sanitized data storage media, to verify data is not recoverable by commercial software."

The same list included Core Requirement 7(c)(3), the annual data security and data sanitization audit.

The sampling one depends on records more than it looks. SERI's quality controls guidance quotes requirement 13: "A minimum of 5% of logically sanitized data storage media shall be routinely sampled by competent and independent party to demonstrate data is not recoverable by commercial software." It gives a worked example: 1,000 devices sanitized in a week means at least 50 sampled from that week. After continued clean results, the rate can drop to as low as 1%.

To do that properly, you have to know what was wiped in a given period. SERI also says the sampling "should include samples from each operator and station performing the logical sanitization" and should "evaluate each type of media, software and process used." You can't pick a fair sample by operator, station and media type unless every wipe record already says which operator, which station and which media type. A spreadsheet with a date and a serial can't give you that.

And if a sample does turn up data, SERI says "previously processed devices would need to be further assessed." Finding those devices means searching your records by method, tool, station or date. Again, the records decide how big that job is.

5. Check your own records before the auditor does

We'd start with ten drives picked at random from last month. Try these on each. None takes more than a few minutes.

1. Find each drive by its serial. Not the laptop's serial, the drive's. If a machine had two drives, find both.
2. Read the serial off the drive itself and compare it with your record. Any mismatch is a typed serial.
3. Check where the time came from. Was it written by the software when the wipe ran, or typed by a person?
4. Look for the tool version. "Wiping software" is not a version.
5. Look for two different people. One who did the wipe and one who verified it, each named.
6. Find a failed wipe. If you can't find a single failed attempt in a month, either nothing ever fails or failures are being overwritten.
7. Ask who can edit a record after the fact, and whether you'd see that it changed.
8. Pull last week's wipes by operator, station and media type. That's the list your requirement 13 sample should come from.

If more than a couple of these fail, you've found what the auditor would have found.

6. What reCore records automatically

reCore is our wiping and diagnostics software for ITAD and refurbishing benches. Here's what it keeps for each wipe, without anyone typing it:

• One record per drive, tied to the device it came out of.
• The drive's serial and model, read from the drive by the station, on Windows and on Linux.
• The method and technique, the NIST category (Clear or Purge) and the number of passes.
• Tool name and version.
• Verification: the method, the result and how much of the drive was read back.
• Start and finish times, plus whether the station's clock had been checked against the server when it took them.
• Failed wipes stay as records, with the failure reason. They never get a certificate.
• Two people. A completed wipe waits as "pending" until an admin approves it. The server refuses the approval if the approver is the technician who ran the wipe.
• Locked once issued. On approval the certificate data is frozen and given a SHA-256 fingerprint. Every certificate is checked against it before it's shown, and one that doesn't match is refused. A wipe record with an issued certificate can't be deleted. We'll be plain about it: it's a fingerprint, not a digital signature.
• Certificates one at a time or in bulk, up to 200 in a single PDF.

Two honest limits. reCore doesn't do the requirement 13 sampling for you. That's meant to be an independent person running data recovery software on wiped drives. What reCore gives you is the list to sample from: you can pull wipes by date and method, and each record names the technician, the station and the media type. And reCore doesn't make a facility R2v3 certified. R2v3 certifies facilities, not software.

The compliance page shows the certificate and the approval step. Our R2v3 compliance overview maps the rest of Appendix B, and pricing has the plans and the free trial.

Conclusion

The audit question isn't "did you wipe it?" It's "show me." SERI has already said a spreadsheet can't answer that for logical sanitization. The record has to come from the software, one per device, with the serial read by the software, the time set by the system, and a second person who checked. Run the ten-drive test above this week. Whatever it finds, it's cheaper to find it now than in the audit.

---

Sources

• SERI, R2v3 Formal Interpretation #1.0: Data Sanitization Software, effective November 29, 2022 (PDF version): definition of software, the spreadsheet ruling, recommended record fields, the manufacturer-reset exception.
• SERI, Podcast 19: Most Common Nonconformances in R2v3 Audits, recorded February 2023: the eleven most common nonconformances, three from Appendix B.
• SERI, Verifying the Effectiveness of the Data Sanitization Process: the text of Appendix B requirement 13, the sampling example, and sampling by operator and station.

We quote Appendix B only where SERI's own pages quote it. The R2v3 standard itself is available from SERI's website; check the current text before you rely on any detail. The interpretation stays in force until the next revision of R2 is published.