Data sanitization is a complex process that requires technical expertise to be effectively designed and implemented.  The multi-layer approach in the R2v3 Standard is designed to build in multiple safeguards to prevent mistakes in data sanitization that can result in data breaches.  It reflects quality management system best practices that incorporates fundamental checks and balances in the data sanitization process which creates accountability and transparency that promotes confidence in the results.

In addition, the R2 Standard is designed to promote a Circular Economy where electronics are reused where possible before recycling.  This is required in Core 2 – Hierarchy of Responsible Management Strategies.  Reuse is only possible when previous user data can be sanitized without physical damage and not recoverable by commercial software.  Reuse cannot be accomplished where it exposes personal, private, or confidential information of the previous users.  In R2v3, the only path for the logical sanitization of data to reuse a device is found in Appendix B.

Appendix B requires that media is logically sanitized using software instead of manually reset.  This is intended to ensure a level of rigor, transparency, and accountability that can be relied upon to be confident that data has been properly sanitized, so the device can be reused.  Users may sanitize their own device manually, as it is their individual choice and risk.  However, to certify a commercial facility to logically sanitize other people’s data to reuse their device, a higher bar is required to mitigate the risks.

Solution – Transparency and accountability

Logical data sanitization is critical to reuse of electronics.  Without confidence that private, personal, or confidential data is not recoverable, devices will likely be physically destroyed to protect that data.  Transparency of who, what, where, when, and how a device was sanitized is important to the credibility of the process.  While automation is the best practice, this information could be gathered with a combination of automated and manual workflows.  For example, where the device information can be read digitally by the software, that part could be automated.  However, the sanitization might be impossible by software, and therefore still requires a manual reset. Other options that can reduce data entry errors could include scanning of barcodes or QR labels on the device to capture device information.

Accountability is the second part of credibility.  Historically we have seen spreadsheets of media that has been sanitized.  Spreadsheets lend themselves to errors in transcribing information, and copying and pasting records, which leads to a lack of accuracy and accountability for each media/device sanitized.  The workflows in the manufacturer reset process should be detailed in the steps to remind the technician of each required step and force the technician to sign off on each step, not just a general signoff on the device or batch of devices.  Recording that each step has been completed creates greater accountability that each step was followed and makes the technician accountable for sanitization of each device.

Challenge – Exploding Market of “Smart” Devices

Since the development of version 3 of the R2 Standard, the types of new electronics that have become “smart” with data storage has exploded.  This has created an environment where new devices are being sold without planning for the sanitization of user data stored on these devices.  While proprietary data storage adds a level of data security, it also potentially prevents the reuse of working devices when the previous user’s data cannot be removed.  A trend has started where commercial software designed to sanitize data cannot always access new devices for data sanitization because of their unique proprietary design.  This is not an end-of-life problem that has years to resolve itself.  The challenge starts when new products are bought, configured, and returned to the retailer with data.

Recognizing this challenge, it is not always possible to sanitize all devices with software that automates, controls, and records the process.   The intent is not to destroy working devices if a credible method can be used to reliably sanitize the data to the manufacturer’s specifications with transparency and accountability.  Therefore, it is important to accept alternative data sanitization solutions which are proven to effectively remove data from the devices that will be resold.

In cases where no automated software exists, the software could integrate the manufacturer’s reset instructions to control the process and produce the data that would create a reliable record of the data sanitization event for each device.  This is more than a spreadsheet which can be subject to alteration or falsification.

Challenge – Gaps in Data Sanitization

Some specific gaps in properly sanitizing data have been demonstrated over time.  For example, formatting a hard disk does not erase the data.  Unencrypted Android devices that have been factory reset show no data when one visually inspects the device for data.  However, when using a commercial data recovery software, a scan will often return pictures, contacts, and messages that are still accessible.  Likewise, a factory reset may simply reset the device to the default configuration without removing access to the previous data.

Challenge – Encryption

Unencrypted devices are often the culprit of manual reset functions gone wrong.  Manual resets can be effective where data is encrypted from the initial setup of the device, but not effective when the device is unencrypted or was encrypted later.

When data is unencrypted on a device, the data often remains in the background after a reset, because the reset does not overwrite the data.  While it is not visually seen when inspecting the device for data, it can be accessed by commercial software when connecting to a computer and scanning for data.  Conversely, encrypted devices are less likely to be recoverable by commercial software.  While the device is similarly reset without actually overwriting the data, once the encryption key is destroyed in the reset process there is no way to read the data.

This can be a confusing because although data encryption can be the default on a device, it may not be mandatory.  If encryption can be turned off, then it may expose data from that point forward.  It is complex and requires technical expertise to evaluate and guide the process of data sanitization for each device model and not make general assumptions.

Verification of Sanitization with “Commercial Software” – Appendix B(13)

“Commercial software” in Appendix B(13) refers to the level of data recovery techniques applied to the sampling method.   This requirement in R2v3 is similar to NIST SP 800-88 Rev. 1 in Section 4.7.3 where the task is to read back the storage on the device to verify it has been overwritten or the previous data is inaccessible (outside of a laboratory).  Effectively, R2v3 sets the level of logical data sanitization between Clear and Purge, as described in NIST SP 800-88 Rev.1 Section 2.5.

Clear is effective for devices that where all addressable storage locations can be overwritten.  Some proprietary devices do not provide options for overwrite.  Manufacturer resets may be the only option to clear a device.  According to Table 5.1, “These still meet the definition for Clear as long as the device interface available to the user does not facilitate retrieval of the Cleared data.”  Visual inspection of a cleared device would not meet Appendix B(13) requirements, and therefore Clear using a the factory reset is not always an effective option for R2v3.

However, Purge is a step further than what R2v3 requires.  Purge “renders Target Data recovery infeasible using state of the art laboratory techniques.  R2v3 is not requiring this level of logical sanitization so that data cannot be recovered by scientific forensic recovery techniques.  Appendix B(13) requires a level not recovered by “commercial software”.

Appendix B(13) is different than verifying that a record of data sanitization is available for the media.  This requirement relies on the technique of actually trying to recover data from the device.  This can often be accomplished by commercial software products for data recovery, often used when a user loses data on a failed hard drive or other device.  This type of software is commonly free when used only to scan for recognizable data on a device.

If a device cannot be physically accessed by commercial software because there is no way to connect a functional device (no IO port or remote access), then by design, there is no means to recover data by commercial software.  This would require forensic analysis to possibly recover data, which is beyond the requirement set forth in Appendix B (13).