Could cloud vendors dump big customers to avoid shared liability once GDPR is enacted?

Fieldfisher GDPR expert Kuan Hon explains the possibilities, with potential fines for large firms set to run into billions when the new law comes into force next year

Most cloud contracts include shared liability clauses, and with the fines under the impending General Data Protection Regulation (GDPR) set at up to four per cent of annual global turnover, the risks to a cloud vendor if it leaks data from a large customer could be ruinous.

Could that mean that cloud providers start to dump their largest customers in an effort to reduce their risk, as May 2018, the date when the GDPR will come into force, nears?

Computing spoke to Kuan Hon, Director, Privacy, Security & Information, at privacy law experts Fieldfisher to find out.

Kuan Hon:

The short answer to the question is, "It's unlikely - but watch this space". The longer answer is, "It's complicated!"

Let's start with a hosting provider's position under the GDPR. If it hosts personal data, it's treated at least as what's called a "processor". In some cases it might even be a "controller" of the personal data - the boundary can be blurry sometimes.

Why does the difference matter? Legal risk, and therefore financial and reputational risk.

Generally, controllers - who control the "purposes and means" of processing the personal data - have more legal obligations and liabilities than processors, they're on the legal hook for more things. Controllers (e.g. customers of hosting providers), can use processors (e.g hosting providers) to process, e.g. host, store, or analyse, personal data for the controller. But the buck, or should I say euro, stops with the controller - it can't outsource its legal responsibilities or liabilities to the processor. If there's a problem with the processor, ultimately the controller could still get fined or sued.

Processors are supposed to process the personal data only as the controller instructs, and not for the processor's own purposes. They have legal obligations to the controller (the provider's customer) under their contract with the controller. But, with hosting providers, the contract is almost always on the provider's standard terms. The hosting customer has to click to accept the provider's terms before it can use the hosting service, and it's rare that customers can negotiate the provider's standard terms.

How does the GDPR change all this? In three ways.

And these are relevant to all service providers who host, analyse or otherwise handle any personal data - not just hosting providers.

Providers directly on the legal hook - fines

First, post-GDPR processors will, for the first time, automatically have some direct obligations and liabilities. As well as the risk of being sued by controller customers under their contracts with them, processors could get fined by data protection regulators for breaching their direct obligations. These include obligations on security, and on international transfers (if they host personal data outside the European Economic Area or allow remote access by staff or contractors from outside the EEA, without using a mechanism recognised by the GDPR like the EU-US Privacy Shield - see my book on transfers and cloud, limited time discount available!).

More contractual risks for providers

Second, contracts between controllers and processors - including hosting providers' standard terms - will, from 25 May 2018 (when the GDPR applies), have to include certain minimum terms that commit the processor to a long list of requirements, for breach of which they can get sued by their customers. In my personal view, and I know many others agree, both sides (not just the controller) could face a 2 per cent turnover/€10m fine if they don't put in place a compliant contract by that date.

Pre-GDPR, the only requirement was for the provider to commit in its contract with the customer to take appropriate security measures.

The new GDPR requirements were designed to better protect individuals whose personal data will be held by providers. But they're hard to apply in cloud, because they don't take into account the commoditised, hyperscale nature of most cloud services, where the provider won't actually know what type of data (personal data, non-personal data) their customers choose to store on the hosting service, e.g. on audit rights - see my article.

I did point out the potential problems while the GDPR was going through, as lead author of a paper for an EU cloud project, but the GDPR's wording never got adapted to accommodate cloud. The UK data protection regulator, the Information Commissioner, recently consulted on its guidance about controller/processor contracts and liability, but the guidance doesn't really deal with the uncertainties or tricky practical issues - on which see my IAPP and (longer) SCL articles.

Many big cloud providers have now come out with new standard terms that try to be GDPR-compliant while being practicable for cloud. However, because the new requirements increase providers' contractual commitments, for which the provider could get sued by customers, pricing may go up generally, or extra fees will be charged by providers if called on to meet some of the new requirements - or both. But I should point out that the GDPR doesn't say that shared liability clauses must be included in provider contracts. I'll say more about that in a minute.

[Turn to page 2]

Could cloud vendors dump big customers to avoid shared liability once GDPR is enacted?

Fieldfisher GDPR expert Kuan Hon explains the possibilities, with potential fines for large firms set to run into billions when the new law comes into force next year

New exposure - compensation claims and supply chain risk

Third, compensation claims and supply chain risk. These are linked. Under the GDPR, if the GDPR was infringed, e.g. a breach affecting personal data because of inadequate security measures, then anyone who suffers damage - including emotional distress, not just financial damage - can claim compensation for the damage suffered from "the controller or the processor". I mention security as an example, and it's a technology supply chain risk, but it's not the only possible GDPR breach.

The GDPR also allows EU privacy NGOs to take action, e.g. sue, on behalf of individuals - what I call "quasi-class actions" (my unofficial term). The UK Data Protection Bill that's being debated at the moment only allows this action where the NGO has been specifically authorised by the individuals (e.g. after a public call to find people affected by the breach), but other countries could allow it even without the individuals' specific authorisation. The potential total compensation under quasi-class actions could be huge, depending on the number of people affected, maybe even dwarfing regulatory fines in some cases.

Not only will there be exposure to compensation claims, but also exposure to the supply chain. Let me elaborate. Technology supply chains are often complex. For example, in cloud, a customer (controller) could use a SaaS or PaaS provider (processor), but the processor might in turn be using an IaaS or PaaS provider behind the scenes (a sub-processor, or "another processor" as the GDPR puts it).

Compensation claims can be made against processors, like service providers - not just against controllers. This is what I call "choose who to sue". Affected individuals or NGOs might choose to sue a hosting provider because the provider is in their country, or is seen to have bigger pockets (e.g. where the controller, the cloud customer, is just an SME, but the hosting provider is a big cloud provider). Or they could sue the underlying IaaS or PaaS provider, in the example above. Whoever gets sued has to cough up compensation for the entire damage, because the goal is to make sure individuals are effectively compensated - and that could be for all affected individuals, if there's a quasi-class action. Whoever gets sued could has the right to claim back compensation from others in the supply chain (e.g. the cloud customer) according to their respective responsibilities for the damage. But that might involve further litigation costs, against the others in the supply chain, and good luck proving who was responsible for what! (unless the original contract set out those responsibilities clearly - which is why you need to get lawyers with GDPR expertise on to your contracts!)

Now, processors have some get-outs if they get sued for compensation. They can escape liability if they've met all their direct GDPR obligations (e.g. on security) and followed all their controller's lawful instructions. They can also escape liability if they can prove that they weren't in any way responsible for the event giving rise to the damage. But, to show that they'd met all their obligations etc., or that they weren't responsible for the event, will all involve time, resources and costs - and in some cases it's difficult if not impossible to prove that you had no responsibility for an incident, if your service was used! It's a bit of a lose-lose situation for processors. So, again, it's important for providers to involve GDPR lawyers to advise on how to record their GDPR compliance (including logs and audit trails), as well as on clear contractual allocation of responsibilities and liabilities. Getting the contract right is probably the most important point.

After all that, finally, I'll get to liability and indemnity clauses in contracts. As I said earlier, hosting contracts are generally offered only on the provider's standard terms. A provider may not want to take on liability through its own standard terms but, because of the GDPR, it has to accept a long list of contractual commitments to its customers, including on security. And, as I've outlined, it's also exposed to compensation claims from individuals/NGOs, plus supply chain risk (it could get sued for something that was really the fault of its customer, or another provider in the supply chain, but it will have to spend money proving that, and might even have to pay full compensation first - the GDPR and guidance just aren't clear on the timing).

So, what's more likely, and this is what some providers are doing, is that providers may want their standard terms to limit their liability to customers. Or they may want indemnities from their customers. In other words, they may state that if the provider gets sued for something that was the fault of the customer, then the provider will have the contractual right to claim reimbursement from the customer, including e.g. its costs of dealing with the compensation claim. Of course, customers may want indemnities from their providers too, and providers from their sub-processors (e.g. underlying IaaS/PaaS providers), all the way up and down the supply chain… There have been, and will be, many arguments about who indemnifies who for exactly what, but much will depend on relative bargaining power and providers' market positioning.

Commercially, the new, admittedly large, risks under the GDPR could conceivably make some providers withdraw from the EU market. But I haven't heard of this happening yet. Realistically, I think the big providers are doing the best they can to minimise their potential liability while complying with the GDPR on the standard terms front and trying to keep customers happy, but we'll have to wait and see what happens. There's too much regulatory uncertainty here, and it will take time for the dust to settle - maybe even a court case to clarify the issues.

Meanwhile, all this presents a great opportunity for insurers. Insurers could offer liability insurance for the entire supply chain, with the customer, provider, sub-providers etc. chipping in on the premiums… (unfortunately there's also uncertainty about whether regulatory fines, as opposed to compensation claims, can be insured against, but that's another matter).

Kuan Hon wishes to state that this constitutes general information, and not legal advice.

Computing has written extensively on GDPR. This page links to our top resources to help get your organisation prepared for the incoming legislation.