NEW EDPB GUIDELINES ON THE CONCEPTS OF CONTROLLER AND PROCESSOR - SEVEN PRACTICAL TAKEAWAYS

More than two years after the GDPR came into force, the European Data Protection Board (the “EDPB”) finally published its long-awaited draft guidelines on the concepts of controller and processor on 7 September 2020.

Prior to this date, UK organisations only had the relatively limited guidance set out on the ICO website and the old Article 29 Working Party guidance, which predated the implementation of the GDPR, to go on when attempting to apply these fundamental concepts to real-world scenarios.

The new draft guidelines, which are open for public consultation until 19 October 2020, are split into two parts:

• Part I addresses the concepts of controller, joint controller, processor and third party/recipient and the scenarios in which these roles should be allocated to parties that are involved in the processing of personal data; and
• Part II sets out details of the measures that need to be put in place when controller-processor and joint controller relationships arise, providing detailed commentary in relation to the contents of a valid data processing agreement entered into between a controller and processor (“DPA”) and joint controller arrangement.

While the contents of the new draft guidelines largely confirm our existing understanding of these concepts and measures, they do contain some helpful sections which serve to offer clarification in relation to a number of issues that have arisen since the implementation of the GDPR. Other sections, however, arguably serve to complicate certain issues further and it is fair to say that many practical questions that organisations and practitioners have, are likely to remain unanswered.

Taking the positive from the draft guidelines however, we set out below seven practical takeaways for organisations looking to navigate to challenges of these concepts.

1. An organisation does not need to have access to or receive personal data to be deemed a controller

If an organisation instructs another party to carry out processing of personal data, or otherwise has processing carried out on its behalf, the organisation can be deemed a controller without ever having access to or receiving personal data.

This guidance confirms that an organisation that provides detailed instructions to a service provider to process personal data on its behalf (e.g. to conduct market research), but only ever receives statistical output information from that service provider in return will not be excused from having to comply with its obligations under the GDPR as a controller simply because it never sees any personal data.

Although not explicitly addressed, it would seem unlikely when this situation arises that contractual provisions would be sufficient to rebut this assumption. For example, we consider it unlikely that a provision in the contract between an organisation and a processor service provider, expressly prohibiting the service provider from providing the personal data to the counterparty organisation, would be sufficient to avoid the organisation being deemed a controller.

2. A service provider can be a processor even if the main object of the service is not the processing of personal data (but not if it only processes personal data on an incidental basis)

If a service provider provides a service where the main object of that service is not the processing of personal data, but has routine or systematic access to personal data, it will be deemed to be a processor. Conversely, a service provider will not be deemed to be a processor if it only comes across very limited quantities of personal data on an incidental basis.

This guidance clarifies that a service provider such as an IT helpdesk service that routinely accesses personal data (e.g. by liaising directly with a customer’s employees or by screen sharing) will deemed to be a processor even if this is not the main object of its role but another service provider, which has, for example, been instructed to fix a specific software bug and will not have the same level of access to personal data (but might see some inadvertently), will not be deemed to be a processor.

3. A service provider that processes personal data for its own purposes will be deemed a controller in respect of those activities

If a service provider carries out processing of personal data for and on behalf of a customer in accordance with the customer’s instructions, it will be deemed a processor in respect of these processing activities. However, if the service provider also processes personal data for its own purposes in the course of carrying out these services (e.g. to conduct data analytics to assist with improving its services for the benefit of its entire customer base), it will be deemed to be a controller in relation to these processing activities, even if it remains a processor for the majority of the processing activities that it carries out for its customer.

This means that the service provider will need to find a way of complying with its obligations under the GDPR as a controller in respect of these processing activities, including the transparency requirements, and it should also make the extent of these activities clear to its customer in any services agreement.

This guidance also reinforces the idea that a service provider is unlikely to solely act as a processor in relation to all processing activities that it carries out in the context of providing services to a customer and is instead likely to act as a mixture of processor, controller and potentially joint controller in respect of the different processing activities that it carries out under these arrangements. This is something that we regularly see reflected in commercial agreements, although the defining lines between the roles that a party may have are often more difficult to discern.

4. Controllers and processors are equally responsible for putting a DPA in place which meets the requirements of Article 28 of the GDPR

Though the wording of Article 28 does not make it entirely clear as to whether it is the responsibility of: (i) the controller; or (ii) both the controller and processor, to put a DPA in place containing Article 28 compliant provisions, it has traditionally been the controller rather than the processor which has taken it upon itself to ensure that the provisions in the DPA are sufficiently robust and detailed so as to meet this requirement. This is possibly a hangover from the Directive and the Data Protection Act 1998.

The guidelines confirm, however, that fulfilling this obligation is the responsibility of both controller and processor and emphasise that processors are also open to receiving administrative fines under the GDPR, which means that processors need to be equally as proactive and engaged as controllers in relation to ensuring these requirements are met.

5. It is not sufficient for a DPA to merely restate the provisions of Article 28

In the absence of a standard set of regulator-sanctioned DPA clauses, controllers and processors have had to exercise their discretion when determining what to set out in a DPA in order to meet the requirements of Article 28 of the GDPR. Typically, parties tend to set out detailed provisions in a DPA if the processing activities to be undertaken are extensive and/or high-risk, whereas if the processing activities are to be minimal or routine, it is not uncommon to see “light touch” DPA wording which simply cross refers to or incorporates by reference certain elements of Article 28 without any additional detail (e.g. in relation to security, “the processor shall take all measures required under Article 32 of the GDPR”).

The guidelines now make clear that merely restating the requirements Article 28 GDPR is never sufficient or appropriate when drafting a DPA: details of the procedures that processor will follow to assist the controller with meeting the listed obligations under Article 28 of the GDPR (e.g. in relation to personal data breach reporting and adopting adequate technical and organisational measures to ensure the security of processing) will need to be set out, potentially in annexes to the DPA. For many organisations that have spent considerable time and resources repapering their commercial agreements to include Article 28 wording, this push for additional detail which may not already be included in many organisations’ DPAs is unlikely to be welcomed given the time often already required to negotiate the provisions of a DPA with counterparties.

6. A controller-processor relationship will only arise where a processor is a separate legal entity in relation to the controller

The guidelines clarify that a department within a company cannot generally be a processor to another department within the same entity and so it will not be necessary to put a DPA in place when this situation arises.

Although the guidelines do not explicitly address whether this principle also applies to a branch and a head office, it follows that it may also not be necessary to put a DPA in place if one were to process personal data for the other.

7. Attributing the roles of controller, processor and joint controller to parties involved in less straightforward processing relationships will remain a challenging exercise

The guidelines set out a number of new tests to help with applying the concepts of controller, processor and joint controller in practice.

For example, the guidelines state that a party will be deemed to be a controller if exercises a “determinative influence” in respect of the processing and if it determines the “essential means” of processing such as making fundamental decisions with regards to the type of data to be processed, the duration of the processing, the categories of recipients and the categories of data subjects. Conversely, if a party only determines the “non-essential means” of the processing, which might include considerations such as choice of hardware or software to be used, it will be deemed to be a processor.

The guidelines also provide that a joint controller relationship will arise where more than one party holds “decisive influence” in respect of the processing either by making a “common decision” or “converging decisions”, where the processing would not be possible without both parties’ participation and where both parties’ processing activities are inseparable or inextricably linked.

While these new tests are welcome insofar that they serve to flesh out the existing guidance available, they do not make the task of attributing the roles of controller, processor and joint controller to parties involved in complex processing arrangements any easier. In particular, the guidelines do not appear to add much clarity with respect to the concept of joint controllers and when such a relationship will arise. Market practice since implementation of the GDPR has seemed to shy away from parties considering themselves to be joint controllers and the draft guidelines do little to clarify whether such practice is sustainable or not. Arguably, these tests will only serve to complicate matters further by requiring additional layers of analysis to be carried out at the outset of every matter involving the processing of personal data. They also offer no guidance on what to do in circumstances where the contractual parties disagree on the analysis – a situation which is potentially only likely to become more common.