This is the first in a series of posts that discuss the key concepts and issues addressed in a set of draft guidelines recently issued by the European Data Protection Board (“EDPB”).  Comments on the draft guidelines are due by 19 October 2020.

Part 1: Focus on Processors

On 7 September 2020, the EDPB published the draft “Guidelines 07/2020 on the concepts of controller and processor in the GDPR.” Businesses and members of the public may provide feedback on the draft Guidelines by 19 October 2020.

One of the baseline issues that must be considered when assessing the obligations and potential liabilities of an organisation that is subject to the GDPR when it collects and processes personal data is whether the organisation should be classified as a data controller or a data processor, as defined in the GDPR.  This is not a new issue, since these terms were originally introduced in the 1995 EU General Data Protection Directive and the definitions were not changed significantly by the GDPR.  Determining whether an organisation is acting as a controller or processor is often not straightforward as the dividing line between these concepts is not always clear.

This post provides an overview of the updated guidance on the concept of data processor.  Subsequent posts will deal with the concepts of data controller and joint controllers.

What is New in the Draft Guidelines Regarding the Role of Data Processors?

In general, the basic principles underlying the concepts of controller, joint controller and processor remain the same as in previous guidance, “Opinion 1/2010 on the concepts of controller and processor,” issued in February 2010 by the Article 29 Working Party (the predecessor of the EDPB).

Pertinent considerations around the role of data processors include the following.

How to determine if an organisation is a processor?

The EDPB provides some helpful tips for evaluating whether an organisation should be classified as a data processor. Despite the updated guidance, the assessment remains a complex exercise when considering real-world activities.

The EDPB reminds us that the determination of the role of a controller and processor may stem from legal provisions, where the law either directly identifies the controller and in some cases the processor(s) (for example, as has been the case recently for organisations participating in government instituted contact-tracing apps in the context of the COVID-19 pandemic), or by the allocation of specific tasks to an organisation that implies controllership.

The EDPB emphasises, however, that in most cases the determination of the roles is based on activities and functions in a specific scenario rather than a formal designation of either party as a controller or processor. Not every service provider is a processor.  The role of a processor does not stem from an organisation’s business, for example as a cloud provider, but rather from its processing activities in a specific context.  As the Guidelines indicate: “a case-by-case analysis remains necessary… in order to ascertain the degree of influence each entity effectively has in determining the purposes and means of the processing.”  The terms of a contract may assist in such determination but cannot be shaped to artificially assign the role of processor or controller.

The processor to act on behalf of the controller

The draft Guidelines reiterate the two basic conditions for the role of processor: (a) it is a separate entity in relation to the controller; and (b) it processes personal data on the controller’s behalf. One example of separate entities would be two companies within a group of companies. Note that a particular department within a company would not be considered a separate entity and so would generally not be classified as a processor to another department within that same company. Similarly, if a controller decides to process data using its own resources (for example, employees) those employees are not processors. This is because the processing is within the same entity (and so does not amount to a separate processor relationship). The Guidelines also clarify that temporary staff in the same position as permanent staff would not be considered processors.

A processor must implement instructions given by the controller, which at the very least set out the purpose of the processing and essential elements of the means of processing. This does not mean that the controller’s instructions cannot leave any scope for the processor to make decisions. The Guidelines specifically state that instructions “may still leave [the processor] a certain degree of discretion about how to best serve the controller’s interests”. The controller decides on what EDPB refers to as the “essential means”, i.e. decisions as to “which data shall be processed”, “whose personal data are being processed”, “who shall have access to this data”, and“when data shall data be deleted”. This leaves the processor with so-called “non-essential means,” which concern the “more practical aspects of implementation” of a processing activity — for example, choice of a particular hardware or software, or specific security measures.

A thin line to cross to be classified as controller

Where a processor goes beyond the controller’s instructions, it will be considered a controller for the relevant activity. This is often disregarded by processors when they decide to use personal data for their own purposes, such as developing their own business activity or for R&D purposes. In this case, the organisation may be “subject to sanction for going beyond the controller’s instructions”.

Moreover, the “same entity may act at the same time as controller for certain processing operations and as processor for others”. An assessment has to be made “with regard to each specific data processing activity”. It will be important to document and deal with this in the agreement between the processor and the controller by way of incorporating controller clauses in addition to processor clauses.

Standalone obligations of a processor

One of the important innovations of the General Data Protection Regulation (“GDPR”) is to impose a number of obligations and responsibilities directly on the processor. This includes the obligations to ensure the confidentiality of personal data, implement appropriate technical and organisational security measures, maintain a record of processing activities, and implement adequate safeguards in the case of international transfers, etc.

Contractual arrangement with a controller

The EDPB observes that “Article 28(3) GDPR imposes direct obligations on processors, including the duty to assist the controller in ensuring compliance“. However, the EDPB clarifies that the “duty of assistance does not consist in a shift of responsibility”.

The EDPB emphasises that it is the obligation of both controller and processor to have a contract in place that is compliant with the GDPR. Therefore, if a processor is subject to the GDPR, it will need to ensure it has included the required GDPR clauses in its contracts with controllers. Standard Contractual Clauses approved by supervisory authorities for use by processors to comply with Article 28 of the GDPR (not to be confused with SCCs for international transfers of data) can also be used, but the EDPB does not view that as the preferred option. The EDPB stresses that processing agreements between controllers and processors should be specific and have concrete information on how the Article 28 requirements will be met, and not simply re-state the provisions of the GDPR.

The draft Guidelines provide an interpretation of the content of Article 28(3) GDPR, including the following noteworthy points:

• It is important for the processor to obtain documented (written) instructions from the controller. In practice, a processor will not always find these easy to obtain.

• Instructions also should cover international transfers. If the instructions by the controller do not allow for transfers, “the processor will not be allowed to assign the processing to a sub-processor in a third country, nor will he be allowed to have the data processed in one of his non-EU divisions”. If the instructions allow for transfers, the agreement must include a provision regarding the way to best provide for the GDPR-required safeguards .This obligation has to be read in the light of the recent Schrems II decision (for more information see our blog here).

• In the case where an EU or Member State law applicable to the processor requires it to process data otherwise than as instructed by the controller, the processor must inform the controller before starting the processing.

• The contractual agreement between the controller and processor should contain details as to how the processor is asked to help the controller meet its obligations under Articles 32 to 36 GDPR (for example, by procedures and template forms added in the annexes).

• As regards the clause relating to notification of any data breaches by the processor to the controller, “the EDPB recommends that there is a specific time frame of notification (e.g. number of hours) and the point of contact for such notifications be provided in the contract”.

• On the obligation to provide the controller with all information necessary to demonstrate compliance , this includes “all information on how the processing activity will be carried out on behalf of the controller”, for example, “information on the functioning of the systems used, security measures, retention of data, data location, transfers of data, access to data and recipients of data, sub-processors used, etc.” and, possibly, sharing the relevant portions of the processor’s records of processing activities.

• On audits, “the parties should cooperate in good faith and assess whether and when there is a need to perform audits on the processor’s premises”, which seems to imply that on-site audits can be avoided in some cases.

• Any changes to the contractual terms or to security measures must be approved by the controller, meaning that processors cannot simply publish changes to the relevant terms online.

• The EDPB clarifies that the contract must be signed by the parties. This means that white papers and data protection policies presented by processors cannot be considered sufficient to meet the requirements of Article 28 GDPR, unless they are incorporated as part of a contractual agreement executed by both parties.

• Large processors that offer an off-the-shelf service will need to actively involve controllers to obtain approvals for decision-making at various stages in order to comply with the GDPR and remain classified as processors

Responsibility for sub-processors

The EDPB recognises that chains of subcontracting are becoming increasingly complex. The draft Guidelines reiterate that the processor is “fully” liable to the controller for other processors’ (“sub-processors”) compliance with data protection obligations contained in the contract with the controller. The appointment of any sub-processor must be authorised by the controller beforehand and the EDPB offers an interpretation if there is a lack of response by the controller, depending on whether the authorisation is specific or general. The draft Guidelines, however, do not provide what the consequence of a lack of authorisation can be in practice (for example, change to another sub-processor, change of the content of the service, or termination of contract).  Processors are reminded of their obligation to flow down (in a “functional way”) their obligations to their sub-processor and are encouraged to inspect compliance by other processors with the data protection obligations flowed down to those parties.

How can issues faced by organisations regarding their role be resolved? 

Some organisations tend to adopt whatever role is prescribed to them by clients or service providers, which may sometimes result in their assuming different roles in relation to the same processing. These types of difficulties arise particularly in cases where a number of parties are involved in the provision of a service. This raises a question as to the apportionment of data protection responsibilities and liabilities between all parties.

The risk of not addressing the issue may lead to organisations taking on disproportionate levels of responsibility and liability risk from the data protection perspective than is reasonable, thereby exposing themselves to increased regulatory risk and the risk of claims from data subjects or third parties.  In addition, where many participants are involved in the supply chain, questions may arise as to the lawfulness of the processing and the risk to data subjects’ rights and freedoms, and indeed the exercise of rights afforded them by the GDPR.

It is important for organisations to document the reasoning behind their role as processor in relation to specific services or the processing of personal data. This does not need to be a lengthy document, but may come in handy when negotiating data protection clauses in contracts and also in the case of mergers and acquisitions. You can build these arguments based on the updated draft Guidelines once these are finalised.

Once the role of processor has been established, organisations should carefully prepare their standard processing agreement under Article 28 GDPR and tailor it on a case-by-case basis to meet the needs and instructions of the controller.

Lucia Hartnett contributed to this article.