GDPR View from the Outside: The Introduction of a “Data Protection Officer”

In the first two blogs in this series we evaluated GDPR and its impact to companies globally. Writing from outside of the EU (in the US), we’ve both been behind in our understanding of GDPR and lucky that we can learn from all the analysis that has already been done by our European counterparts. In my opinion, GDPR has been miscategorized as something only EU-based organizations need to worry about. Part of the inspiration for starting this series is to help educate companies who are just now realizing that they are beholden to these regulations, despite not basing their primary operations in the EU. In the second blog, we specifically looked at the concept of a data breach: what happens when one occurs, what type of data are considered sensitive and what organizations and affected.

In this blog, we’re going to look at another requirement of the GDPR: the establishment of a “Data Protection Officer.” While the context below is crucial, we believe that the push towards a data protection officer is a good idea for organizations worldwide. By functionally separating IT and responsibility to consumers’ data rights, we believe there will be fewer egregious data breaches and misuses.

Background

While most large enterprises in the US and the EU have had a Chief Information Security Officer for years, the Data Protection officer is a new role - both in the title and function. The requirements are outlined in Article 37 (“Designation of the data protection officer”), Article 38 (“Position of the data protection officer”) and Article 39 (“Tasks of the data protection officer”). The role has generated significant conversation about what is required and the situational implementation inside organizations which we’ll dig into!

Role definitions and requirements

The Data Protection Officer’s roles are predominantly called out in Article 39. It’s worth reviewing each (rewritten in plain English):

• Organizational Educator (Article 37.1.a): The Data Protection officer must advise the organizations who are processing or contracting the processing of personal data, and the employees who are actually doing so, about GDPR and the requirements to which they’re beholden. Notably this means educating and ensuring broad understanding by a large number of employees or contract employees that do not actually work for the Data Protection Officer.

• Compliance Monitor (Article 37.1.b): The Data Protection Officer must monitor compliance with GDPR. This includes education activities (as above), the actual protection (whether by process or product) and audit of GDPR-related practices. For a short description (and a sub-sub-bullet in the regulation) this drives considerable complexity to the role. In short, the person (or team) in the role must be able to educate, understand the current state of adherence, help enforce the regulation (by selecting / monitoring products services) and help audit the above as well. Adding this all up, it quickly can become more than one person’s job!

• Impact / Solution Assessor (Article 37.1.c): The Data Protection Officer must provide guidance about adherence to GDPR, selection and implementation of new technologies that affect the processing of personal data and the impact to personal data protection and ongoing monitoring of new systems. As new technology is built (e.g. a new system or service that interacts with personally identifiable information) the Data Protection Officer may be asked to comment on the use of data, the safeguards put in place and the resulting change to the organization's data protection (as outlined in Article 35).

• Regulatory Point of Contact (Article 37.1.d/e): The Data Protection Officer is the point of contact for for the relevant supervisory authority.

• Risk Assessor (Article 37.2): The Data Protection Officer is expected to understand the risk associated with the company’s data processing activities (whether internal or external).

What’s most surprising in this role is how broad and deep this role needs to be. It requires understanding of legal and regulatory frameworks (interacting with supervisory authority, understanding compliance), while at the same time understanding all services and applications that are processing sensitive data, the way they do so, the processes put in place to prevent unauthorized usage profiling and the building of risk models. This is hard to put in a single sentence, let alone to manage in a single role. As we’ve advised companies, however, this role should really be thought of as a data ombudsman - a role or collection of people who operate independently of the lines of business and on behalf of consumers. In effect, the role is to ensure that the company does what’s right for the individuals, even if that’s at odds with the business.

Organizational requirements

Not every organization needs to have the data protection officer on staff. Article 37 calls out several key specifications:

• Article 37.2: Notes that conglomerates / holding companies may use a single Data Protection Officer, assuming that each company or unit can sufficiently access the Data Protection Officer.

• Article 37.3: Notes that public organizations may share a Data Protection Officer, dependent on their size a structure. The implication is that many, small public organizations can share a data protection officer, whereas large or complicated ones cannot.

• Article 37.6: Notes that the Data Protection officer does not actually have to be on the staff of the organization - contracts with third parties are acceptable.

Throughout this blog, we’ve typically focused on enterprises, but note that this regulations can apply to companies of any size so long as they’re a data controller or processor. Note the previous German Federal Data Protection Act (see “Precedent” below)  did limit this to companies above 10 employees. In our opinion, the biggest take away from the organizational part of the Data Protection Officer is that it doesn’t have to be on the payroll. While this immediately makes sense for small organizations who likely do not have the resources or capital to afford it, we also believe that it also makes sense for large organizations to consider outsourcing some of the role as well. Given the breadth of the job, it’s unlikely organizations will staff all of the functions, much like how organizations outsource some of security, legal and other functions.

Beyond the types of organizations that require a Data Protection Officer, there are important further requirements about how the organization must place and treat the officer. This is covered in Article 38:

• Strict Involvement with Personal Data Matters (Article 38.1): The organization must involve the Data Protection Officer in all matters involving personal data. We can never say with perfect certainty of course, but we expect that with a required Data Protection Officer involved, situations like Uber’s data breach cover up never would have happened.

• Access and Sufficient Resources (Article 38.2): The organization must supply adequate resources and access to perform any analyse or execute any changes needed in support of protecting personally identifiable information. Further, the Data Protection Officer is a role that must exist at the highest level of the organization - not buried under levels of management.

• Separation of Duties (Article 38.3): The Data Protection officer must act independently - specifically they do not take orders from any of the lines of business (in either the processor or controller if they’re separate).

The quick take away is quite revealing - the Data Protection Officer is required (though not necessarily to be employed) by all organizations that handle personally identifiable information and must be allowed to act independently of the business that they are monitoring.

Precedent

The concept of handling sensitive data (broadly) and ensuring that organizations protect their customers and their reputations is not new; although we can make a strong case that it’s been too loosely managed. However, in most countries there was no rule that led to the creation of an entirely separate role to handle data privacy.

The exception is Germany, as the role of Data Protection Officer has been introduced in advance of GDPR in Germany with the Federal Data Protection Act. Passed in early 2017, it can give us some early indications about the impact of the Data Protection Officer and how it should be handled. Most interestingly, the German government has already levied fines against companies who did not properly establish a Data Protection Officer. In the case of the fine under existing law, german authorities deemed that an organization who had dual roles of Data Protection Officer and IT Manager could not effectively act independently. This is notable as much of German data protection law is precedent for GDPR and the indications are that it will be taken very seriously and we expect similar fines will come as the regulation takes hold. Under the above description, this dual role for IT Manager and Data Protection Officer would clear violate a number of the stipulations - notably Article 38.

Take aways

In summary, while much of the exercise of data security, and in particular reducing the risk of breach of personally identifiable information, is well-known to organizations, there are a number of key changes. GDPR had codified roles and organization structures that have been maturing over time and enforces these via fines. While organizations do not have to have a Data Protection Officer on staff in all situations, the service provided by a Data Protection Officer must be available (by outside sources).

Finally, there are a few key changes we want to finish with and give our recommendations:

• Shared Responisiblities: The Data Protection Officer is how it is a separate, and yet quite complex role. To be in adherence to the law, DPO needs to have wide ranging reign and expertise across IT, traditional security, security offerings and the legal directives. Our expectation (and recommendations) is that this is handled by a team of under a Data Protection Officer (and leveraging key outsourced companies) to handle the functionally different exercises - risk assessment, vendor assessment and legal compliance.

• Functionally separate: The Data Protection Officer is a functionally separate role from IT, which we support. We’ve noted this trend over the past couple of years as we’ve sold our data privacy products to IT and separate security organizations. We expect this to become best practice - functionally separating IT implementation from data privacy responsibilities.

• Impact and Role of Technology and Vendors: Given the breadth of roles covered above and the complexity and value of data in 2017, a number of systems will be required to assist the Data Protection Officer. No one vendor will be able to provide a complete set of solutions or replace the process required from a Data Protection Officer and their team. We recommend careful assessment of the individual roles, responsibilities and expectations and determine where vendors are applicable.

In general, we think the push towards standardization of a Data Protection Officer is a good thing. The cost can be mitigated by use of an external party (if your org or data are sufficiently small). The on-going process and product selection, including analysis of existing data, understand of risk / impact and then finally the selection of controls, can be long and complicated, but there are a lot of well-educated people and companies. Delphix can help with some of these (data management, data analysis, data masking), but as mentioned above, no one vendor will be a solution for broad-based GDPR adherence.