GDPR: Controller, Joint Controller, Processor or a Mere Recipient?

Posted

As we edge nearer and nearer to GDPR-Day (25 May 2018) more businesses are questioning their data protection policies and are attempting to overhaul their data protection practices. This has lead some businesses, who believe they are controllers, to ask other businesses, perceived to be processors, for “Processor Contracts”, as such controllers believe they have a controller – processor relationship. If such a relationship exists it is governed by Articles 28 and 29 of the General Data Protection Regulation (“GDPR”), but just how often does this sort of relationship actually arise?

Definitions of controller, processor and recipient under GDPR

In order to decide whether or not a processor contract is required, you need to know what a controller, a processor and a recipient are, as defined by GDPR. Initially it is important to understand that there is a difference between “processing”, as defined by Article 4(2) of GDPR, and being a Processor, defined by Article 4(8). Undertaking any form of processing does not automatically make you a Processor. It is possible to be a recipient, that is someone to whom the data is disclosed, and a processor because under the definition of processing simply storing such data is processing, without there being a requirement for a processing contract. Nowhere in GDPR does it state that a recipient is a Processor by virtue of the fact that it does processing. In order to avoid confusion, in this article when referring to a processor that would need to be subject to a processor contract we will use a capital ‘P’ for processor.

The definitions in Article 4 of GDPR, are as follows:

“Controller - 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…”;

“Processor - a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”; and

“Recipient - a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, whether a third party or not”.

Chapter 4 (Controller and Processor) of GDPR covers controllers, Processors and the relationship between the two. Article 26 states that joint controllers are “two or more controllers jointly determining both the purposes and the means of the processing to be carried out”. In our opinion this situation would arise when two or more entities were carrying out processing from the same data source but could be doing entirely different types of processing. For example, it may be agreed that one entity carries out marketing as its processing and the other entity maintains the Customer Relationship Management system in which the data is stored.

Article 28 further expands on the definition of a Processor, stating “where processing is to be carried out on behalf of a controller, the controller shall use only [P]rocessors [that can guarantee that] the processing will meet the requirements [of GDPR]”. The question then arises: what does “on behalf of a controller” really mean? Many businesses are assuming it means an entity that carries out any form of processing of data provided by them. This would mean that a business, e.g. a law firm, would need to be party to Processor Contracts with each of its clients; which if we consider GDPR with a purposive and proportionate approach cannot be the intended outcome.

GDPR Controller and Processor contracts

In order to establish whether or not a controller-Processor relationship exists you have to ask what it is exactly that the Processor can do with the data: is the processing of the data limited to only to those processes which the controller requires the Processor to carry out? If the processor can process in its own way, beyond that specifically required by the controller, the processor is a controller in its own right and a controller-Processor relationship is not established.

GDPR adds further detail by stating that where a controller has engaged a Processor to carry out processing on its behalf the Processor cannot engage another processor (e.g. as sub-contractor) without the prior written consent of the controller (Article 28(2)); that such processing shall be governed by a contract that binds the Processor to carry out only the processing required by the controller, and nothing else (Article 28(3)); and GDPR stipulates what must be included in the contract (Article 28(3)(a-h)). In summary: when the processing is being carried out for a controller the Processor can only process in the way that it is contractually bound to, and the Processor has no right to process the data in any other way. It has no discretion.

What is the opinion of the Information Commissioner’s Office (the “ICO”)?

The ICO have provided GDPR guidance on Contracts and Liabilities between Controllers and Processors; as with a lot of ICO guidance, it does not go into the detail of what controllers and processors actually are. It does state that if you are unsure as to whether you are a controller or a processor then the reader should refer to the ICO guidance based on the Data Protection Act 1998, Data Controllers and Data Processors.

In paragraph 25 of this guidance the ICO states “the fact that an organisation contracts or employs another organisation to provide a service to it does not mean that the other organisation becomes its data processor in every case. Whether an organisation is a data controller or data processor will depend on their role[s] and responsibilities in relation to the processing.”

If there is some responsibility that lies with the recipient of the data that is carrying out the processing to determine what it does with the data, that recipient cannot be a Processor and a Processor contract is therefore not required. The guidance provides various examples showing that it is only on rare occasions that a Processor contract would be required, and the example provided is cloud hosting providers. In the majority of the examples, as stated above, the recipient of the data is a controller in their own right, not a Processor nor a joint controller.

There is no specific definition of a joint controller and there is limited online guidance. The ICO do consider “controllers jointly acting” and the following two examples are provided.

GDPR Example 1

“A network of town-centre CCTV cameras is operated by a local council jointly with the police. Both are involved in deciding how the CCTV system is run and what the images it captures are used for. The council and the police are joint data controllers in relation to personal data processed in operating the system.”

GDPR Example 2

“A government department sets up a database of information about every child in the country. It does this in partnership with local councils. Each council provides personal data about children in its area, and is responsible for the accuracy of the data it provides. It may also access personal data provided by other councils (and must comply with the data protection principles when using that data). The government department and the councils are data controllers in common in relation to the personal data on the database.”

These examples demonstrate when a joint controller relationship arises and show again that the situations where it does arise are far less common than might originally be expected when deciphering GDPR.

It is possible that businesses may consider themselves as joint controllers with other businesses but in our opinion this is rare and it is far more likely that they are simply controllers in their own right or a mere recipient. We can conclude that joint controllership only arises when two controllers are processing from the same data pool using specific pre-agreed processing activities. Fortunately where a joint controller relationship does arise it is our opinion that documenting the “arrangements” between the controllers as required by GDPR is straightforward.

The information above supports our opinion that a processor contract is only required in very specific and limited circumstances, i.e. when the Processor is ONLY processing for a controller in accordance with specific requirements, and where the Processor has no control over how the data is processed or for what purpose. This means that many businesses that are being asked for processor contracts probably do not need to provide one; our advice to those businesses is to ask themselves exactly what they are doing with the data in question; if they have any discretion whatsoever there is no requirement for the contract.

The ICO held a consultation on their draft GDPR guidance on contracts and liabilities for controllers and processors. The deadline for responses was in late 2017 and the ICO are still analysing the feedback received but intend to publish the final guidance shortly, hopefully in time to provide further clarity before GDPR-Day.

To have your questions answered about GDPR, contact Brian Bannister on 023 8071 7466 or email brianbannister@warnergoodman.co.uk. Alternatively, you may find the following resources useful:

ENDS

This is for information purposes only and is no substitute for, and should not be interpreted as, legal advice. All content was correct at the time of publishing and we cannot be held responsible for any changes that may invalidate this article.