Where more than one party is involved in personal data processing operations, the first and most important question to answer is: are they acting as a controller or a processor?
Indeed, depending on the role of the parties (i.e. controller or processor), their obligations and responsibilities with regard to the processing of personal data will greatly differ.
The European General Data Protection Regulation (GDPR) provides for three kind of relationship between parties involved in data processing operations:
Controller to Processor
Controller to Controller
Because of the rise of multi-services providers, it has become more and more difficult to determine the role of each party involved in personal data processing activities. Indeed, where a third party is allowed to use a set of personal data to provide a wide range of different services, it may be considered as a controller for one service and a processor for another one. This situation may be confusing and professionals have different approaches as to how to handle this kind of situation.
The aim 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 to help understand the reasoning when it comes to complex services.
1. Why is it so important to determine whether one’s is acting as a controller or a processor?
Determining the role of each party to data processing activities is crucial as each party’s responsibilities in case of breach of the GDPR will differ depending on their role.
1.1. Controllers bear most of the responsibilities under the GDPR. A controller is responsible vis-à-vis individuals (i.e. data subjects) whose data is processed and vis-à-vis the authorities who can audit and sanction it if it breaches the regulation (see data controller’s obligations here)
2.2. Processors’ legal obligations and responsibilities are limited (e.g. security; see article here) and therefore both controller and processor have a legal obligation to enter into a contract to ensure processor does not put controller at risk of a breach of the GDPR. However, to the extent processor breach one of its legal obligations, it is also responsible vis à vis the authorities and data subjects.
2. What do “controller” and “processor” mean?
In broad words, the controller is the one in control of the data and makes all the important decisions with regard to the processing operations while the processor is a contractor acting on controller’s behalf and following its instructions.
According to the GDPR, a controller is “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; (…)”
A processor is “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”;
“The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller unless required to do so by Union or Member State law.” (art 29)
In practice, it is not always easy to make a distinction between controller and processor due to the complexity of the services provided.
3. How to determine whether a third party recipient is a controller or a processor?
Where a company acts alone without any third party being involved in its processing activities, it should be the only controller (e.g. a company running its own online business and hosting its website). In this case, there is no data processor.
However, when a third party is involved in the company’s data processing activities, it may be acting as a separate controller, joint-controller or processor (see examples below).
Example 1: Controller to Processor relationship
Company A runs its online business through its website. Customers’ personal data collected through the website is stored by a company B which is only allowed to host the data.
In this case, A is controller and B processor of the processing operations as it is only acting on A’s instructions and will not use the data for its own purposes (i.e. it is A’s subcontractor).
Example 2: Controller to Controller relationship
The same company A has decided to sell a copy of its customer database to Company C for its direct marketing activities.
Once the transaction is agreed, the data will be transferred from A to C and A will not be involved or benefit from C’s direct marketing campaign.
In this case, both parties act as a separate controller of their own processing activities and remain independent from each other. It is a controller-to-controller relationship.
Example 3: Joint Controllers relationship
A and C decide to enter into a partnership and promote a product.
They set up a common website, with a common customer database, they are both involved in the provision of the services. C will be in charge of setting up the website, A of hosting the database and sending direct marketing on behalf of both A and C.
In this case, A and C are joint controllers. This means they have data processing activities in common and they should enter into a contract to agree which of them is in charge of each of the data protection obligation provided for in the GDPR (e.g. security, information of data subject, handling request etc.)
4.What if the same set of personal data is used for different processing operations by the data recipient?
A more complex and nonetheless common situation is where the same set of personal data is processed for different purposes by a third party that could be considered as a controller, joint controller or processor if each processing operations were taken separately into consideration.
For example, the case where A asks B to host its customers’ database and allows B to use it for its own direct marketing purpose. They also agree that B will perform profiling processing and share the outcome with A so that A and B can better target their customers when they send direct marketing to their customers.
First step: working out the role of each party per purpose/service provided
In so far as the same set of personal data is used to fulfil the aforementioned purposes, the role of each party for each processing purpose would be as follows:
- Hosting: B is a data processor of A as it is performed on A instruction
- Direct marketing: each party is independent, A and B are “independent” controller for this purpose
- Profiling: it’s about common means and purposes and therefore both parties should be considered joint-controller.
It is particularly important to be aware of the role of each party per purpose of processing operations to draft a contract (see below).
Some data protection specialists will use a controller to processor clause and maybe a controller/joint clause in order to cover each of the purposes set out above regardless of the fact that it is the same set of data.
However, this approach may be unsatisfying because of the contradictions in the third party’s obligations (e.g. the recipient would breach its processor’s obligations to act on instruction when using the data as a controller or could not delete the personal data when requested as it would need for its own purpose etc.)
Second step: taking in consideration each processing purpose as a whole
Being both a controller and a processor of the same set of personal data may result in inconsistencies as to the obligations of the third party recipient.
In the previous example, B must act only on A’s instruction when hosting personal data. However, when using the same set of data for profiling and direct marketing purposes, it is not following A’s instructions but its own. It could, therefore, be considered in breach of its processor’s obligation.
In practice, a controller is the one responsible for any necessary personal data breach notification. If a personal data breach were to occur in B’s servers, which of A or B would have to notify the authority and if necessary the data subjects? Both parties being the controller of the same set of data for different purposes, it would be difficult to argue that only A is responsible for such notification if the breach occurred in B’s server.
Third-party recipient’s role in a data protection agreement should be the one that is closer to the dominant processing operations/main reason for contracting with this third party.
Therefore, when it comes to determining the role of a third party providing several services using the same set of personal data, it is easier to take all the data processing purposes as a whole and decide which is the dominant purpose that best reflects the relationship between both parties.
In our example, B carries out profiling activities and direct marketing for its own purposes and host data on A’s behalf. When taking the big picture, hosting the data is also necessary to the processing operation carried out for the other processing purposes (e.g. profiling and direct marketing). Therefore, the dominant activity would be the profiling activities and considering both parties as controllers will make the drafting of the agreement more consistent.
However, considering B a controller does not mean that it cannot be subject to any obligation similar to those of a processor or being restricted with regard to the authorised use of personal data.
In this regard, it will be necessary to allocate each party’s obligations in detail in the data protection clause (e.g. agreeing each party’s obligation in terms of security, personal data breach notification, information notice as well as agreeing on data reversibility/retention period and the authorised use of personal data etc.)
Given the rise in complexity of the services provided by third parties, it is more and more difficult to work out the role of each party and unfortunately, it is often a grey area leading to a lot of disagreement between the parties. However difficult it is to work out each party’s role, the risk has become too high to neglect this point and in doubt, you should always make sure that third party recipient’s obligations in the contract ensure your compliance with the GDPR.