Appendix B of the R2v3 Standard sets the requirements for facilities that sanitize data-bearing devices — chiefly logical sanitization, where software wipes the data so a device can be reused. For any ITAD operation, this is often the single most scrutinized part of the certification, because it’s the part your clients care about most: proof that the data on the devices they handed you is truly, verifiably gone.
If your facility wipes devices for reuse, Appendix B governs how you do it and how you prove it.
Logical and Physical Sanitization: Who Needs Appendix B
Every R2 facility is responsible for securing data-bearing devices and planning for their sanitization under Core Requirement 7. A device containing data — or potentially containing data — can then be sanitized in one of two ways:
- Logical sanitization — using data erasure software to wipe the data while keeping the device intact and functional (the path that preserves the device for reuse). Any R2v3 facility that performs logical sanitization must be certified to Appendix B.
- Physical sanitization — physically destroying the data-bearing media so the data can’t be recovered (shredding, degaussing, and the like). Physical destruction on its own does not require Appendix B; it’s handled under Core Requirement 7.
A facility might do one, the other, or both. You’re audited against the requirements for the processes you actually perform. Once you hold Appendix B, though, its requirements apply to all of your data-bearing devices — physical destruction included — rather than the lighter Core 7 rules. This piece focuses on the logical sanitization and quality-control side, since that’s where most reuse-focused facilities live.
What Appendix B Covers in General
Before getting into the specific requirements, it’s worth seeing the full scope. Appendix B is concerned with:
- A documented Data Sanitization Plan
- Traceability of every data-bearing device
- Training and evaluation of employees who handle data-bearing devices
- Device markings
- Security controls
- Data security and sanitization audits
- Logical and/or physical destruction requirements
- Quality control of the sanitization process
That breadth is the point: Appendix B treats data sanitization as a controlled, documented, auditable system — not a one-off action.
The Core Logical Sanitization Requirements
The heart of Appendix B’s logical requirements spells out what responsible software-based sanitization actually looks like. In plain terms:
- Keep electronic sanitization records created by the software, tied to the unique identifier of each piece of data storage media. Every wipe is documented, per device.
- Use sanitization software that is properly configured and maintained — configured to sanitize all user-addressable locations containing non-original data, configured to fail any media where a location can’t be sanitized, kept current with patches, and verified to be a supported version before use.
- Remove all connections — logins, passwords, locks, and any ties to a remote service must be removed so the device is no longer connected to anything.
And a crucial operational rule: where automated sanitization software exists for a device, you must use it. You can’t just run a factory reset or format the drive on a MacBook Pro, for example, when proper automated sanitization software exists for that device. The standard wants verifiable, recorded destruction — not a manual reset you hope worked.
The SERI Formal Interpretation on “Software”
This is the detail that trips facilities up, and it’s worth understanding precisely. In November 2022, SERI issued a Formal Interpretation clarifying what “software” means in requirements (10) and (11).
The short version: “software” means applications that automate, control, and record the results of data sanitization for each unique identifier — and software-based methods must be the primary method of logical sanitization, because manufacturer factory resets don’t always make data irrecoverable.
However, SERI acknowledged a real-world wrinkle: on some functional, undamaged devices, a manufacturer-provided reset may be the only available option. In those specific cases, “software” can extend to the application that directs, controls, and records the manual manufacturer-reset workflow — provided that application still fulfills the recording requirements of Appendix B (10) and the software requirements of (11). In other words, even when you fall back to a manufacturer reset, something has to be automating the control and record-keeping around it.
SERI also publishes a Sanitization Software Examples Information Sheet, a non-exhaustive table of commercially available tools. It is not an endorsement and does not say any listed product meets Appendix B, so it is a starting point for your own validation, not a substitute for it.
Why Appendix B Matters So Much
For most ITAD clients, data security is the whole reason they chose a certified vendor. A data breach traced back to improperly wiped equipment isn’t just embarrassing — it’s a legal and financial problem for both your client and you. Appendix B is what lets you stand behind your sanitization with documented, auditable proof rather than a verbal assurance. That proof is a genuine competitive advantage, not just a compliance checkbox.
It’s also where audits find problems. The common failure isn’t sanitization that didn’t work; it’s sanitization that was done reliably but recorded inconsistently — missing device-level records, or logical wiping carried out without Appendix B certification. Expect an auditor to pick a device at random and trace it from receipt, through sanitization, to disposition. Gaps in the middle are where this fails. We cover what auditors ask for in our R2 Center.
It’s also worth remembering how scope works: certification is appendix by appendix. A facility certified for materials recovery (Appendix E) is not automatically certified to wipe devices for reuse. When you tell clients you handle their data securely — or when you vet another recycler — confirm the certificate’s scope actually names Appendix B if wiping is part of what they do.
The Bottom Line
Appendix B turns “we wipe your data” into a controlled, documented, verifiable process. It requires a sanitization plan, full traceability, trained staff, properly configured and recorded software-based wiping, and quality control over the whole thing — with SERI’s Formal Interpretation making clear that automation, control, and record-keeping are non-negotiable even when a manufacturer reset is the only route. For an ITAD operation, getting Appendix B right is getting the most important promise you make to clients right.
Quick answers
What does R2v3 Appendix B cover? The requirements for data sanitization — chiefly logical (software erasure) — including the plan, traceability, training, software configuration, and quality control behind it. Physical destruction on its own is handled under Core Requirement 7.
What’s the difference between logical and physical sanitization? Logical sanitization uses software to wipe data while keeping the device functional for reuse; physical sanitization destroys the data-bearing media. A facility that performs logical sanitization must be certified to Appendix B; one that only physically destroys media follows Core 7.
Can I use a factory reset to sanitize data under Appendix B? Generally no — where automated sanitization software exists for a device, you must use it. A manufacturer reset is only acceptable in specific cases, and even then it must be directed, controlled, and recorded by qualifying software.
Does an R2v3 certificate automatically cover data destruction? Not necessarily. A facility that wipes devices for reuse needs Appendix B named in its scope. Physical destruction alone doesn’t require Appendix B, so check which methods a vendor actually uses and ask to see the scope on its certificate.
Want to be confident your data sanitization process would pass an R2v3 audit — and stand up to client scrutiny? Score your facility with our free R2v3 readiness quiz, or book a free readiness call and we’ll walk through it.
