Controllers, processors, and everyone in between

The EDPB guidelines on the concepts of controller and processor

12.10.2020

At the start of September, the European Data Protection Board (EDPB) released new guidelines on the concepts of controller and processor under the GDPR. They replace the old Working Party Opinion on the same topic from 2010 and, as far as the definitions of “controller” and “processor” go, they are essentially identical to the old Opinion. The most interesting aspects of the new guidelines are the EDPB’s thoughts on joint controllers and on the controller-processor agreement required under Article 28 of the GDPR. There is also a nifty flow-diagram at the back of the guidelines, to help those struggling with their classification.

The guidelines are open for consultation until 19 October 2020, and so may still be tweaked as a result of stakeholder feedback.

“Controllers” and “processors”

The controller is the actor who has determined why the processing is taking place (i.e. what for, and to what end) and how this objective shall be reached (i.e. which means shall be employed to attain the objective). The processor (who must be a separate entity to the controller), processes the personal data on the controller’s behalf.

Whilst processors will often makes decisions about how processing is carried out, they should not make decisions as to the purpose. In line with the Working Party Opinion, the EDPB considers that the controller must determine the “essential means”  (those closely linked to the scope and purpose of the processing, such as what data will be processed and by whom), but the processor can determine the “non-essential means” (those which concern the practical details of implementation, such as what tools can be used).

The EDPB acknowledges that many processor offer a standardised service, but notes that the controller must be presented with a detailed description of the service and must make the final decision to actively approve the method (and be able to request changes if necessary). The processor shouldn’t be able to later change essential elements of the service without the controller’s approval.

A useful clarification in the guidelines is the EDPB’s position that individuals appointed as contractors or ‘temps’, who are acting under the direct authority of the controller, will not be separate processors but rather acting as part of the controller’s entity. This debate comes up fairly regularly in IT contracting, so it’s good to have some guidance.

As further evidence of a recent focus on ‘control’ within a group of companies, the EDPB states that “special attention” must be paid to the parties’ roles within a corporate group, and the question of whether an establishment acts as a controller or processor. This can be very difficult in practice, especially if teams are working together laterally between establishments and cross-border. It seems likely that the supervisory authorities will increasingly impose joint controller status across corporate groups (which could pose all sorts of interesting challenges when it comes to jurisdiction and the One Stop Shop.. perhaps one for another day).

Joint controllers

In interpreting the recent CJEU case law, the EDPB has developed two alternative routes to joint controllership: (1) where the processing results from “common decisions” by more than one party (i.e. acting together to make a decision); or (2) where the processing results from “converging decisions” by more than one party.

The concept of “converging decisions” is likely to be subject to the most debate (and, dare we say it, confusion). The EDPB explains the decisions can be considered as converging on purposes and means if they complement each other and are necessary for the processing to take place in such manner that they have a tangible impact on the determination of the purposes and means of the processing. An important criterion for converging decisions is whether the processing would be possible without both parties’ participation in the sense that the processing by each party is inseparable, i.e. inextricably linked. Where the parties do not have the same purpose, they can still make converging decisions if the two purposes are closely linked or complementary (e.g. if there is mutual benefit arising from the processing).

The upshot of the EDPB guidelines on this point is that there seems very little scope for the frequently used (albeit unofficial) concept of “co-controllers”. Instead, in these circumstances the parties will almost always be joint controllers making “converging decisions”.

The guidelines do acknowledge the parties can be separate controllers if they process the same personal data in a chain of operations, each having an independent purpose and independent means (i.e. A gives B data and leaves it at that). However, there is clearly a fine line here in cases where the parties have “closely linked” or “complementary” purposes.

One crucial question arises – how much difference does the designation of joint controllership make in practice? The EDPB repeats the point, made by the CJEU, that joint responsibility does not imply equal responsibility, and so presumably not equal liability either. Provided each party will only be held responsible for its own failures, it may be that joint controller status has far less impact that many have previously feared.

Article 28 terms

The guidelines contain detailed advice from the EDPB, for the first time, on the contractual terms which must be included between controllers and processors. These are mandated by Article 28 of the GDPR, and hence are often referred to as “Article 28 agreements” or “Article 28 terms”.

The EDPB is emphatic that the data processing agreement should not merely restate the provisions of Article 28; instead, it should include specific, concrete information on how each of the requirements will be met, as well as what level of security is required. For example, details of precisely how the processor will assist the controller with its obligations under the GDPR (the EDPB suggests procedures and template forms could be annexed to the agreement), and the specific protocols to follow in the event of a security breach.

Some of this detail recommended by the EDPB is only commonly seen in large outsourcing deals, where the parties spend time negotiating bespoke arrangements. It would be nice for the EDPB to acknowledge some scope for a ‘risk-based’ approach here, with the level of detail and specificity varying depending on the scale and risk profile of the data processing arrangement. For low-risk processing engagements involving only basic contact data, for example, the level of detail proposed by the EDPB seems disproportionate. Certainly, however, parties should be cautious about simply cutting and pasting ‘generic’ Article 28 language into their agreements, without giving thought to its operation in practice.