[Note: “Text in italics and quotes” below are quoted directly from the R2v3 second draft standard.]
In Part 1 of this series, we discussed the second draft of the R2v3 standard – specifically, the introduction. This covered applicability and scope as well as Sanctioned Interpretations, and highlighted some areas we want to pay attention to. Part 2 reviewed the Definitions section – some changes, additions, deletions, and the Focus Materials Table.
In Part 3, we started digging into the standard’s Core Requirements (CRs) – the auditable portion of the R2v3 standard. Specifically, the Scope and Hierarchy of Responsible Management Strategies.
In Part 4 of the series, we covered two short, but very important, Core Requirements – CR 3, EH&S Management System, and CR 4, Legal and Other Requirements.
In Part 5 which addressed Throughput Tracking, we discussed what inbound and out outbound summary reports should include, and how to address negative value.
In Part 6 we discuss sorting, categorization, and processing, including a helpful flowchart on how to process, including references to applicable Appendices.
Now, in Part 7, we’re going to be discussing Data Security (R2:2013 Provisions 8 & 10)
Data Security ensures that the electronics we are handling are protected from data breaches, through the use of secured areas, data sanitation, and compliance with legal and regulatory requirements for this Core Requirement.
Core Requirement 7 describes the documentation that must be maintained, including
“(A) Security controls to protect data in the R2 Facility’s control, including declarations of secured areas dedicated to data sanitization with access limited to authorized individuals, and
(B) Types of data storage devices accepted that may contain data, and
(C) Types of data to be sanitized, and
(D) Declaration of general information that does not need to be sanitized, and
(E) Potential associations to network services that could automatically repopulate data on the device, and
(F) Written contractual requirements not to sanitize data on user’s data storage devices when requested, and
(G) Applicable legal, supplier, and other requirements for data sanitization including applicable data breach and privacy regulations, and
(H) Where legal, supplier, and other requirements are addressed in written policies and procedures to ensure conformance, and
(I) Methods for data sanitization for each type of data storage device, and
(J) Planned durations to sanitize data from the time of receipt, and
(K) Downstream vendors or contractors that perform data sanitization in accordance with this plan, if data sanitization is not performed internally, and, where applicable, those downstream vendors whose services will be provided in another country, and
(L) Records to be maintained to demonstrate the effectiveness of the sanitization and verification activities, and
(M) Process for authorizing and monitoring workers, visitors, and others permitted to have access to equipment and components containing data.”
Wow – that’s a lot of requirements! And that’s just under documentation – as you see when you continue reading below, there is also the requirements for a written data security policy – so there are a LOT of documentation requirements here.
Let’s break it down a bit:
(A) Requires you to have a dedicated area:
(B) Says that you have to have a list of different data storage devices
(C) This list is for what needs to be sanitized by type
(D)And this list is what doesn’t fall into (c)
(E) Look at your network services to determine if you can automatically repopulate data devices
(F) Written contracts not to sanitize users data storage device if requested
(G) Conform with CR 4 – legal and other requirements (so make sure CR 4 includes GDPR if that applies to you, data breach regulations, privacy regulations, etc.)
(H) Conform with your own written policies and procedures
(I) List methods of sanitation or each type of data storage device
(J) List timeline between receipt of materials and data sanitation
(K) Same goes for DSV’s (Downstream Vendors)
(L) Maintain records of sanitation/verification effectiveness, and
(M) Document how you authorize and monitor workers, visitors, and others with access.
The Data Security Policy CR 7.a.2, requires a facility to document/maintain a written security policy, that meets several requirements, including
“(A) Prohibits unauthorized individuals from accessing or handling equipment containing data, and
(B) Assigns a competent Data Protection Representative with the overall responsibility and authority for the R2 Facility’s data security and legal compliance, including oversight of all related duties otherwise assigned, and
(C) Mandates reporting of known and suspected breaches of security and data to the Data Protection Representative, and
(D) Requires completed training and confidentiality agreements prior to individual authorization to handle equipment containing data, and
(E) Identifies penalties for non-compliance with the policy, including personal liability.”
This has been changed slightly – the first draft required a Data Protection Manager, with no guidance on what would qualify someone as a DPM. This change to a Representative is meant to allow more flexibility on this, and simply ensures that someone has the responsibility for data security and legal compliance. A quick check of CR 4 does not show the requirement for a DPR, so it pays to note that this requirement covers both data security and legal compliance, but is not called out as part of Legal and Other Requirements, indicating that formal training/certification may not be required.
CR 7.a.3 finishes up by requiring regular training and verification of competence on both policies and procedures for data security, dependent on their level of authorization.
7.b deals with Security, and requires a security program to be in place, controlling access to all or part of the facility as appropriate. There must be levels of security authorization to control access, and this applies to visitors and contract workers as well as employees. Secured areas must be clearly defined, labelled with signage; and security controls must be in place to limit access to equipment.
For folks granted authorization, each person must have written acknowledgement of their responsibilities vis a vis disclosure of data, theft of equipment or data, data breaches; and must disclose any incidents that they are aware of.
When an incident is reported, an incident response procedure will be followed to investigate.
CR 7.c is Process, and states that
” (1) For the receiving of any equipment or components that may contain data, the R2 Facility shall provide to the supplier confirmation of:
(A) Receipt of equipment or components containing data, and
(B) The method of data sanitization to be used, and
(C) Whether data sanitization will be performed internally or by a downstream vendor.
(2) Equipment and components containing data shall be sanitized in a timely and effective manner, in accordance with one of the following methods, as disclosed to the supplier:
(A) Sanitize the data on the data storage devices in accordance with Appendix B – Data Sanitization, or
(B) Physically destroy the data storage media in accordance with an applicable method defined in Appendix A of the NIST Guidelines for Media Sanitization: Special Publication 800-88 (rev.1), and verify destruction in accordance with a defined process to demonstrate 100% effectiveness of the destruction process, or
(C) Ship/transfer data storage devices under written contract to a downstream vendor that has been verified in accordance with Appendix A – Downstream Recycling Chain, with the capabilities to sanitize data from the type of equipment shipped in accordance with the planned method disclosed to the supplier.
(3) Internal data security and sanitization audits shall be performed at minimum annually by a competent and independent auditor to validate the data sanitization processes are effective and conforming to the R2 Standard, legal requirements, and the data sanitization plan.”
This CR has a lot going on – it refers to options for data sanitation, which could lead back to Appendix B for DSV, or Appendix A for NIST Guidelines for Media Sanitation. Again, there are a lot of moving parts in this revised standard, and the Appendices are going to play a big part in how some of this may be accomplished if you are using R2 or non-R2 Downstream Vendors for data sanitation.
Finally, for CR 7.d, Notification, it requires an R2 facility to provide information to suppliers where requested of changes in DSV and breaches in security.
This has been updated to provide the information only when requested, which should make the paperwork monster a bit easier to tame; and the word “suspected” prior to breaches in security has been removed – again, for clarity’s sake and because, practically, no one is going to report a suspected breach in security until they’ve investigated it.
But wait – we’re not done yet!
Next up: Core Requirement 8 – Focus Materials
There’s a lot of information in these posts! Can’t wait for the entire series and want to engage with us now? Contact us to start the process!
Interested in getting some assistance on R2 implementation? Check out our other blog posts or contact us to get more info.
