Controllers, Processors, Sub-processor, Joint Controllers, Co-controllers: so, who (or what) are you…?

Whilst the GDPR devotes two Articles to Processors, Controllers and Joint Controllers, and despite the European Data Protection Board (EDPB) having issued “Guidelines 07/2020 on the concepts of controller and processor in the GDPR”, the concept of Processors, Controllers, Sup-processors, and Co-controllers continue to be the subject of much argument.

It may be time for us to reconsider (and for the EDPB to adopt) a different naming convention. This would see us move away from the ambiguous terms of controllers and processors and adopt a clearer approach to defining the parties – for example, business and service provider, aligned on the California Consumer Privacy Act (CCPA). This would also allow us to consider widening the rules (in certain circumstances) of secondary processing by the service provider.

?

Sometimes, I wished I could rewrite privacy laws!!! (Ok, that is a megalomaniac statement to make at the start!)

In the various roles I have undertaken in my career, I have had plenty of reasons to gripe and complain about, specifically regarding the old EU Data Protection Directive and, more recently, the GDPR, in the context of customer and supplier negotiations; for example, audit rights, a consistent approach to technical and organisational measures, maximum retention periods, whose document should we use, and let us not forget, the massively contentious topic of international data transfers.

But one piece that comes up regularly - and has the immediate ability to increase my blood pressure exponentially - is the topic of who does what in the relationship – meaning, identifying who is a controller, processor, joint controller, sub-processor, and co-controller (or controller in common).

Granted, some of these (shall we call them) titles are much easier to define and identify in the relationship.

Now, before I continue, I must stress that I have had discussions with outside counsel about this piece in the past. One advised that it should not really matter what the parties are defined as, provided that (1) there is a clear contract between the parties and (2) that that contract specifies what each party does with the data (i.e., to ensure accountability, handling of data subject requests and transparency, etc.). But this is where I disagree. In my mind it is imperative that each party in the relationship, ecosystem, etc. is labelled to be able to clearly articulate what their rights, duties, and obligations are in accordance (not least) with the accountability principle of the GDPR.

?

Sub-processors…

It may be best to start with the (perhaps) least contentious party in the equation – the sub-processor. Most people would define the sub-processor as a third-party engaged by the processor to process personal data on the processor’s behalf. Although it must be said that there is no definition in the GDPR that clearly explains what a sub-processor is. In fact, the only inkling we have that there is an additional party doing something with the personal data is per Article 28(2) of GDPR.

So far, so good!

Well, not quite - because this relatively rudimentary definition of “another processor” engaged by the processor immediately butts up against the definition of processor. The processor is (per the UK Information Commissioner’s Office definition) “a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller. Processors act on behalf of the relevant controller and under their authority. In doing so, they serve the controller's interests rather than their own.”

So, what we have so far is that a sub-processor processes the personal data on behalf of the processor and the processor, in turn, processes the data on behalf of the controller. (Confused yet?)

Controllers…

Inevitably, this brings us to the controller, which – again per the ICO – “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.” (We will dissect this a little below.)

And as a final piece to this patchwork of ‘interested’ parties, we have the joint controller. We get an indication of this additional party in the definition of the controller, where the ICO uses the words “alone or jointly with others.” In addition, Article 26(1) of GDPR specifically calls out the situation “[w]here two or more controllers jointly determine the purposes and means of processing […]”.

?

Co-controllers, or controllers in common…

But wait – I know that many my call foul play on my discussion and say that I am ignoring the final culprit in this twisted saga – the co-controller or controller in common. This is where I must draw the line! There is no concept of co-controller under the GDPR (or in fact any other prominent privacy law) that I have seen (of course, I would be grateful for a specific reference if you feel otherwise). In fact, when preparing my thoughts for this discussion, I trawled the internet for a definition of co-controllers to really understand what we are dealing with and whether I was missing something. It must be said that the only real substantive position I could find is an article from LexisNexis, which defines controllers in common as a situation “where two or more persons share a pool of personal data that they process independently of each other.”

In saying this, many privacy professionals will protest that I am ignoring the (perhaps) most fundamental and definitive piece of guidance on this subject – the European Data Protection Board “Guidelines 07/2020 on the concepts of controller and processor in the GDPR”. They will point specifically to section 3.2.3, in which the Guidelines talk about “Situations where there is no joint controllership” and provide four (albeit non-exhaustive) examples. These examples, the EDPB deems to be situations that warrant several controllers, where they do not jointly determine the purposes and means of processing. I must stress at the outset that nowhere in the Guidelines does the EDPB define or explain the term co-controller or controllers in common or in any other way identify who they are (or could be).

?

Has the EDPB ruled out joint controllers under Article 26 of GDPR?

And so; this is where I begin to struggle: why? Because the grounds upon which these examples are based, can (and I would say, should) be attributed to a straightforward controller-processor relationship or are simply not true and accurate illustrations of the proposed co-controller position. How is that possible? Let us take a closer look at the examples AND the guidance given by the EDPB in the Guidelines.

Before delving further into the examples, it is critical that we keep in mind the Executive Summary on page 3 of the Guidelines, in which the EDPB states that “[a] controller determines the purposes and means of the processing, i.e., the why and how of the processing. The controller must decide on both purposes and means. However, some more practical aspects of implementation (“non-essential means”) can be left to the processor. It is not necessary that the controller actually has access to the data that is being processed to be qualified as a controller.” The reason for the emphasis I have added above will become clearer in the discussion below.

Furthermore, this section on page 3 needs to be read in conjunction with the first paragraph of section 3.2.3 of the Guidelines which states “[not] all kind of partnerships, cooperation or collaboration imply qualification of joint controllers as such qualification requires a case-by-case analysis of each processing at stake and the precise role of each entity with respect to each processing” - again my emphasis.

The Mysterious Examples Provided by the EDPB

Once we have understood these two points, we can then turn our attention to a reading of the first example at paragraph 70 - “Example: Transmission of employee data to tax authorities”. The example includes the line that “even though both the company and the tax authorities process the same data concerning salaries, the lack of jointly determined purposes and means with regard to this data processing will result in qualifying the two entities as two separate data controllers” - I would argue this is flawed! For me, but for the fact that the controller employs the employees, the controller has no obligation to report (for example) income taxes to the relevant authority.

The lawful basis of processing is clearly pursuant to Article 6(1)(c) of GDPR and there is nothing else that would impose a particular position on the parties. The EDPB gives no further indication as to why it feels that “this data processing will result in qualifying the two entities as two separate data controllers” and without this, the example contradicts the definitional pieces I flagged above about “requiring a case-by-case analysis of each processing” and “some more practical aspects of implementation (“non-essential means”) can be left to the processor.” Therefore, I wonder whether you could argue that the tax authority could, in fact, be the employer’s processor of tax-related employment data and the ‘how’ the tax authority processes the employer's data “can be left to the [tax authority]” in line with the definitional guidance at the start of section 3.2.3 of the Guidelines. In any event, the only conclusive statement the EDPB does make in this example is to say that there is a “lack of jointly determined purposes and means.” To me, the only thing the EDPB has done here (aside from starting to muddy the water) is to simply rule out joint controllers under Article 26 of GDPR – rather than justify the creation of a separate category of participant in the ecosystem.

So the conclusion as regards the example at Paragraph 70 must be that (notwithstanding the EDPB’s intervention), the controller has certain compliance with legal obligations requirements (under Article 6(1)(c)) and there is nothing noted to stop an assertion (based on the ‘but for’ position set out above) that the tax authority could (and should) be the processor of the employee tax data as provided in the employment context.

I am sorry to be quite crass, but my reading of the first example at Paragraph 71 is not even an example of joint controllers or controllers in common at all, and anyone who positions this example as such completely misunderstands the GDPR relationships! The first example at Paragraph 71 (Example: Marketing operations in a group of companies using a shared database), clearly sets out that each party using the database, uses their own data, meaning that Company A does not even access (even though it may be able to – this is unclear from the example) the data of Company B, even though they are on the same database.

The second example at paragraph 71 (Example: Independent controllers when using a shared infrastructure), again instils little to no confidence in the EDPB’s understanding of the ecosystem or of the technologies used. For me, the example also flies in the face of other requirements of the GDPR, such as purpose limitation, data minimisation and most important, data security and the integrity and confidentiality of the data. (I.e., the triad of confidentiality, integrity, and availability). In the EDPB’s second example at paragraph 71, they seem to imply that Company XYZ does not segregate the data, which in turn results in a potential personal data breach. So instead of providing clarity, the EDPB has muddied the water further!

The final example at paragraph 72 (Example: Statistical analysis for a task of public interest) is prefaced with the following statement “[also], there can be situations where various actors successively process the same personal data in a chain of operations, each of these actors having an independent purpose and independent means in their part of the chain. In the absence of joint participation in the determination of the purposes and means of the same processing operation or set of operations, joint controllership has to be excluded and the various actors must be regarded as successive independent controllers.” ?I would argue that the preface statement is simply a restatement of what it has already stated rather than providing a substantive clarification to a further example to help the discussion. The EDPB provides the example that various government authorities must report certain data they have collected to a central authority that carries out analysis of the data, suggesting that each of these separate government authorities are controllers (in their own right). Again, I would argue that the GDPR gives sufficient opportunities for the controller to allow third parties to use the data for statistical and/or analytical purposes and still maintain the controller to processor relationship.

?

Any help available from the New Standard Contractual Clauses?

So where does this leave us – well, we are still in a position that neither GDPR, nor the relevant guidance provide any comfort or certainty for the users in the ecosystem. The fact that the EDPB has issued the new Standard Contractual Clauses with Module 1 option for controller to controller transfers only serves to complicate matters further. I would argue that, in effect, the EDPB has created an additional actor by the backdoor. Furthermore, while co-controllers may be possible, it is not something contemplated by the law and therefore, should only apply in edge cases, rather than as a regular occurrence.

Controllers in their own right?

Notwithstanding this unclear position, there are many industries (for example, insurance, benefits, and pensions) where the providers allege that they are controllers in their own right. Considering the above analysis and conclusions, I perceive there is a flaw here, especially when dealing in the B2B context. (The B2C context is different because the providers have a direct selling/contractual relationship with the consumer.)

Let us remind ourselves of the definitions:

Processor – “a natural or legal person, public authority, agency, or other body which processes personal data on behalf of the controller. Processors act on behalf of the relevant controller and under their authority. In doing so, they serve the controller's interests rather than their own.”

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.”

And the EDPB Guidelines, which state that need for “a case-by-case analysis of each processing” and that “some more practical aspects of implementation […] can be left to the processor.”

In this context, we must carry out a case-by-case analysis of the processing to understand the basis upon which the provider (let us say a benefits or pensions broker) gets access to the employee data (for example) to make available to the employer quotes for and provide disability benefits to the employees. The relationship is purely and only by virtue of the purchase and service contract between the employer and the broker and, by implication, any data that flows from the employer to the broker is transferred to enable the provision of the contracted services.

To argue, like many brokers do (in this scenario) that they are a controller ignores a fundamental part of the definition of controller – that being that the controller “determines the purposes and means of the processing of personal data” – and the definition of processor – that being “processors act on behalf of the relevant controller and under their authority [… and] they serve the controller's interests rather than their own.” While, I admit, that a broker does not provide their service voluntarily but for a fee, I will go back to the position above of the but for test - I.e., but for the service and purchase contract concluded between the broker and the employer, the broker would not have been given access to the employee data. To put a finer point on this – the service and purchase contract between the employer and the broker is the instruction to process the data by the employer to the broker; this instruction reflects the employer’s interest to offer certain minimum benefits to the employees.

Some might argue that I am ignoring the situation that happens so often, where the employees send data directly to the broker – for example, claim-related data is sent directly back and forth between the employee and the broker, with little to no involvement by the employer. To this I would say that even here the EDPB Guidelines are clear in stating that “[it] is not necessary that the controller actually has access to the data that is being processed to be qualified as a controller.” The case here is that it is not necessary for the employer to have access to all the employee data (in this case, the claim-related data) for the employer to remain a controller. Therefore, for the broker to argue that they are a controller is simply their own convenient construct that is not backed up (per the above analysis) nor is it conducive to the transparency required towards the data subject. On a personal level, I have yet to come across a cogent argument that explains why the broker actually needs this data as a controller – other than to increase its own data lakes.

So where does this leave us?

In my view, there are a several pieces to this discussion that require careful attention:

·??????First, and foremost, it would be welcome for the EDPB to modify the “Guidelines 07/2020 on the concepts of controller and processor in the GDPR”. Either expressly embrace and clearly define the concept of co-controller or controller in common OR dismiss it outright as a concept that applies. While there is sufficient leeway in the definitions of controller and processor to cater for all participants in the ecosystem, the explicit lack of guidance or specific legal language in the GDPR does not help anyone.

·??????Alternatively, it may be time for us to reconsider (and for the EDPB to adopt) a different naming convention that would actually be aligned with the one used under the CCPA. This would see us move away from the ambiguous terms of controllers and processors and adopt a clearer approach to defining the parties – for example, business and service provider. This would also allow us to consider widening the rules (in certain circumstances) of secondary processing by the service provider;

·??????Separately – and this depends greatly on the position the EDPB takes in the two points above – the parties in the ecosystem should stop trying to bend the rules to allow them access to greater amounts of data and instead focus on the key concepts of the GDPR – accountability, transparency and most importantly, the rights and freedoms of the data subjects;

·??????Finally, as alluded to in the second bullet above, I wonder whether we should also take this opportunity to get a better understanding of secondary processing and put in place some clear rules on when and how it is acceptable – again for the sake of transparency and to honour the rights and freedoms of the data subjects.