How GDPR will weigh on cloud computing providers and impose new breach notification rules

In the first part, we looked at the new obligations and liabilities that will be introduced under GDPR, and how it will affect cloud computing by putting more responsibility (and the prospect of high fines) onto the shoulders of personal-data ‘processors'.

It's not just cloud that is going to be affected and required to have these terms-flowdown arrangements in place for sub-processors.

So, basically, all contracts for personal data processing will have to comply with the GDPR's requirements by 25 May 2018. And both sides of the contract, both controllers and processors, could be subject to a lower tier fine if they have a non-compliant contract. Their contract could be compliant on the 24 May and the next day it's non-compliant.

There is no 'grandfathering' of existing contracts. If you have a contract now that's already running but it's going to run-on beyond 25 May 2018, and you haven't changed it to meet the requirements of GDPR, you could find that you are non-compliant and exposed to a fine from 25 May 2018.

Hopefully, cloud providers will be updating their standard contracts to make them compliant; it is difficult to know how much negotiation is possible. But one thing is definite: because of these flow down requirements it may be impossible for a cloud provider to actually comply with all of these requirements, unless it's one of the giants - one of the Amazons, Googles or Microsofts - because they control the supply chain or they can have the bargaining power to force their subprocessors to accept these flowdown provisions if necessary.

But, you can imagine, if you're a small SaaS provider, and you are trying to negotiate with a large cloud IaaS/PaaS sub-provider, it's going to be hard to get them to accept these extra obligations. Some of them might decide as a commercial matter that they will, but if not it's going to be difficult. And it may be impossible to get a third-party data centre provider to agree the GDPR-required terms, if regulators insist on the flowdown going down all the way.

So, really, I believe this is going to drive business towards the cloud giants (who control their supply chain and are therefore able to comply with the detailed new GDPR requirements), while putting SMEs in a difficult position. Is this consequence really what lawmakers intended when they put those prescriptive contract requirements into the GDPR? Did they fully consider the impact of those requirements on cloud, SMEs, innovation or competitiveness?

And, remember, all this applies also to non-cloud contracts.

But the bottom line is this: If your organisation has ANY contracts involving personal data processing that could expire after 25 May 2018, you've got to take stock; you've got to make sure you can track down those contracts so you can make them compliant, starting negotiation discussions sooner rather than later. If you're entering into new contracts, again, you've got to take account of these issues; you've got to put in the GDPR-compliant terms now, or put in something into the contract to let you change them without penalty.

It's probably better to put the GDPR terms in now, if you can, rather than trying to change them in 2018 when time is running out and you may be in a difficult bargaining position if, in practice, you can't migrate away from a provider in time for 25 May 2018 should negotiations break down.

These extra GDPR requirements have got to go into the contract. That means there will be lots of lively discussion over who's going to pay for the cost, who's going to be responsible for what, who's going to be liable for what and indemnities - who pays up in the event of a GDPR breach if there are fines or compensation claims.

Cloud providers could be directly liable themselves and if somebody sues them, but it was your fault, they are going to want to claim back from whoever is directly responsible - so they will want to spell out who is responsible for want, with clear liability allocation, and indemnities if they get sued or fined for infringements in situations where the cloud customer was more at fault.

And pricing, unfortunately, is probably going to go up to cover the cost of all this, as well as, for cloud providers, to account for their increased liability exposure.

Next page: Security requirements and breach notification

How GDPR will weigh on cloud computing providers and impose new breach notification rules

Security requirements

There are slightly different security requirements under GDPR compared with now. Cloud providers and other processors will have direct security obligations, whereas under the Data Protection Act they don't have direct data protection obligations, only obligations to their controllers under their contracts with them (including security commitments).

The GDPR security obligations themselves - confidentiality, integrity, availability, resilience, business continuity, and regular testing and evaluation - are pretty much security best practices.

The focus on accountability means that in order to show that you're complying, having records and logs will be much more important, so you have got to make sure you have got those records and logs readily to hand when you need them, for example to show a regulator. This will increase the need for logging in the cloud, and access to cloud logs and audit trails.

For breaching security requirements, controllers will be subject to a higher tier fine; processors, the lower tier. If you can show that you have complied or tried your best to comply with the GDPR's security obligations, that might help reduce a fine.

This means that there will be a much increased role for GDPR-approved codes and certifications.

It won't be enough to brandish ISO27001, 27017, 27018 or any other generalised industry standard. It's got to be a standard that has been approved for GDPR purposes under a particular process - which will be different for codes of conduct and certifications.

The details of these processes aren't available yet and we don't know what exactly the requirements will be, which codes and certifications will be approved, or who will be approving them. But if you, your processor or your cloud processor sign-up to one of these, when they have been approved, it will help to show that your organisation is compliant and, perhaps, reduce the size of fines if there is a breach. For example, if your processor has a GDPR-approved certification or code, your organisation could point to that certification or code as "an element" to demonstrate compliance with your due diligence obligation.

There will, however, be an opportunity for industry to put forward sector-specific codes or certifications for approval.

Breach notification

For the first time in the EU for personal data, there will be general breach notification obligations. At the moment, only telcos have to notify personal data breaches.

The controller organisation is going to have to notify its supervisory authority, which in the UK will be the ICO. In some circumstances it must also notify individuals, the data subjects, who have been affected.

And processors, including cloud providers, are going to have to notify their controllers too.

But it's only about what's defined as a "personal data breach". That means that if there is a confidentiality or integrity breach, notification will be a legal requirement. But breaches that only affect availability need not be notified.

Also, if you're supposed to notify a breach and you don't, you can get fined, albeit at the lower tier - but that's still up to a maximum of two per cent of turnover or €10m, if higher.

To sum up, because cloud providers and other processors will have new obligations and liabilities, they are going to want to change their contracts. And it won't just be cloud - other vendors who process personal data will want to change their contracts in relation to responsibility, liability, indemnities, pricing and so on, so check them carefully before signing.

Both controllers and processors will have an interest in changing contracts, because they could be fined if they have a non-compliant contract. Again, cloud computing usually involves standardised terms so we'll have to see what the providers come up with.

Organisations will also have to examine and re-engineer their systems and processes as well to make sure they can comply with GDPR. This involves not just things like privacy by design and by default (which includes designing products and services with security baked-in from the start) but also, in some situations, you might have to conduct a data protection impact assessment, including regarding security, and your organisation's ability to detect and notify breaches.

And finally, again, codes or certifications will have a much increased role.

Next: In part three, we'll look at Brexit, Safe Harbour and the Privacy Shield - and the Network and Information Systems Security Directive.

Kuan Hon is a consultant lawyer for Pinsent Masons focusing on data protection law. She is also a senior researcher, project co-ordinator and research assistant of the Cloud Computing Project at Queen Mary University of London

Disclaimer: This article does not constitute legal advice. Specific legal advice should be taken before acting on any of the topics covered.