A GUIDE TO CONTROLLER-PROCESSOR CONTRACTS
The GDPR sets out strict requirements for when an organisation decides to utilise the services of another company to process personal data. The most important aspect to establish first is whether you are both acting as controllers of the personal data being processed or whether the service provider is purely acting as a processor, acting at all times under instruction of the controller.
What is a controller?
A controller is person, or more commonly an organisation, which controls the ‘means and purposes of processing’. The controller makes the decisions about how this personal data is collected, used, stored, transferred, kept secure, destroyed etc. and among other matters is responsible for fulfilling individual rights requests, such as Subject Access Requests.
What is a processor?
To be recognised as a processor, a person or organisation, must processes personal data on behalf of a controller and not use this data for their own purposes. For example, a processor may be an external company utilised to provide payroll, printing, marketing or website services.
However, if an organisation determines the ‘means and purposes of processing’, i.e. uses the personal data for their own purposes, they become a controller. For example, if a marketing service provider uses the personal data it’s provided for its own internal analysis/profiling (which is not solely produced for the controller) it’s likely to be considered a controller for this activity.
It is worth noting that processors may be those who are offering hosted or cloud based services, which although not EU located are clearly caught by GDPR.
Establishing the relationship
It has proved very challenging for many organisations to clearly establish whether companies are acting as processors or controllers, with some organisations insisting they are a processor when actually they may be a controller. However, it is crucial for this to be established if you wish to ensure these relationships are compliant.
Where controllers are sharing personal data with another controller, this may under a joint-controller relationship or as separate autonomous controllers. In both circumstances, controllers have a duty to meet their data protection obligations as controllers. Therefore if they that act as joint controllers, they will have shared obligations.
What GDPR changed for Controller-Processor relationships
Prior to the GDPR, the accountability for compliance rested almost entirely with the controller, who was liable if things went wrong. Now, under the GDPR, the controller and processor could both be held accountable for compliance with the Regulation, and for compensating any damage (material or non-material) suffered by EU data subjects. A controller or processor would only be exempted shall if they can prove they are ‘not in any way responsible’. And if the controller goes out of business, the processor carries the full burden. Processors also have their own accountabilities, such as being responsible for their sub-processors, data transfers, staff training, fulfilling record of processing requirements (where necessary) and assisting the controller.
What does GDPR require for Controller-Processor agreements?
Article 28 sets out specific requirements for when a Controller utilises the services of a processor. Just to reiterate, Article 28 applies when the supplier/vendor is:
- processing personal data on behalf of the controller (i.e. processing the controller’s own data)
- under the instruction of the Controller
- NOT using the controller’s personal data for its own purposes.
The law makes it very clear that this arrangement must be covered by a binding agreement (i.e. a live contract) and there are specific provisions that must be included in this agreement in order to comply with GDPR Article 28. Prior to GDPR written contracts were required, but GDPR requires more specific detail.
Core GDPR Contractual Requirements
1. Technical and Organisational Measures (TOMs)
The Controller must only use processors who have provided sufficient guarantees to implement appropriate technical and organisational measures to meet the requirements of GDPR and ensure the protection of data subjects’ rights.
It is therefore strongly advisable that organisations, as part of their due diligence process, conduct an information security impact assessment of any potential new processor and to document the outcomes. The aim of this is to provide assurance to the controller that personal data will be properly protected both in transit and when at rest in the processors’ systems. It is advisable to include reference to necessary security measures implemented by the processor in any contract, which may include for instance any requirement for encryption, access controls, and so on.
Controllers should also look for assurance by the processor on aspects such as adequate training of the staff handling their personal data and that access to data is restricted to those that require it to provide the service.
2. Appointment of sub-processors
The processor must not engage another processor (often referred to as ‘sub-processor’) to conduct processing of the controller’s personal data without the specific or general written authorisation of the controller.
Furthermore, the processor needs to inform the controller of any intended material changes concerning additional/replacement sub processors as the controller must be given the opportunity to object to such changes.
A contract should therefore provide details of any sub-processors which will be used to handle the controller’s data. Updates should be provided when this list changes.
Under the law processors need to be aware they are accountable and liable for the actions of their sub-processors. Article 28(4) specifically states that the same obligations as set out in the contract between the controller and processor shall be imposed on another processor by way of contract (or other legal act).
Where a sub-processor fails to fulfil its data protection obligations, the initial processor will be fully liable to the controller for the performance of the sub-processor’s obligations. Processors are therefore responsible to conducting due diligence of any sub-processors they use.
3. Further contractual requirements
A contract (or other legal act) between a controller and processor must set out the following:
- Types of personal data the processor will be processing on behalf of the controller (e.g. name, email address, telephone number, bank account number, date of birth – including any special category data)
- Categories of data subject (e.g. employees, patients, customers, students, minors)
- Nature and purpose of processing
- Duration of processing (i.e. the term of the contract)
- Obligations and rights of the controller
Article 28 continues to provide other specific details that must be covered in a contract.
a) Rights and duties of each party (e.g. the processors commitment not to use the controller’s personal data for any other purpose than for providing the agreed service).
b) Instructions from the controller – The agreement should include details of what the processor is permitted to do with the personal data it is provided. In practice, this may often be set out by the supplier (processor), but the controller should check and agree that these accurately represent their instructions.
c) International transfers – If relevant, the agreement should include details and provisions for any transfer of personal data to a third country (i.e. outside the EEA) whether this be to the processor itself or any sub-processors used. Post-Brexit this will become a key aspect of contracts as the UK itself would become a third country.
d) Duty of confidentiality – There must be a confidentiality clause which commits the processor to ensuring that people who are authorised to access the controller’s personal data have committed themselves to a duty of confidentiality or are under a statutory obligation of confidentiality.
e) Data subject’s rights – the processor must commit to assist the controller, where applicable, with the fulfilment of data subject’s rights, such as Subject Access Request, the right to erasure, the right to object to processing, etc.
f) Assistance with controller’s compliance – the agreement should set out that, as and when required, the processor will assist the controller with:
i. Security of processing
ii. Notification of any Data breaches
iii. Conducting a Data Protection Impact Assessments (DPIA), should this be required
g) Return or destruction of the data – the agreement should stipulate what happens to the controller’s personal data at the end of the term of the contract. The law states that at the choice of the controller all personal data must be returned or destroyed. If the controller’s choice is for the data to be destroyed, it would be advisable to ensure that a contract stipulates that a data destruction certificate will be provided.
h) Audits and inspections – the agreement should set out that the processor agrees to make available all information necessary to demonstrate compliance with Article 28 and will allow for, and contribute towards audits, including inspections, by the controller or an authorised auditor.
What might be the consequences of getting data contracts wrong?
It’s crucial that contracts relating to data processing include all the appropriate terms to make sure that individuals are properly protected and also that the accountabilities and liabilities of each party are clearly agreed should a data breach or other infringement of data protection law occur.
As GDPR states:
‘Any person who has suffered material or non-material damage as a result of an infringement of this Regulation shall have the right to receive compensation from the controller or processor for the damage suffered.
Any controller involved in processing shall be liable for the damage caused by processing which infringes this Regulation. A processor shall be liable for the damage caused by processing only where it has not complied with obligations of this Regulation specifically directed to processors or where it has acted outside or contrary to lawful instructions of the controller.’ (Article 82)
It’s worth noting that a Ponemon Institute study revealed that 56% of companies experienced a 3rd-party breach in 2017, which represented an increase of 7% compared to previous year. In the event of a supplier suffering a breach, contractual arrangements are likely to come under scrutiny.
Simon Blanchard, May 2019
The information provided and the opinions expressed in this document represent the views of the Data Protection Network. They do not constitute legal advice and cannot be construed as offering comprehensive guidance on the EU General Data Protection Regulation (GDPR) or other statutory measures referred to.