Under the General Data Protection Regulation (GDPR), any person (including organisations) handling personal data is subject to a different level of obligations and responsibilities with regard to the personal data processing operations they carry out depending on whether they are acting as a processor, a controller or a joint controller.
Indeed, their GDPR obligations and responsibilities stem from their role in the processing operations at stake. In broad words, controllers bear most responsibilities while processors must only act under the instructions of the controller and therefore, bear much less responsibility on their shoulders.
Where more than one party are involved in the same or a set of personal data processing operations, the first question to answer is: are they acting as a controller or a processor?
Answering this question will help draft the data protection agreement/clauses and assign the relevant GDPR obligations to either of the parties involved in the processing operations. It will also be the first question any authority or judge will answer before issuing a fine or awarding indemnity.
The European Data Protection Board has updated its guidelines (July 2021) on how to determine whether a stakeholder is acting as a processor, controller or a joint-controller taking into consideration the recent judgements of the European court of justice. However, these guidelines may be confusing to any new comers.
The purpose of this article is to explain the reason why it is important to determine the role of each party to personal data processing operations and provide some examples and possible ways to handle complex situations.
1. Why is it important to determine whether one’s is acting as a controller or a processor?
Determining the role of each party involved in a set of data processing operations is crucial as their responsibilities are different depending on their role.
1.1. Controllers are legally responsible for the compliance of their processing operations with the GDPR and are liable to the individuals and to the authorities who can audit and sanction them if they breach the regulation (see controller’s obligations here).
1.2. Processors’ legal obligations and responsibilities are limited (e.g. security: see article here) and for this reason, controllers and processors have a legal obligation to enter into a contract to ensure the processor does not put their controller at risk of a GDPR breach. However, where a processor breaches one of its few legal obligations (as opposed to the contractual ones), it remains liable to the authorities and the data subjects.
2. What do “processing”, “controller” and “processor” mean?
2.1. The controller determines the purposes and the (essential) means of processing and may act alone or jointly with others.
In other words, it makes all the important decisions regarding the processing operations.
2.2. The processor is a third party acting only on the controller’s behalf and following its instructions unless otherwise required to do so under Union or Member States law.
2.3. Processing is, under the GDPR, any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction;
Given the rise in complexity of certain services, it is not always easy to make a distinction between controller and processor in practice.
3. How to determine whether a data recipient is a controller or a processor?
Where a company acts alone, it is a controller (e.g. a company running its online business and hosting its website) and, there is no processor.
However, when the controller shares its personal data with a third party, the latter may be acting as an independent controller, a joint-controller or a processor.
Given the infinite number of possible situations, providing an exhaustive analysis has proved impossible. Therefore, the examples provided below aims to provide a high-level view of the possible ways to deal with various kind of data-processing situations.
3.1. Controller to Processor
As explained above, a data recipient is a processor when it only acts on instruction of the controller.
In practice, it means that the recipient does not use the personal data for its own benefit/purpose and does not decide either the purpose or the essential means of processing. In other word, it should not decide anything that is closely linked to the purpose of the processing operation (e.g. type of data, data retention period, categories of data subjects, other data recipients etc.). However, it can decide for the type of software to be used or the specific security measures to be implemented (“non essential means of processing”).
For example, Company A runs its online business and decides to outsource the storage of its customers’ data to Company B.
In this example, A is a controller and B a processor as the latter is only acting on A’s instructions and will not use the data for its own purposes (i.e. it is A’s subcontractor).
The parties must enter into a data processing agreement in compliance with article 28 GDPR setting out the provisions that a controller to processor agreement must contain.
3.2. Independent Controllers
Independent controllers situation happens when a controller share the personal data it holds for its own purpose to a third party for the latter’s purposes. In this case, the first controller does not decide the purpose and the means of the processing operations carried out by the recipient. It only agree to share its data for any or certain specific purposes.
For example, company A has agreed to sell a copy of its customer database to Company C for C’s direct marketing activities.
Once the copy of the data provided to C, A will not hold any role in or benefit from C’s direct marketing campaign. It will not either decide how the data will be sent, when etc.
In this case, both parties act as a separate controller of their processing activities and remain independent from each other.
A contract is not legally required but very much recommended as C would need A to obtain individuals’ consent to marketing email beforehand.
Another clearer example is, when a company must send HR data to governmental agency such as Tax agency etc. This is required by law and the governmental agency decides for the means and the purpose of processing alone. As a result, it is a sole controller.
Joint-controller relationships are complicated to define and the reader will have to be very flexible in its approach as to what joint-controller is or may be. Indeed, the EDPB guidelines and the court decision may appear difficult to understand as they aim to adapt to a wide range of situation.
According to the EDPB guidelines, very much inspired from the ECJ, Fashion ID case (see here), and the GDPR, there is a joint-controllership when at least two parties determine jointly the purpose and the means of a processing activity. It entails that more than one entity have a decisive influence over whether and how the processing operation takes place.
It may result from common decisions (i.e. they decide together) or from converging decisions (i.e. each party’s decisions complement each other, are necessary for the processing operation to take place and have a tangible impact on the determination of the purposes and means of the processing operation. These decisions are inextricably linked and without both partie’s participation, the processing operation cannot take place).
Regarding the determination of the purposes of the processing operations, the parties may not pursue the exact same purposes, these purposes need only to be closely linked or complementary. It may be the case where they both benefits from the processing operations of which they both determine the purposes and the means. (see ECJ Fashion ID decision here regarding the Facebook Like Button).
Regarding the determination of the means of the processing operations, it is not either necessary that each stakeholder determines all the means. The mere decision to use the means or making available the data through standardised means of processing (e.g. platform, embedding a Facebook like button on its facebook page etc.), may be sufficient.
Furthermore, it is not necessary for both parties to access the personal data as long as they were involved in the determination of the means and purposes of the processing operations (e.g., the Jehovah’s witnesses community does not access data collected by its members in the context of door-to-door preaching).
Joint-controllership does not necessarily entails equal responsibility. Indeed, stakeholders may be involved at different stages and to different degrees. However, one of the entities cannot be considered to be a controller, in the context of operations that precede or are subsequent in the overall chain of processing for which that person does not determine either the purposes or the means (without prejudice to any civil liability provided for in national law).
Besides, being joint-controllers involves, in particular, allocating each parties’ GDPR obligations in a written agreement (e.g. security, informing data subjects, handling individuals’ right requests etc.) that should be made available on request.
Although this contract does not bind third parties, it will help determine each parties’ responsibilities in case of GDPR breach.
Example 1: basic example of joint-controllership
A and C have decided to promote a product in partnership via a direct marketing campaign. Both parties provide their customers’ email address to a third pary in charge of the emailing.
The purpose of the emailing campaign (i.e. the processing operations) is to promote both companies’ product. They appointed together a third-party provider to do so.
The third party is a processor as it is only acting on behalf of both companies. However, Companies A and C are acting as joint controllers of the emailing campaign as they decided together the purposes (promoting their product) and the means (emailing campaign via the third party provider).
Example 2: Fashion ID case (Facebook Button Like Button)
Even though there is already an article dedicated to this case (here), this European Court of Justice (ECJ) decision may be the perfect illustration of the approach to Court and very likely the Authorities, want operator to follow when it comes to ambiguous situation.
In this case, the website operator, Fashion ID, had embedded the Facebook like button on its website. This action entailed that Facebook could collect personal data relating to the Fahsion ID website regardless of whether they were Facebook users or not or had clicked on the FB Like button.
The embedding of the FB Like Button allowed Fashion ID to optimise the publicity of its goods by making them more visible on the social network Facebook when a visitor to its website clicks on that button.
Regarding the determination of the purposes, the Court considered that the implied purpose for which Fashion ID consented to embedding the FB Like Button, and as a result, to the collection and disclosure by transmission of the personal data of its website visitors to Facebook Ireland, was to benefit from the commercial advantage consisting in increased publicity for its goods. Besides, these processing operations are also carried out in the economic interest of Facebook Ireland who uses the data for its own commercial purposes.
Regarding the determination of the means of processing, the Court considered that Fashion ID was fully aware that the FB Like Button served as a tool for hte collection and transmission of the personal data of its website visitors and by embedding the plugin, exerted a decisive influence over the collection and transmission of the personald ata to Facebook, which could not have occurred without Fashion ID action.
However, it also considered it was impossible for Fashion ID to determine the purposes and means of subsequent operations involving the processing of personal data carried out by Facebook after their transmission to the latter.
As a result, it considered that Fashion ID was acting as a joint controller but only with regard to the collection and transmission of the personal data to Facebook through the Like Button it had embedded on its website. Facebook remained sole controller of the subsequent processing operations.
The Court chose to take a very analytical approach in that case insofar as for a set/chain of processing operations carried out for a same purpose, Fashion ID was only responsible for the processing operation over which it could really exert a control (i.e. determine the purposes and the means).
4. What if the data recipient acts both as a controller and a processor of the same set of personal data?
Given the rise of multi-service providers, it often happens that a third-party recipient processes the same set of personal data for different reasons. However, it becomes tricky when this third-party is acting as a controller and a processor depending on the processing operation it is carrying out as part of the services it provides.
Unfortunately, there is no perfect and universal answer to these situations given their complexity and the lack of clarity of the GDPR and the Authorities’ position in this respect. Indeed, the EDPB guidelines never states clearly how to handle it, especially when a processor turns into a controller of the same set of personal data as part of the services it provides.
Therefore, the parties should carry out a detailed analysis and adapt their contract on a case-by-case basis depending on the processing operations at stake and each parties’ GDPR obligations and responsibilities resulting from thereof.
The example provided below aims to show one of the possible approaches the parties may follow to mitigate the risk and avoid the inconsistencies arising out of this kind of situation.
For example, A asks B to host its customers’ database and allows the latter to carry out analytics researches. A will benefits from the analtycis research to better target its customers and B will also use the analytics to improve its marketing analitycs research and provides better market data to its other clients.
The role of each party for each of the processing operations/purposes should be as follows:
- Hosting: B is a processor and A a controller, as B performs the services on A’s behalf.
- Analytics: B performs the service and both parties benefit from it. They are joint-controllers to some extent, (see Fashion ID example above)
The problem that such a situation raises is that B will breach its processor contractual and legal obligations as soon as it will perform the Analytics activities as a controller.
Indeed, If we take each processing operations separately, B must act only on A’s instructions when hosting A’s personal data. However, it will breach these instructions (i.e. only storing the data) when using this same data set for its analytics researches.
To avoid contradictions in B’s various obligations, B should, in this case, be regarded as a controller as its controller’s activities (i.e. analytics ) prevails on its processor activities (i.e. hosting service).
In this regard, the parties should allocate in details their respective GDPR obligations and liabilities in their data processing agreement (e.g. security, information notice, retention period, authorised use of personal data, data breach notification etc.).
However, considering B as a controller does not mean that the agreement may not contain processor-like obligations and that B is allowed to do whatever it wants with the data. As A remains responsible for the GDPR compliance of most of the processing operations and B must leave the personal data available to A as part of its hosting service.
If you need any help with your Data Protection Agreement or Determining your GDPR responsibilities, you can contact Arnaud Blanc, French Lawyer and Privacy Expert.