R2v3 Data Sanitization Program Guide: Building Appendix B Evidence for the Audit

In my experience, many data sanitization findings trace back to something more basic than the sanitization method: a facility that cannot prove, device by device, what happened to the data. The wipe tool works fine. The records don't.

This guide walks through how Appendix B fits into the R2v3 Standard, what auditors look for, and how I would build a sanitization program from scratch for a facility that is new to R2v3 certification or has paperwork that needs updating. This is a program-building guide, not a clause-by-clause restatement of the standard. SERI revises the R2 Standard and its guidance over time, so take the clause-level requirements (sampling rules, particle-size limits, verification depth) from the current published text and your certification body's interpretation, and use the structure below to organize your evidence.

What is Appendix B in R2v3?

In the R2v3 Standard, data security is addressed in Core Requirement 8, and Appendix B covers data sanitization in more technical detail. Confirm the exact section titles and numbering against the current published text. For this guide, I treat Core Requirement 8 as the program-level question (protect data, control access, sanitize or destroy data-bearing devices, manage incidents) and Appendix B as the method-level question (how sanitization is carried out and verified).

An easy way to keep the two straight:

Both apply to any R2 facility that handles data-bearing devices. As I read the standard, data security can be treated as not applicable only if the facility does not receive or handle data-bearing equipment anywhere within its certified scope. A facility that handles any data-bearing equipment cannot scope the requirements out, even for a small share of its volume. Confirm the exact applicability wording in the current standard, record the not-applicable justification in your scope documentation (for example, a statement of the device types you accept and the intake controls that keep data-bearing items out), and expect the auditor to test it.

Which standard sits underneath Appendix B?

The sanitization framework you need to understand is NIST Special Publication 800-88, Guidelines for Media Sanitization. This guide uses the vocabulary of Revision 1 (December 2014). NIST has since published Revision 2, which is now the current NIST edition. R2v3 was released when Revision 1 was the current edition, so Revision 1 is the vocabulary the standard was written against. Confirm in the current SERI text, or with your certification body, whether Revision 2 has been adopted for audit purposes. Revision 1 defines three categories of sanitization:

• Clear applies logical techniques to user-addressable storage locations, such as overwriting. It protects against simple, non-invasive data recovery.
• Purge applies physical or logical techniques that make recovery infeasible even with state-of-the-art laboratory methods. Examples include cryptographic erase and block erase on supported media, and degaussing for magnetic media. Note that degaussing a modern hard drive destroys its servo tracks and renders it unusable, so it is a purge-then-scrap method, not a reuse method.
• Destroy renders the media unusable and recovery infeasible, typically through shredding, disintegration, or incineration.

Whichever revision applies, use the Clear, Purge, Destroy vocabulary consistently in your procedures.

The practical point is that R2v3 expects you to match the method to the media. A method that is fine for a spinning hard drive can leave data behind on flash storage. A legacy overwrite routine run on solid-state drives is a classic example of this mismatch.

How do you choose the right sanitization method for each media type?

This is where I would start the program. Build a media matrix before you write anything else, because every other document (work instructions, tool validation, training, sampling plans) hangs off it.

Two decisions are worth documenting explicitly, because auditors ask about both. First, which media you will never attempt to sanitize logically and will always destroy. Second, what happens when a logical method fails partway through. The answer should be a defined escalation to physical destruction, with the failed device recorded.

Reuse versus destruction

If a device is headed for resale or reuse, the sanitization has to be strong enough that the downstream owner cannot recover anything, and the method has to leave the device functional. If a device is headed for scrap, destruction is simpler and easier to verify. In my view, most facilities should default to destruction for anything that has no resale value and reserve logical purge for devices where the reuse value justifies the verification effort.

How do you validate sanitization tools?

Auditors want to see that you chose your software and equipment deliberately. A tool that happens to be installed is not evidence of anything.

A workable tool validation file contains:

1. The tool name, version, and the media types it is approved for.
2. The sanitization category it achieves (Clear or Purge) for each media type, with the vendor's documentation or an independent test as support.
3. A test of your own: sanitize a known-pattern drive, then attempt recovery with a forensic tool and record the result.
4. A change control rule: any software update or new tool triggers revalidation before production use.
5. For degaussers and shredders, the manufacturer's specification, calibration or maintenance records, and your periodic performance checks.

For physical destruction, record the output specification. If you shred drives, document the particle size your equipment produces and confirm that it meets the limit in the current standard text or your certification body's requirements for that media type. NIST SP 800-88 does not set one particle-size figure for all media. The required size depends on the media type and on the destruction specification cited, such as the NSA/CSS evaluated products lists, so record which specification you are claiming and the size it requires. Don't rely on a vendor brochure for that figure. Measure what comes out of the machine: for example, collect a handful of output pieces from a run, measure the largest, and record the result with the date and machine ID.

What does verification look like?

Sanitization without verification is a common gap. The facility should be able to show that sanitization was effective, not just that the process was run. Write your sampling rule to match the verification requirements in the current standard text. As an illustration only, with numbers you must replace with the figures from the current text, a rule might say: verify 100% of devices from a new customer or a new tool for the first batch, then 10% of each subsequent batch (never fewer than five devices), and return to 100% after any failure until a clean run is recorded.

In practice, I would structure verification in three layers:

• Tool-level evidence. The sanitization software produces a report for each device with serial number, method, start and end time, pass or fail status, and operator or station ID. Reject any tool that cannot produce a per-device record.
• Independent check. A person other than the one who ran the sanitization inspects a defined sample, using a second tool or a forensic read, and records the result. Document who is authorized to do this and what they were trained on.
• Destruction verification. For shredded or disintegrated media, someone inspects the output against your particle-size or condition criteria and records it against the batch or device list.

What happens when verification fails matters as much as the check itself. Write down the rule: a failed sample triggers re-sanitization or destruction of the affected batch, an investigation of the cause, and a record of the corrective action. Auditors often ask to see one example of a failure, and a program that has never recorded one looks like a program that isn't looking.

What records do auditors expect to see?

R2v3 is a traceability standard, so the question an auditor will keep returning to is whether you can follow a specific data-bearing device from receipt to final disposition. Build your record set around that path.

For each device, you should be able to produce the full chain within minutes. If the answer is "let me check three spreadsheets," the audit will go slowly and findings will follow.

Retention matters too. Set a retention period in your procedures, apply it consistently, and make sure it is long enough to cover your certification cycle and any contractual requirements from customers.

How should you handle data security around the sanitization process?

Appendix B methods only work inside a controlled environment, which is why Core Requirement 8 sits next to it. Auditors will walk the floor and look for:

• Data-bearing devices stored in a secured area, separated from non-data-bearing equipment, from the moment of receipt.
• Access limited to trained and authorized personnel, with a record of who they are.
• Training records tied to the specific tools and methods each person uses, with refresher intervals.
• An incident response procedure for lost, missing, or unsanitized data-bearing devices, including notification of the customer where required.
• Control over devices that arrive with unexpected data-bearing components, such as a piece of lab equipment with an internal drive.
• Cameras, badges, or other physical controls consistent with the risk you described in your plan.

If you operate under customer contracts that impose their own sanitization specifications, map those requirements into your procedures so a single process satisfies both. Where equipment may be export-controlled, the disposition requirements add another layer, which I cover on our export-controlled electronics disposition page.

Step-by-step: building an Appendix B program

Here is the order I would work in for a facility starting from partial documentation.

1. Define scope. Identify every device type you receive that can hold data, including the oddballs. Decide in writing what you will treat as data-bearing.
2. Build the media matrix. Assign Clear, Purge, or Destroy to each media type, with the specific method and tool.
3. Select and validate tools. Create the validation file for each tool, including your own recovery test.
4. Write the procedures. One work instruction per method, with screenshots or photographs of the actual stations. Include the failure and escalation path.
5. Set the verification plan. Define sample size, who verifies, how, and what a failure triggers, per the sampling rule you took from the standard.
6. Design the records. Make the per-device record the backbone and make sure each stage links to it by serial number or unique ID.
7. Train and authorize. Train each operator on the tools they use, test them, and keep the roster of authorized people current.
8. Run a pilot batch. Process real devices end to end, then audit your own records by picking five devices and tracing each from receipt to disposition.
9. Fix what the trace exposes. A trace like this often exposes a gap. Better that you find it than the auditor.
10. Hold an internal audit and management review before you schedule the certification audit.

Common audit findings and how to prevent them

How Appendix B connects to the rest of your R2v3 system

Data sanitization does not stand alone. R2v3 requires the facility to operate under a management system and to hold the required environmental, health, and safety certifications for its scope, and your sanitization procedures should sit inside that same document control, training, internal audit, and corrective action structure. If you already run ISO 9001-style controls, extend them to the sanitization process instead of creating a separate set. Auditors are more comfortable when sanitization records follow the same rules as everything else in the facility.

If you are pursuing R2v3 certification for the first time, expect the certification body to look hard at whether your documented process matches what actually happens on the floor. The gap between the paperwork and the floor is usually the problem, which is why I recommend an internal gap assessment before your first certification audit. Our contact page is there if you want outside help.

Pre-audit checklist

• Written media matrix covering every data-bearing device type you handle
• Each method assigned to Clear, Purge, or Destroy, consistent with NIST SP 800-88
• Validation file for every sanitization tool, with version and your own recovery test
• Destruction equipment specifications and periodic performance checks
• Per-device sanitization reports, linked by serial number
• Independent verification records and a defined sampling rule
• Failure and escalation procedure, with at least one recorded example
• Training and authorization records tied to specific tools
• Secure storage with access logs
• Incident response procedure for lost or unsanitized devices
• Retention schedule applied to all sanitization records
• A traced sample of five devices, receipt through disposition, with no missing links

Next step: pick one device from this week's intake, trace it through every row of the records table above, and list each missing link as a corrective action.

Last updated: 2026-10-28. Written against NIST SP 800-88 Rev. 1 vocabulary; the R2v3 text version and NIST revision you rely on should be confirmed against current SERI publications before use.

Frequently Asked Questions

What is Appendix B in the R2v3 Standard?

Appendix B of R2v3 is titled Data Sanitization. It supports Core Requirement 8 (Data Security) by setting out how data-bearing devices must be sanitized or destroyed and how the results are verified. Confirm exact requirements against the current SERI standard text.

Which sanitization guideline does R2v3 rely on?

The framework most auditors expect is NIST SP 800-88 Rev. 1, Guidelines for Media Sanitization (December 2014), which defines Clear, Purge, and Destroy. NIST has since published a later revision, so check which version your standard text and certification body reference.

Is overwriting enough for solid-state drives?

Usually not. Wear leveling can leave data in blocks a standard overwrite never reaches. Use cryptographic erase or vendor secure/block erase where the device supports it and you can verify it, and otherwise physically destroy the drive.

What records will an auditor ask for?

Expect to show per-device records from receipt to final disposition: serial number, method, tool and version, operator, result, independent verification, and any destruction record. You should be able to produce the full chain for any device quickly.

Do I need to validate my sanitization software?

Yes, in practice. Auditors expect evidence that you selected the tool deliberately, including the media it is approved for, its version, and ideally your own recovery test on a known-pattern drive. Revalidate after any software update.