Given the potential financial exposure under GDPR, it is no surprise that a great deal of time is being spent working out how to allocate the risk and liability when negotiating commercial contracts. Here is our take on the underlying law and the recent trends.

Obligations – the source of liability

Before we look at limiting liability, we need to first consider how liability can arise in the first place in the context of GDPR.

Assuming a straightforward Controller/Processor arrangement, there are three ‘categories’ of obligations which can give rise to liability: (i) those imposed by the GDPR irrespective of the terms of the contract, (ii) those which GDPR mandates are included in the contract, and (iii) those additional terms which the parties expressly choose to set out in the contract. Looking at each in turn:

  1. Under GDPR, a series of obligations are automatically placed on the Controller, including the general principles relating to processing (such as to do so lawfully, fairly and in a transparent manner) under Article 5 and the conditions for obtaining consent under Article 7. There is no need to set these obligations out in the contract itself. Likewise, although more limited, GDPR imposes direct obligations on the Processor, including the (joint) requirement to implement appropriate technical and organisational security measures under Article 32 and the obligation to notify the Controller of a personal data breach without undue delay under Article 33(2).
  2. The second source is the obligations the parties are obliged to include in the contract as a result of Article 28. On the face of it, this should be quite simple, but there are complexities. For example, while it is reasonably clear what is meant by the requirement to stipulate that the Processor should process the Personal Data only on the documented instructions from the Controller, it is not specified in GDPR how detailed or precise these instructions need to be, nor what the Processor should do where it has notified the Controller that it considers the instructions to be inconsistent with GDPR. Therefore, we often see parties negotiating modifications to the Article 28 obligations which seek to clarify or expand the mandatory terms.
  3. There is then the third type of data obligations: those which are entirely discretionary and that one party may look to impose on the other to reallocate risk or reputation exposure. These range from the straightforward to the more specialised, but in our experience typically include the following:
  • allocating specific responsibility for complying with security obligations or shifting the onus on to one party to warrant the ‘appropriateness’ of such measures;
  • warranties from the Controller that the processing of data by the Processor shall be lawful;
  • vendors seeking the ability to update the GDPR related terms unilaterally with automatic effect in the event of a change in law;
  • the Processor requiring payment from the Controller for assistance given to the Controller in particular in relation to audits and data subject requests or for compliance with any instructions that would require a change to the services; and
  • indemnities given by one party to the other for losses suffered as a result of breach of GDPR.

What are the implications of these three sources of liability when negotiating a contract? The main takeaway is that if you are looking at ways to limit financial exposure from GDPR in the contract, the best way is to minimise any gold-plating to source 2 above or the inclusion of any additional obligations of type 3 above. In other words, other than the requirements which are imposed by the GDPR itself or which need to be included in the contract under Article 28, the more either party can resist the discretionary additional terms the more it will reduce its exposure. The battle ground in negotiations is frequently security given that GDPR sets a vague and ever changing “state of the art” standard. Vendors not surprisingly favour committing to a finite list of security controls with additions to be agreed for a cost through change control. Customers on the other hand argue that as this is a legal requirement, the vendor should reflect in the contract what they are already subject to directly by virtue of Article 32 GDPR. Silicon Valley vendors are winning the finite control argument. However vendors with less leverage often have to accept a more open ended commitment to maintain state of the art security. This can prove to be extremely costly given the pace of change in cyber security technologies. What is strong encryption today may be easily hacked in a year’s time – and encryption upgrades (just one element of good security) don’t come cheap.

Types of liability

Now that we have looked at the sources of obligations for GDPR, there are three different forms of liability which can arise, and each of these has to be considered separately:

  1. First, both Controllers and Processors can now be directly liable for fines for breach of GDPR (whereas previously only Controllers were liable). These fines are in theory limited by reference to turnover (either (i) to 4% of total worldwide turnover or €20 million, whichever is greater, for certain breaches, including breaches of Articles 5 and 7; or (ii) to 2% of turnover or €10 million, whichever is greater, for other breaches including of Article 32). However, in practice, these fines are often viewed as involving large enough sums to be troubling and to need limiting. While many contracts seek to include such fines within the caps/limitations of liability, there is doubt as to how effective that would be in practice, for reasons we will discuss below.
  2. In addition, both Controllers and Processors can also be subject to direct claims made by data subjects for breaches of GDPR obligations. There is no need for claimants to prove financial loss; mere distress is sufficient. GDPR also makes it easier for group litigation. Group litigation risk is real with the recent Morrisons decision in the UK a notable recent example. There is no limit to such claims, but each party can effectively try to limit its exposure by having the other party indemnify them for loss suffered as a result. We will also consider below how effective these indemnities are.
  3. Controllers and Processors can also face contractual liability from the other party under the express additional terms of the contract dealing with data protection. Given these obligations are created by the contract, they can also be limited or excluded by other provisions of the contract, and such limitations will generally be effective.

Article 82 and 83 of the GDPR respectively give data subjects the right to receive compensation if they have suffered material or non-material damage as a result of a GDPR infringement and give the Supervisory Authorities the ability to levy fines based on the Controller and Processor’s conduct. This is one of two reasons for addressing each type of liability separately, and for the complexity of the legal position. The second reason is a legal principle which goes by a latin moniker – “ex turpi causa non oritur actio” – which means that someone cannot raise a claim against another based on their own misdeeds. Taken together, this means that while the contractual caps and exclusions will have a bearing on the allocation of liability, they won’t necessarily have the final word.

  • In relation to Article 82, this states that persons who have suffered damage as a result of a GDPR infringement can bring a claim to receive compensation from the Controller or Processor. While the primary obligation is on the Controller, the Processor can also be held liable if it has not complied with its specific GDPR obligations or has acted outside the lawful instructions of the Controller (which is why it is particularly important to clearly define such instructions). As, under GDPR, the claim should follow the blame, any indemnity which tries to limit liability or pass it to the other party when the first party was in fact to blame does not sit well with Article 82 and, (if the claim is based on a party’s deliberately or negligently wrongful acts) offends the “ex turpi causa” doctrine, and therefore runs the risk of being unenforceable. This is not to say that such indemnities should not be included, but rather it is an open question as to whether courts would give effect to them other than in circumstances where the claim which is being indemnified has been caused by the indemnifying party or for which the indemnifying party has accepted responsibility elsewhere under the contract.
  • Similarly, when it comes to fines pursuant to Article 83, under GDPR these should also be based on conduct. Therefore, it is to be expected that the Supervisory Authority will issue fines which take into account which party has been at fault. In such cases, there will be limited grounds for seeking to recover the fines from the other party – perhaps only where the Controller can claim that it was not at fault and has still been fined, such as where the Controller outsources to the Processor something which is ultimately the Controller’s responsibility under GDPR (e.g. a mechanism for delivering privacy notices). As such, seeking to limit exposure to fines or to expressly include fines as being recoverable from the other party as direct losses may not give the complete comfort it would seem to offer.

Therefore, while caps/exclusions of liability for the discretional obligations are legitimate and likely to be upheld, there is more doubt about exclusions/indemnities for fines and data subject claims levied in relation to breaches of the type 1 or type 2 obligations outlined above. That said, such provisions do no harm and will be applicable in a limited sub-set of scenarios so are worthwhile including, but it would be unwise for someone negotiating these to express confidence that they will apply to limit their liability fully in circumstances where they themselves have been at fault.

Limits of Liability

Finally, turning to the actual drafting of the financial caps and other limitations and exclusions of liability in circumstances where they are appropriate, the position we are seeing in the market following GDPR is now quite different from under the Data Protection Act 1998. It is less usual now to see a blanket statement of unlimited liability for breach of the data protection provisions of the contract, in the same way as you will generally still see for breaches of confidentiality. What is seen generally breaks down into the following:

(a) a financial cap on liability which is different from and separate to the general cap for contractual damages. The amount we see typically varies from low millions of pounds to many multiples of the contract value, depending on the nature of the data and the processing and the bargaining power of the parties;

(b) an exclusion of indirect losses; and

(c) a list of specific losses which are deemed to be direct and therefore recoverable, which may include internal additional costs, remediation efforts with data subjects, ex-gratia compensation and costs incurred generally in dealing with the fall-out from data breaches. This list often includes claims made by data subjects and fines, but for the reasons given above, it is doubtful whether these will be effective in situations where the party seeking to claim the amounts has caused the damage or breach to arise. For that reason, we would recommend splitting out the data subject claims and fines from the other losses that may be suffered, so that if these are ineffective the whole clause will not fall away.

GDPR creates many open legal questions and the ability to recover fines and compensation awards from a contract counter-party or insurer are good examples. One interesting issue is whether the courts will differentiate between direct liability and vicarious liability when determining whether or not to enforce a contractual indemnity. In cases where there is no finding of direct liability for an employer (as was the case in Morrisons) and liability arises strictly on the basis of vicarious liability of the employer for the acts of its employees, the courts may be more willing to allow recovery. This should provide some comfort for organisations grappling with the challenge of insider threat. It is also an illustration of why there is value in negotiating appropriate indemnity protection.

Conclusion

Limiting financial liability under GDPR has been made much more complex than under the Data Protection Act 1998, both because the nature of the obligations placed on both parties has changed and because the consequences of breaches are much more serious. Parties looking to limit their exposure should be realistic and not assume that it will be either possible or desirable to simply pass liability to the other party under the contract in all circumstances, instead, they will need to take a more balanced approach to liability, based on the terms of GDPR and who has caused the loss in question to arise.