Who’s in Control?

One of the key aspects of data protection law is the concept of Data Controllers and Data Processors. In advance of the GDPR enforcement date (25th May), many organisations are seeking to review, update and amend their agreements with suppliers and partners, to ensure that the documentation doesn’t undermine their compliance with GDPR.

For GDPR compliance, it is critical that the paperwork matches reality, so simply issuing the same ‘Data Processor Questionnaire’ to anyone who you have invoiced over the past three years is highly unlikely to be enough – in fact, it may even be counterproductive if the relationship is not actually a Controller/Processor one.

The definitions of “Data Controller” and “Data Processor” have not significantly changed between previous legislation and the GDPR, although the language has been made more specific.


  “Data Controller” “Data Processor”
Data Protection Act 1998 a person who (either alone or jointly or in common with other persons) determines the purposes for which and the manner in which any personal data are, or are to be, processed; in relation to personal data, means any person (other than an employee of the data controller) who processes the data on behalf of the data controller;
Obligations Compliance with principles, suitable contracts with Processors No direct obligation
GDPR 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 natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller;
Obligations Compliance with principles, suitable contracts with Processors, written agreements with Joint Controllers Comply with the security principle; joint liability with Data Controller for breaches


As is evident from the definitions, a Controller/Processor relationship is not determined by who is paying whom, but by where decision-making authority is held, in relation to the processing of personal data. It is important to ascertain and document the correct relationship, as the exercise of data subject rights, legal obligations and liabilities are always the ultimate responsibility of the Data Controller.

There are three basic models for processing relationships between organisations:

Data Controller – Data Processor

  • The Controller dictates the why and how of the processing to the Processor.
  • The Processor can only follow the Controller’s instructions and may not re-use, re-purpose or disclose the data without the Controller’s (or Data Subject’s) explicit permission.
  • Only the Data Controller needs to be identified in privacy information
  • A Data Controller must put in place a legally-binding agreement (usually a contract) with any Data Processor they use, which addresses the requirements of GDPR Article 28.

Example: engaging an outsourced provider to manage payroll processing

Joint Data Controllers

  • Two or more organisations making decisions about the why and how of the personal data they are processing together.
  • The Joint Data Controllers may be processing the same core dataset or may be re-using each other’s data for their own purposes. They may be processing the data in the same way but for different purposes; or may be processing for the same purpose but by different means.
  • Both/all Data Controllers must be identified in privacy information
  • Responsibilities and boundaries need to be negotiated between the Data Controllers and documented, either in a contract or a data sharing agreement.

Example: using a specialist challenge event management company to organise a sponsored bungee jump

Separate Data Controllers

  • This relationship usually occurs when personal data is disclosed from one organisation to another but where each organisation will be processing the data independently and for their own purposes.
  • Both organisations need to provide suitable privacy information to the data subject
  • Each organisation is responsible for their own compliance; however the disclosing Data Controller needs some assurance that they are not putting data subjects at unwarranted risk by releasing their personal data, and the recipient Data Controller needs to be assured that the personal data was acquired, and is being disclosed in ways that are lawful, fair and transparent.

Example: An employer and their employee pensions provider

There are some common errors and assumptions which can lead to difficulties and disputes between organisations later on.

“We’re paying for a service, therefore only we can be the Data Controller”

The organisation making decisions about the data is a Data Controller, regardless of the flow of money. For example, if you engage an external legal firm to advise on an employment dispute, they will be a Data Controller in their own right, as they will be applying their professional judgement to the processing of the personal data supplied to them and will also be required to keep their own records for auditing and professional.

Similarly, if a school implements an online homework-management system to allow pupils to receive and submit their homework assignments, then then school will be a Data Controller for the pupils’ use of the system. However, if the system provider is also gathering analytics from the pupils (such as contact details, age, geolocation, devices used to access, psychological insights) to use for their own purposes (such as product development, targeted advertising or data profile-brokering) then the system provider is also a Data Controller.

Using boilerplate contract clauses which don’t specify the relationship

Although generic or model contract clauses can be used for Controller/Processor relationships, there still needs to be some detail which is specific to that relationship. This includes the specifics of the processing being carried out by the Processor and arrangements for responding to or assisting with incidents and data subject rights requests.

In Joint Data Controller relationships, the contract or agreement needs to be much more detailed, addressing the following issues:

  • Which party deals with rights requests, and at which points of the relationship with the data subject?
  • What is the obligation of each Data Controller to the other(s) to notify of incidents or breaches?
  • How and when does privacy information given to the data subject need to address the processing of both/all Data Controllers?
  • To what degree should a recipient Joint Data Controller be responsible for checking accuracy of data provided to them by the other Data Controllers in the Joint relationship?
  • Can one of the Data Controllers decide to reuse for a new purpose and do they need tell the other(s)? Or ask their permission?

There is no template or boilerplate text that can cover the details of Joint Data Controller arrangements as these will be specific to the organisations, processing purposes, types of data subject and categories of personal data.

In a straightforward transfer of personal data from one Data Controller to another with no continued alignment of processing, a contract is not necessarily needed but a data sharing agreement is strongly recommended to define:

  • what data is to be disclosed
  • when the disclosure takes place
  • why the disclosure is needed
  • how the personal data is disclosed
  • how privacy information about the disclosure is to be communicated.

Tips for managing third-party relationships:

  • Generic, standard terms and conditions are unlikely to provide suitable and appropriate protections for all parties (including the data subjects). Specifics of the processing and responsibilities must also be agreed and documented
  • Data Controllership is a matter of fact and cannot be waived, re-assigned or delegated by contract terms. You can include warranties and indemnities in the contract to allow your organisation to recover losses from a problem you didn’t cause, but if you are the party making the decisions, then you ultimately remain accountable for the processing of the personal data
  • Consider your exit strategy: what happens to the data if your organisation’s relationship with the other party comes to an abrupt (or even planned) end? Is return/retention of data addressed in contract?

Asking some basic questions can help you determine whether a supplier, provider or partner is a Data Controller or a Processor:

  • Can the other party decide to do something different with the data, such as start processing it for other purposes, or disclose it to another Data Controller?
    • If the answer is ‘no’ then the other party is likely to be a Data Processor
  • Can my organisation remove/restrict/prevent the data being processed by the other party without having to ask their permission?
    • If the answer is ‘yes’, then the other party is likely to be a Data Processor
  • Can the other party assert a confidential relationship with the data subject that prevents your organisation from accessing their data?
    • If the answer is ‘yes’, then the other party cannot be a Data Processor
  • Does the other party assert that details of the processing (such as algorithmic logic, copyrighted databases, confidential sources) are proprietary and commercially confidential to them?
    • If the answer is ‘yes’, then the other party cannot be a Data Processor
  • Does the other party have auditing or accountability obligations that require them to process the personal data even if you tell them not to?
    • If the answer is ‘yes’, then the other party cannot be a Data Processor

As well as making the initial determination about the nature of a data processing relationship, keeping track of these relationships and the supporting documentation is a critical part of complying with the Accountability Principle of GDPR. Ideally, the records should be kept with, or linked to the Record of Processing Activity.


Written by Rowenna Fielding