Out-Law Analysis | 02 Nov 2018 | 2:11 pm | 4 min. read
The GDPR spurred banks, insurers and other financial institutions to review their existing contracts, most notably their data processing agreements.
We found through our work that there is a lot of confusion in this sector about the concepts of 'controllers' and 'processors' of personal data. Both controllers and processors have distinct obligations under the GDPR.
When organisations wish to use third parties to process personal data they are responsible for on their behalf then those organisations - controllers - need to have a written contract with those third parties - processors - stipulating the conditions by which the data can be processed. However, not all agreements which involve the processing of personal data will necessarily have a controller and a processor - both parties could perform the role of controller, even where one party is providing a service to the other.
The roles of controllers and processors are defined in the GDPR, so in theory it should be easy to distinguish which party in a data processing relationship is a controller and which is a processor. However, the issue is more complicated than many financial services firms might realise.
We found this out through our work supporting large scale contract remediation projects to incorporate GDPR-mandated provisions, set out in Article 28, into data processing agreements. We were surprised just how much time was spent negotiating whether a party was acting as a controller or processor.
Reflecting on why this was the case, we have found that this is partly due to the fact that, traditionally, data flows in the financial services sector are complicated and often involve multiple parties, meaning that the roles of each party do not necessarily fit neatly into the concepts of controller and processor, or indeed 'joint controller' as defined by the GDPR.
There are other contributory factors too. Some businesses confuse the concept of data ownership with the concept of controller. The controller status confers obligations, not rights. In addition, placing restrictions on permitted uses of the personal data upon the recipient does not necessarily cause that party to be a processor if they fulfil other elements of the controller criteria.
We also experienced reluctance by some counterparties to accept responsibility for the controller status for fear of being subject to the full gambit of the GDPR. Conversely, we saw other counterparties unwilling to accept processor status due to concern about the GDPR's requirement to ensure that the controller imposes contractual restrictions on the processor's rights to sub-contract and transfer personal data outside of the European Economic Area (EEA) without first obtaining the controller's permission.
In the negotiations over whether parties to a data processing agreement were controllers or processors, we saw a lot of focus given to which party determines the 'purpose' of the processing as the grounds for defining the parties' roles and relationship. However, there are a number of other factors to be considered which influence whether an organisation is performing a controller or processor role under a particular contractual arrangement. This is confirmed in guidance that has been produced by EU and UK data protection authorities.
Further questions that should be asked include:
The designation of the parties in the contract is ultimately a question of fact based on the data processing being carried out by each party. While the contractual designation of the parties is not absolute, it will be taken into account by the ICO and/or the courts and so it is important that the parties are in agreement about the role being performed by each party. Therefore, it is important for the parties to agree a set of clauses that are appropriate to the 'controller v processor' relationship and that those terms achieve statutory compliance for both parties.
While there are no specific mandatory contractual clauses that must be included in a controller-to-controller data sharing arrangement, organisations should still refer to the ICO's statutory data sharing code of practice, which is currently in the process of being updated, to ensure that risks have been identified and provided for in the contract.
Kathryn Wynn is an expert in data protection law at Pinsent Masons, the law firm behind Out-Law.com.