This guidance discusses contracts and liabilities between controllers and processors in detail. Read it if you have detailed questions not answered in the Guide, or if you need a deeper understanding. DPOs and those with specific data protection responsibilities in larger organisations are likely to find it useful.
If you haven’t yet read contracts in brief in the Guide to Data Protection, you should read that first. It sets out the key points you need to know, along with practical checklists to help you comply.
This guidance will help both controllers and processors to understand what needs to be included in a contract and why. It will also help processors to understand their new responsibilities and liabilities under the GDPR.
There are many common issues to discuss about contracts and liabilities. We have structured the guidance so that these are discussed first. After this, the issues specific to controllers and processors are discussed separately. So whether you are one or the other, we recommend that you read the general sections first, and then read the sections specific to you. This will give you a full understanding of the topic.
Please note that this guidance is not a guide to contract law or to the intricacies of commercial contract negotiation. Contracting parties should, if required, seek advice from their own trade or professional organisations, and obtain professional advice on updating existing contracts and agreeing the terms of new contracts. The commercial aspects of the contract are a matter for the parties, so long as it complies with the GDPR.
What’s new under the GDPR?
Under the Data Protection Act 1998 (“the 1998 Act”), a controller that employed a third party to process personal data on its behalf (a “processor”) could demonstrate its compliance with the security principle by having a contract in place with the processor.
Typically, this contract would have required the processor to only act upon the controller's instructions and to take appropriate measures to keep the personal data secure.
Under the GDPR, there is a separate obligation to have a contract. Also, contract requirements are more wide-ranging and are no longer confined to just ensuring the security of personal data. They aim to ensure that the processing of personal data, by a processor, will comply with all the GDPR's requirements and protect the rights of data subjects. The GDPR sets out specific terms that must be included in the contract, as a minimum.
The contract must state details of the processing, and must set out the obligations and rights of both the controller and the processor. It must also include the standards the processor has to meet when processing personal data.
This is a significant change to what the 1998 Act required. However, in practice, existing contracts may have already included some of the new requirements for commercial reasons or as good practice under the 1998 Act.
The GDPR also allows the contract to include standard contractual clauses issued by the European Commission or a supervisory authority, such as the ICO. Again this is a significant change in the law but, initially at least, it should make little practical difference as standard clauses are not yet available.
In the future, processors may be able to demonstrate they provide ‘sufficient guarantees' to process personal data in line with the GDPR by adhering to an approved code of conduct or certification scheme. No such codes or schemes have been approved so far so, initially at least, this should make little practical difference.
The main difference is that processors now have direct GDPR responsibilities and obligations, outside the terms of the contract. Processors can be held directly responsible for non-compliance with their GDPR obligations. They may be subject to administrative fines or other sanctions and liable to pay compensation to data subjects.
If you haven't already done so, you must ensure any contracts which were in place as of 25 May 2018 meet the GDPR's requirements.
Controllers and processors should therefore check their existing contracts to make sure they contain all the required elements. If they don't, it's essential to either amend existing contracts or get new contracts drafted and signed, and to review all template contracts in use.
It would also be prudent for controllers to make sure their processors understand the reasons for the changes and the obligations that the GDPR puts on them. The processor should understand that it may also be directly subject to an administrative fine or other sanction if it does not comply with its obligations.
When is a contract needed and why is it important?
The GDPR imposes a legal obligation on controllers and processors to formalise their working relationship. Aside from the legal requirements, this makes practical and commercial sense.
By having a contract in place with the required terms, controllers and processors are:
- ensuring they each comply with the GDPR;
- protecting the personal data of customers, staff and others; and
- ensuring both parties are clear about their role regarding the personal data that is being processed and are able to demonstrate this.
The GDPR says that a contract is needing in two circumstances.
Firstly, Article 28(3) states that:Processing by a processor shall be governed by a contract or other legal act under Union or Member State law, that is binding on the processor with regard to the controller…
This means every time a controller uses a processor to process personal data, there must be a written contract that binds the processor to the controller in respect of its processing activities.
Article 28(3) could be complied with not only by a direct contract between the controller and the processor, but also by other legally binding contractual arrangements (for example, a set of contracts between multiple parties) provided the processor is ultimately bound, as a matter of contract law, to each controller in respect of the particular processing.
Secondly, Article 28(4) states that:Where a processor engages another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 3 shall be imposed on that other processor by way of contract or other legal act…
This means that every time a processor uses another processor (a sub-processor), there must be a written contract between the processor and the sub-processor. The terms of the contract that relate to Article 28(3) must offer an equivalent level of protection for the personal data as those that exist in the contract between the controller and the processor.
The GDPR refers to a contract 'or other legal act'. But, in practice, in the UK, contracts are likely to be the appropriate means of complying with Article 28(3).
The GDPR defines a controller and processor as:
‘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.
‘processor’ means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
If you are not sure whether you are a controller or a processor, read ICO guidance on controllers and processors.
It is common practice for a controller to engage a processor to process personal data on its behalf – for example, to take advantage of the processor's expertise and experience in a particular type of processing operation
- A specialist company provides software and data analysis to process the daily pupil attendance records of a state-maintained school for an annual fee. For the software provision the company is not a processor, but for the data analysis it is a processor for the school.
- The readers of a monthly science magazine receive a hard copy delivered to their home. Their subscriptions and the mailings are handled by a separate company at the publisher's request. The company is a processor for the magazine publisher.
- A marketing company sends promotional vouchers to a hairdresser's customers on the hairdresser's behalf. The marketing company is a processor for the hairdresser.
- An organisation uses a cloud service to store and analyse its data. The organisation remains the controller and the cloud service provider is its processor.
A processor might wish to use the services of another processor to assist with the processing it is carrying out on the controller's behalf. For shorthand, this is sometimes referred to as using a 'sub-processor', although this is not a term taken from the GDPR itself.
Before employing a sub-processor, the original processor must inform the controller and obtain its prior specific or general written authorisation.
If authorisation is given, the processor must put in place a contract with the sub-processor. The terms of the contract that relate to Article 28(3) must offer an equivalent level of protection for the personal data as those that exist in the contract between the controller and the processor.
For more information on the process for appointing sub-processors, see ICO guidance on controllers and processors.
The controller and processor must be party to the contract. In any sub- processing arrangements, the relevant parties to the contract will be the processor and sub-processor.
For organisations with no separate legal personality (eg unincorporated partnerships or unincorporated associations), you should review the document which sets up and governs the management of that organisation. This document should set out which individual(s) manage the organisation on behalf of its members and are likely to act as the controller or joint controllers, and how contracts may be entered into on behalf of the organisation.
What needs to be included in the contract?
Article 28(3) states that the contract (or other legal act) must include the following details about the processing:
- the subject matter and duration of the processing;
- the nature and purpose of the processing;
- the type of personal data and categories of data subject; and
- the controller’s obligations and rights.
The controller therefore needs to be very clear from the outset about the extent of the processing it is contracting out.
Article 28(3) also sets out the following specific terms or clauses that must be included in the contract:
- Processing only on the documented instructions of the controller.
- Duty of confidence.
- Appropriate security measures.
- Using sub-processors.
- Data subjects’ rights.
- Assisting the controller.
- End-of-contract provisions.
- Audits and inspections.
These are the minimum required, but the controller and processor may agree to supplement them with their own terms. Each of these terms is explored further below.
Under Article 28(3)(a) the contract must say that the processor may only process personal data in line with the controller’s documented instructions (including when making an international transfer of personal data) unless it is required to do otherwise by EU or member state law.
The contract may include details of the instructions specified in Article 28(3), or those instructions may be provided separately.
An instruction can be documented by using any written form, including email. The instruction must be capable of being saved, so that there is a record of the instruction.
This contract term should make it clear that it is the controller, rather than the processor, that has overall control of what happens to the personal data.
If a processor acts outside of the controller’s instructions in such a way that it decides the purpose and means of processing, including to comply with a statutory obligation, then it will be considered to be a controller in respect of that processing and will have the same liability as a controller.
Under Article 28(3)(b) the contract must say that the processor must obtain a commitment of confidentiality from anyone it allows to process the personal data, unless that person is already under such a duty by statute.
This contract term should cover the processor’s employees as well as any temporary workers and agency workers who have access to the personal data.
Under Article 28(3)(c) the contract must oblige the processor to take all security measures necessary to meet the requirements of Article 32 on the security of processing.
Both controllers and processors are obliged under Article 32 to put in place appropriate technical and organisational measures to ensure the security of any personal data they process which may include, as appropriate:
- encryption and pseudonymisation;
- the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
- the ability to restore access to personal data in the event of an incident; and
- processes for regularly testing and assessing the effectiveness of the measures.
Adherence to an approved code of conduct or certification scheme may be used as a way of demonstrating compliance with security obligations. Codes of conduct and certification may also help processors to demonstrate sufficient guarantees that their processing will comply with the GDPR.
Under Article 28(3)(d) the contract must say that:
- the processor should not engage another processor (a sub-processor) without the controller’s prior specific or general written authorisation;
- if a sub-processor is employed under the controller’s general written authorisation, the processor should let the controller know of any intended changes and give the controller a chance to object to them;
- if the processor employs a sub-processor, it must put a contract in place imposing the same Article 28(3) data protection obligations on that sub-processor. This should include that the sub-processor will provide sufficient guarantees to implement appropriate technical and organisational measures in such a way that the processing will meet the GDPR’s requirements. The wording of these obligations do not need to exactly mirror those set out in the contract between the controller and the processor, but should offer an equivalent level of protection for the personal data; and
- the processor is liable to the controller for a sub-processor’s compliance with its data protection obligations.
For more information on the process for appointing sub-processors, please read ICO guidance on controllers and processors.
Under Article 28(3)(e) the contract must provide for the processor to take “appropriate technical and organisational measures” to help the controller respond to requests from individuals to exercise their rights.
This provision stems from Chapter III of the GDPR, which describes how the controller must enable data subjects to exercise various rights and respond to requests to do so, such as subject access requests, requests for the rectification or erasure of personal data, and objections to processing. For more information, please read our guidance on individuals’ rights.
Under Article 28(3)(f) the contract must say that, taking into account the nature of the processing and the information available, the processor must assist the controller in meeting its obligations to:
- keep personal data secure;
- notify personal data breaches to the supervisory authority;
- notify personal data breaches to data subjects;
- carry out data protection impact assessments (DPIAs) when required; and
- consult the supervisory authority where a DPIA indicates there is a high risk that cannot be mitigated.
We recommend that the contract is as clear as possible about how the processor will help the controller meet its obligations.
Under Article 28(3)(g) the contract must say that at the end of the contract the processor must:
- at the controller’s choice, delete or return to the controller all the personal data it has been processing for it; and
- delete existing copies of the personal data unless EU or Member State law requires it to be stored.
It should be noted that deletion of personal data should be done in a secure manner, in accordance with the security requirements of Article 32. For more information, please read our guidance on security.
The contract must include these terms to ensure the continuing protection of the personal data after the contract ends. This reflects the fact that it is ultimately for the controller to decide what should happen to the personal data being processed, once processing is complete.
We appreciate the practical reality that it may not be possible for data in backups or archives to be deleted immediately on termination of a contract. Provided appropriate safeguards are in place, such as the data being put immediately beyond use, it may be acceptable that the data is not deleted immediately if the retention period is appropriate and the data is subsequently deleted as soon as possible, eg on the processor’s next deletion/destruction cycle.
Under Article 28(3)(h) the contract must require:
- the processor to provide the controller with all the information that is needed to show that the obligations of Article 28 have been met; and
- the processor to allow for, and contribute to, audits and inspections carried out by the controller, or by an auditor appointed by the controller.
This provision obliges the processor to be able to demonstrate compliance with the whole of Article 28 to the controller. For instance, the processor could do this by giving the controller the necessary information or by submitting to an audit or inspection.
The GDPR does not require that the contract includes a provision requiring a processor to keep records of the processing it carries out for the controller – although such records would be useful for the processor to demonstrate compliance with Article 28. However, requirements for processors to maintain records of their processing activities are set out in Article 30(2). For more on this, see ICO guidance on controllers and processors.
The GDPR allows the EU Commission and supervisory authorities (such as the ICO) to issue standard clauses to include in contracts between controllers and processors. These clauses may provide a simple way to ensure that contracts between controllers and processors comply with the GDPR. They may also form part of a certification scheme to demonstrate compliant processing, when the schemes have been approved.
The Danish Data Protection Agency has adopted SCCs which have been approved by the EDPB (external link). If you use these SCCs in a contract with a processor (without amendment) the contract should comply with the requirements in Article 28.
What responsibilities and liabilities do controllers have when using a processor?
The controller is responsible for assessing that its processor is competent to process personal data in line with the GDPR’s requirements. This assessment should take into account the nature of the processing and the risks to the data subjects. This is because Article 28(1) says a controller must only use a processor that can provide “sufficient guarantees” (in particular in terms of its expert knowledge, resources and reliability) to implement appropriate technical and organisational measures to ensure the processing complies with the GDPR and protects the rights of individuals.
Some examples of the considerations controllers should have when assessing whether the processor provides “sufficient guarantees” could include:
- the extent to which they comply with industry standards, if these apply in the context of the processing;
- whether they have sufficient technical expertise to assist the controller, eg in carrying out obligations under Articles 32-36 of the GDPR (technical measures, breach notifications and DPIAs);
- adherence to an approved code of conduct or a certification scheme (when they become available).
This is not an exhaustive list, and ultimately it is for the controller to satisfy itself that the processor provides sufficient guarantees in the context of the processing. Whether the guarantees are sufficient will depend on both the circumstances of the processing and the risk posed to rights of individuals.
Once the controller has chosen a suitable processor, it must put in place a contract or other legal act that meets all the requirements of Article 28(3) and give the processor documented instructions to follow (either in the contract or separately).
However, the controller’s responsibilities do not end there. Controllers should ensure a processor’s compliance on an ongoing basis, in order for them to satisfy the accountability principle and demonstrate due diligence. In particular, Article 28(3)(h) explicitly requires the processor to allow for and contribute to audits and inspections, carried out either by the controller or a third party appointed by the controller. The methods used to monitor compliance and the frequency of monitoring will depend on the circumstances of the processing.
A controller is primarily responsible for its own compliance and ensuring the compliance of its processors. This means that, regardless of the terms of the contract with a processor, the controller may be subject to any of the corrective measures and sanctions set out in the GDPR. These include orders to bring processing into compliance, claims for compensation from a data subject and administrative fines.
An individual can bring claims directly against a controller if the processing breaches the GDPR, in particular where the processing causes the individual damage.
A controller will be liable for any damage (and any associated claim for compensation payable to an individual) if its processing activities infringe the GDPR.
However, a controller will not be liable for damage resulting from a breach of the GDPR if it can prove it was not in any way responsible for the event giving rise to the damage.
If a processor is involved in the processing, the individual making the claim for compensation can claim against either party. If a controller has to pay full compensation for damage suffered by individuals, it may be able to claim back all or part of the amount of compensation from a processor involved in the processing, to the extent that the processor is at fault.
What responsibilities and liabilities do processors have in their own right?
A processor may make its own day-to-day operational decisions, but Article 29 says it should only process personal data in line with a controller’s instructions, unless it is required to do otherwise by EU or Member State law (in that case it must inform the controller of this legal requirement before the processing, unless that law prohibits it doing so on important grounds of public interest). This is also a required contract term under Article 28(3)(a).
If a processor acts outside of a controller’s instructions in such a way that it decides the purpose and means of processing, then it will be a controller and will have the same liability as a controller.
In addition to the contract terms, a processor also has some direct responsibilities and liabilities under the GDPR. When drawing up and negotiating a contract for data processing, it is good practice for all parties to make sure they understand this.
The parties may also wish to explicitly cover this in the contract, although the GDPR doesn’t require it. For example they may wish to include a clause specifying that nothing in the contract relieves the processor or controller of its own direct responsibilities and liabilities under the GDPR – and to say what these are.
In any case we recommend that both the controller and processor obtain their own professional advice.
For more information about a processor’s direct responsibilities under the GDPR, please see ICO guidance on controllers and processors.
A processor may be contractually liable to the controller for any failure to meet the terms of their agreed contract. This will of course depend on the exact terms of that contract.
It will also be subject to the relevant investigative and corrective powers of a supervisory authority (such as the ICO) and may be subject to administrative fines or other penalties.
An individual can also bring a claim directly against a processor in court. A processor can be held liable under Article 82 to pay compensation for any damage caused by processing, including non-material damage such as distress. A processor will only be liable for the damage if:
- it has failed to comply with GDPR provisions specifically relating to processors; or
- it has acted without the controller’s lawful instructions, or against those instructions.
It will not be liable if it can prove it is not responsible for the event giving rise to the damage.
If a processor is required to pay compensation, but is not wholly responsible for the damage, it may be able to claim back from the controller, the share of the compensation for which they are responsible. Both parties should seek professional legal advice on this.
If you are a sub-processor, you will be liable for any damage caused by your processing only if you have not complied with the GDPR obligations imposed on processors or you have acted contrary to lawful instructions from the controller, relayed by the processor, regarding the processing.
If you are a processor and use a sub-processor to carry out processing on your behalf, you will be fully liable to the controller for the sub-processor’s compliance with its data protection obligations. This means that, under Article 82(5), if a sub-processor is at fault, the controller may claim back compensation from you for the sub-processor’s failings. You may then claim compensation back from the sub-processor.
A sub-processor may also be contractually liable to the processor for any failure to meet the terms of the agreed contract. This will of course depend on the exact terms of that contract.
Processors and sub-processors should seek their own legal advice on issues of liability and the contracts between controllers and processors and processors and sub-processors.
Thank you for reading.