In an earlier post I mentioned the “battle of forms” which is a term the lawyers use when referring to a conflict between two sets of standard contract terms issued by the parties of a transaction, such as a supplier and a customer. In April 2016 by the European Parliament of the General Data Protection Regulation (GDPR), which (among so many many other things) requires that the party that is responsible for the personal data (controller) needs to conclude a specific written agreement with all the parties that process their personal data, so called data processing agreement (DPA). It has proved to contain a number of sticky points, leaving sometimes the lawyers arguing until the cows come home…
As expected, the adoption of GDPR triggered thousands if not tens of thousands of lawyers to draft their own standard DPA form for their clients, looking at the world either form controller or processor point of view, and trying to protect their client against the unknown calamities to come. Despite of the fact that the core contents of a DPA is meticulously regulated in the GDPR, there remains areas where the lawyers have the freedom to tip the scale of responsibilities on one side or another. The phenomenon reminds me of the Y2k era, when lawyers tried to address every possible permutation of things going wrong on 1.1.2000 when legacy systems were feared to crash or provide incorrect results if they did not manage to handle calendar dates of the next century. Many lawyers added to the soup leap years and all kind of other specific anomalies and events that nobody had bothered to contractually regulate before, but had rather relied on more generic warranties. Common to both legal conjunctions is that they caused challenges to those stuck with old IT systems that date back to a time where the standards and requirements for security, privacy and data protection were different than now, and the GDPR related functional requirements could not be anticipated.
In my experience, there are especially two sticky topics that almost invariably raise in the DPA negotiations: costs and limitation of liability.
The issue with costs is partly related to the fact that the GDPR (Article 12.5) requires that the controller will enable fulfillment of certain rights of the data subjects free of charge (such as the registered persons’ right to get their personal data erased (right to be forgotten). The controllers would naturally would like to ensure in the DPA that the providers of their cloud services, IT platforms and services equally will not charge for anything that the controller may require to be done to comply with rights of the data subjects. Such obligation is however not directly applicable by the GDPR to the processors which claim that in certain situations these requests may cause significant costs that should be carried, or at least sheared, by the controller. Similarly, many controllers would like to ensure that when they review their “TOMs” requirements (the technical and organisational measures – effectively data security requirements), this should not increase their cost of data processing. If the controller at the same time does not allow the processor the freedom to choose how to implement the data security, so that it can be done cost effectively and by applying the same technical solution across the whole customer base, this will put the processor into an unbearable situation. Until there is some court practice, industry best practices or codes of conduct that help to set a reasonable balance, these discussions may remain challenging.
Some controllers have taken the view that the processor’s liability for breaches under the DPA should be unlimited, and in the best case, fortified with extensive indemnity provisions. This has been caused by the GDPR regime that includes potential liability of the controller and processor for damage and administrative fines which can go up to 4 % of the total worldwide annual turnover (similar to those applicable for breaches of EU competition law – a topic worthy of a separate post). Further, the controller (and processor) have a reverse burden of proof, meaning that they need to prove they did not violate the Regulation. Due to the wide range of issues and situations that could lead to liability, the processors are generally unwilling to deviate (much) from what they would normally agree concerning limitation of liability when providing IT platforms and services. Accordingly, the gap between these two standpoints is wide, and both sides can provide an ample sample of justifiable reasons as to why their view should prevail.
Article 82.4 and 5 of the GDPR provides for joint liability of the controller and processor, and respective right of recourse (right to claim back what one has had to pay instead of the faulty party). In theory, that should take off the pressure between the controller and processor in the DPA, as they are both directly liable towards the authorities for fines and towards the data subjects for damage. In the perfect world they would in such situations both be direct parties in the proceedings so that their respective proportionate liability would be determined at that occasion. But there are several reasons why this may not happen, and should be discussed is a separate post.
In contrast to the battles of DPA forms under the GDPR, the European Commission has in the past issued so called “model contracts” or “standard contractual clauses” (decision 2010/87/EU) that are a form of DPA designated to regulate the processing outside the EU/EEA between the controller and processor. They came with a lovely legislative backbone – it is obligatory to use them verbatim as issued by the Commission, in order to remain complaint and achieve the intended purpose of providing the “adequate protection” of the processing of personal data outside the EU/EEA. Maybe it would save a lot of everybody’s time, money and legal resources if the EU would move to issue a mandatory standard DPA also for the data processing within the EU/EEA…