One of the most challenging aspects of practising privacy law is the number of times data protection theory bumps up against data protection reality. In theory, theory and practice are the same, the saying goes. In practice, however…
Nowhere is this more apparent than in the context of contractual negotiations. You think your supplier is a data controller; they insist they’re a data processor. You want to be notified of data breaches immediately; they will only agree to notification as soon as reasonably practicable. You want them to get your consent before engaging any new subprocessor; they tell you they have to have subcontracting freedom. You want the right to conduct on-site audits; they will only provide summary third party audit reports.
The list goes on, and most of these debates aren’t new - privacy professionals have been having them for years. Many of us have come to learn that you can’t let the great be the enemy of the good, and so accept compromises in our contractual negotiations. What is new, however, is the growing insistence from controllers on unlimited liability clauses in contracts with their data processors.
Liability demands under GDPR contracts
Why the sudden demand for unlimited liability? Historically, data protection liability in your average commercial contract has either been capped some multiple of contract value (2x, 3x, 4x or thereabouts) or has been agreed upon by reference to regulators’ ability to fine (£500k is a fairly common value in UK contracts simply because, to date, that’s been the most the UK ICO can fine). Sometimes, in intense and risky negotiations, you might see higher - but seldom more than £1m to £2m at the outside.
But then came along the GDPR, with its fines of up to 4% of annual worldwide turnover, and the contracting world turned upside down. Controllers, wary that under the current law they can be held liable for breaches caused by their processors, look forward and worry that the same may be true under the GDPR - i.e. that they could be liable for 4% fines even when the breach is caused by their processor, not by them.
The result has been contracting chaos. Suppliers, particularly those offering commoditised cloud services to tens of thousands of customers, suddenly find themselves faced with requests to agree to unlimited liability - something, in the interests of prudent risk management, they could never agree to do. Customers, on the other hand, find themselves frustrated when procuring services from suppliers who, they feel, are not offering adequate liability caps in light of the greater exposure under the GDPR.
But how well-founded are these requests for unlimited liability? After all, as many processors will point out, they can be held directly liable by data protection authorities (DPAs) under the GDPR - so, surely, if they are in breach the DPAs will pursue them directly, rather than going after their controller customers; going after the controller for a processor’s breach would seem akin to punishing a child for the sins of its father. Indeed, when my partner Renzo Marchini posted on this issue on LinkedIn the other day, respondents to his post made just this point - some making erudite arguments under competition and criminal laws about why this should / would / could not happen.
The problem, though, is that GDPR is eerily quiet on this issue. We know under the current Directive that a controller can be liable for the failings of its processor. We know, too, that a controller is ultimately “accountable” under the GDPR for compliance with the data protection principles (art 5(2), if you’re interested). We also know that there’s a risk that if a processor screws-up then the controller will be told it didn’t exercise sufficient due diligence over the processor, didn’t have good enough contract terms, or simply didn’t monitor its compliance sufficiently - and these are all potential grounds for DPA fines under article 83(3). All roads seem to point to potential liability for the controller if its processor doesn’t behave.
It’s not just DPA fines that controllers worry about though. There’s also the civil liability regime. The GDPR says that individuals can claim compensation for damage suffered - material (e.g. financial) or non-material (e.g. emotional distress) - caused by unlawful processing. Where a breach occurs due to unlawful processing by a processor, the controller is jointly and severally liable for the damage if it, too, was in some way responsible - no matter how minor its responsibility. Only if the controller is completely fault-free can it avoid liability for a breach caused by its processor (art 82(3)). (It’s worth also stating that this arrangement works in reverse too - i.e. a processor can be liable for breaches caused by its controller.)
Managing liability discussions
So where does that leave things? Ultimately, controllers are going to demand, and processors are going to need to accept, higher liability caps in contracts. It’s the question of how much liability that will become key. If you find yourself having to debate this across a negotiation table, here are few considerations to keep in mind:
1. What level of liability cap do you really need? While we all know that the DPAs can, in theory, fine up to 4% annual worldwide turnover, the likelihood of them doing so is very slim and that level of fine would only be seen in the most egregious data protection breaches. That risk can also to a large degree be managed by the controller by going through a thorough due diligence process, selecting a reputable supplier, and instructing that supplier to engage only in lawful processing activities. Higher value liability caps are likely only to be needed where the data, or the processing operations, are of a particularly sensitive nature. Suppliers are very unlikely to agree to significant liability caps in the majority of cases, so agree instead on a level of liability that represents a realistic reflection of the ‘riskiness’ of the processing.
2. What level of insurance do you have in place? If you’re a supplier, time to dust off those cybersecurity insurance policies and check them out - or go and get one if you haven’t already. Don’t look at just the value of the insurance you have in place, but consider too its scope - does it protect only against security incidents or does it extend to wider data protection regulatory breaches? Does it insure you against contractual claims? Are you insured on a ‘per claim’ or ‘all claims’ basis? If the policy was taken out before GDPR, does it need re-brokering in light of GDPR risks? Ultimately, as a supplier, you don’t want to expose your business to significant risks for which you may not have adequate insurance coverage. Equally, as a customer, there’s no point having enormous contractual liability coverage from your supplier only to find it is uninsured and will be bankrupted - and so unable to pay you - the first time you make a claim.
3. What are the liability triggers? Another important consideration is what triggers must exist for a customer to make a contractual claim against its processor for a data protection breach. If those triggers are carefully managed, a supplier may be prepared to agree to higher liability if it is not having to constantly look over its shoulder for every minor mishap. For example, if a customer requires prior consent every time a supplier wants to appoint a new subprocessor, the supplier may be reluctant to agree to a significant liability cap for fear that a simple failure to notify its customer about a new subprocessor may expose it to contractual liability. Conversely, if the supplier is given a general consent to engage subprocessors, it may accept a little more liability risk. Similarly, if there is a good dispute resolution clause in the agreement, then suppliers may feel better able to manage and resolve contractual complaints without fear that a customer will turn immediately to litigation - again encouraging it to accept a greater liability cap.
4. You don’t have to ask for, or give, indemnities. It’s very common for many data processing agreements these days to include indemnities, and the scope of some of these indemnities can be very wide indeed. An indemnity is essentially a contractual right to financial recovery on the occurrence of certain trigger events (so see point 3 above!), and recovery under an indemnity can be significantly greater than recovery under court-awarded damages. It’s very common to see wide-ranging indemnities in US contracts, but their use is far less common in European contracts. For that reason, if you’re a supplier, you might want to think about taking data protection indemnities out of your standard terms and offer them only as a fallback in negotiations; equally, as a customer, remember that you don’t need an indemnity to recover damages from your supplier and so removing an indemnity could be a lever for agreeing a higher liability cap.
5. What is the market standard? “What does everyone else do?” It’s a question that lawyers are asked so often. “I don’t want to offer any more liability than anyone else.” The truth is, right now, we don’t really know. Because the GDPR has not yet come into force, market practice around liability caps hasn’t yet arisen - but, rest assured, it will do, and 18 - 24 months from now, what is a ‘standard’ liability cap offering will be much clearer. Keep a watching brief on what your competitors are doing, and speak to peers whenever you can.
6. Context is king! There are so many other relevant considerations to take into account that it’s hard to enumerate them here. But consider too things like the life of the contract (easier to justify a higher cap for a long term contract than a short term contract), contract price (remembering that services are typically priced on a certain assumption of liability - and if liability goes up so too does price), and the degree of reciprocity in the contract (if you insist on unlimited liability from your processor, just remember it may well turn around and insist on unlimited liability from you too!)
For now, working our way through liability issues under the GDPR contracts is a collective challenge for all of us. If you have any other thoughts on how to address some of these issues, then please feel free to debate them with me on e-mail (phil.lee@fieldfisher.com).