GDPR: the 'controller v processor' debate in financial services

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.

The controller v processor debate

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.

Distinguishing controllers from processors

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:

• how autonomous is the service provider/data recipient?
• is the expertise limited to the "means" of the processing or is this a more specialist service which the customer/data provider would not be able to do in-house?
• is the service provider/ data recipient processing the personal data for its own benefit - for example, to generate new business as opposed to simply being paid to carry out the processing or provide a service?
• does the service provider/data recipient determine the legal basis of the processing?
• does the service provider/data recipient select the data subjects?
• does the service provider/data recipient determine the content of the personal data?
• is the counterparty subject to a regulatory regime or conducting a regulated activity?

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. 

In data sharing arrangements, a particular area of concern that is emerging is how the recipient controller conveys the 'fair processing' information, required under Article 14 of the GDPR, in an arrangement where it has no direct contact with the data subjects. The parties should work together to map out the customer journey to ensure that data subjects are provided with the requisite information about the overall data processing arrangement. Agreed solutions have included the disclosing controller providing sufficient information to cover the Article 14 information or providing a link to the recipient controller's privacy policy.

Kathryn Wynn is an expert in data protection law at Pinsent Masons, the law firm behind Out-Law.com.