Identity Crisis: Data Protection Roles for Life Sciences Companies

James Clark

The advent of the General Data Protection Regulation (GDPR) has brought with it a complicated range of challenges for businesses operating in life sciences. From transparency and privacy notices, to the use of consent,  from contracts with service providers, to extended data subject rights, the potential headaches are numerous. However, in order to successfully navigate this world and to make informed decisions about exactly which obligations are applicable, the fundamental question is always the following: "What role am I playing under the GDPR?" Controller; joint controller; processor; sub-processor - each has a unique status, and the statutory obligations, and therefore exposure to liability, vary from one to the next. 

Data protection roles exist as a matter of law - they flow from the factual context, not vice versa.  Consequently, whilst organizations may record their expectations about the role they are playing in a contract or policy, ultimately that status is determined by the application of legal definitions to their activities, and not by anyone's intentions.

Definitions

The key definitions of controller and processor, under Article 4 of the GDPR, are as follows (emphasis added):

•  "controller" means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law;

• "processor" means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.

As the definition of controller suggests, an organization can either be performing that role in isolation, or as a joint controller with one or more other controllers, in which case the provisions of Article 26 (Joint Controllers) become relevant. The term sub-processor is not actually used in the GDPR, but is widely understood (including by supervisory authorities) as referring to a secondary processor to whom the primary processor sub-contracts some or all of the controller's instructions, under Article 28(2). 

What has changed under the GDPR?

The law which preceded the GDPR in the EU (Directive 95/46/EC) contained substantially the same definitions of a controller and a processor. However, whilst the concepts have remained constant, there has been a significant change how the law treats processors. Whereas previously a processor had no obligations of its own, and was only liable in contract to the controller, processors now face their own direct obligations under the GDPR, which bring with them direct liability to supervisory authorities and to data subjects.  This inevitably colors the way in which organizations approach the role of being a processor, and means that a major incentive for acting as a mere processor has vanished.

The GDPR also introduces specific requirements for joint controllers which did not previously exist. Chief among these is an obligation to determine, in a transparent manner, their respective responsibilities for compliance with the obligations of a controller under the law.  Frequently this arrangement is documented in writing in the form of a binding "joint controller agreement", although this is not strictly necessary.  As we will see, the joint controller dynamic is potentially a common one in a clinical trial context. 

Typical examples for life sciences companies

It has been settled law for some time now that the sponsor of a clinical trial acts as a controller, and this position remains the same under the GDPR.  Importantly, a sponsor can be a controller regardless of whether it ever actually obtains access to personally identifiable information. As the EU supervisory authorities have made clear[1], the determining factor is whether a particular actor determines the purposes and/or means of the processing of personal data. Therefore, as a sponsor makes the key decisions about "why" (and, to a greater or lesser extent, "how") personal data is processed, it acts as a controller, even if no-one within the sponsor ever touches the personal data which is obtained from participants.[2]  However, at this point it is worth noting that the scope of personal data under the GDPR expressly includes so called pseudonymized data, which would encompass the key-coded data which a sponsor typically would receive.  

Alongside the sponsor, a trial site will, in many cases, be regarded as a joint controller. In order to assess whether an actor is making decisions about the purposes or means of processing, it can be helpful to consider the expertise that they wield, and the degree of independence or autonomy that this grants them in processing personal data. Organizations which bring a high level of expertise and independence to their role will typically be controllers, even if they are appointed by, and are ultimately providing a service to, another controller.  In this light, where a trial site is autonomously collecting patient data, obtaining consents, and making decisions about the running of a trial (even if it adheres to guidelines from the sponsor), it will be a joint controller.    Similarly, a CRO may also be a joint controller in circumstances where the full clinical development plan is delegated to it, and it therefore assumes sufficient operational independence and decision-making autonomy.

However,  it is perhaps more common for the CRO to be seen as a processor, as typically its margin of man oeuvre in developing or operating the trial is sufficiently constrained by instructions or oversight from the sponsor. In most cases, providers of IT solutions which involve the hosting or processing of data (including SaaS solutions) will act as processors. In a pharmaceutical context, this would include IRT / IVRS and IWRS providers, but also suppliers of more generic software, such as Human Resources and Customer Relationship Management platforms. 

As an important side note to clinical trials - health care professionals, either in their own right or through the hospitals or other medical centers through which they operate, will typically be controllers in their own right vis-à-vis their relationship with their patients, particularly where they are collecting data for clinical (rather than research) purposes. 

Finally, in the world of market research, an important trend has developed to regard the client sponsoring the research and the market research provider as joint controllers. As is the case with a trial sponsor, whilst the client may never know the identity of the participants, who will only ever interact with the research provider, the client is nevertheless making important determinations about the purpose of the research and, in some cases, the operational means by which the research will be carried out (for example by feeding into the design of the questionnaire). 

Practical implications

A significant challenge for sponsors of both clinical trials and market research arises from the lack of an interface between the sponsor and the data subject.  Indeed, in double blind studies, it is an ethical imperative that there is no direct interaction between the two. Consequently, the presentation of a privacy notice which identifies the sponsor is a dilemma, as is the sponsor's ability to respond to and deal with data subject rights requests (for example for access to, or erasure of, personal data). A compromise which we are increasingly seeing is for the joint controller in these contexts (e.g. the trial site or the market research provider) to be the primary point of contact for the data subject. The data subject can then be told that there is a sponsor who is also a data controller, but that the parties have determined that data subject rights will be dealt with via the first controller. If the data subject insists on learning the full identity of the sponsor, that request can be satisfied, but the data subject must understand that it may come at the cost of their further participation in the trial or the research, as a result of the loss of the double blind.

Where data processors are used, the parties will have to address the practical challenge of putting in place contractual terms which reflect the quite specific requirements of Article 28 of the GDPR. In a clinical trial context, thought will need to be given as to how this aligns with the Clinical Trial Agreement. Generally, the developing trend, both between actors in a clinical trial and in broader contexts (such as the general use of IT providers), is for standalone data processing agreements or addenda. Whilst Article 28 provides a baseline for the necessary terms, it is inevitable that, in most cases, life sciences companies will want to do some tailoring of these to take into account sector-specific issues, for example: the heightened risks around health, genetic or biometric data and the impact that this will have on desirable limitations of liability; conditions around the re-identification of pseudonymized or de-identified data; and any assistance required from the service provider regarding the collection of consents (if this is the appropriate legal basis for data processing, which will not always be the case). 

Where service providers are acting as joint controllers, an agreement corresponding with Article 26 will normally be required, and will need to deal with the apportioning of data controller responsibilities, including those around legal basis, but also the issues concerning privacy notices and data subject rights discussed above.

Finally, a common nightmare scenario for data protection and compliance officers is the personal data security breach. The correct response to a breach will in large part be determined by whether your organization is a controller, and therefore has the responsibility for reporting the breach to a supervisory authority within 72 hours and, in high risk scenarios - not uncommon with health, genetic or biometric data - reporting the breach to data subjects. If your organization is a mere processor, you do not have this responsibility, but can expect to be called upon heavily by the controller for assistance (whom you must notify about the breach "without undue delay"), and if the breach affects multiple clients for whom you provide services, dealing with a range of demanding stakeholders can be an equally large challenge. As this article demonstrates, there will also frequently be circumstances in which multiple controllers are trying to respond to the same breach.  Assuming they act as joint controllers, the parties should have previously determined (for example, in their joint controller agreement) how they will co-operate in the event of a breach, and if one party will take the lead. 

James Clark 
is Senior Associate at DLA Piper UK LLP.

[1] See "Opinion 1/2010 on the concepts of "controller" and "processor"". Article 29 Working Party. 16 February 2010

[2] The recent case of Unabhängiges Landeszentrum für Datenschutz Schleswig-Holstein v Wirtschaftsakademie Schleswig-Holstein GmbH (Case C-210/16) is significant on this point.