More than GDPR: Brexit, Safe Harbour and Privacy Shield, and the Network and Information Systems Security Directive
Part three: Pinsent Masons' consultant lawyer Kuan Hon explains how a variety of issues - not just the GDPR - is set to complicate cloud computing and data protection
It always looked most likely that, Brexit or not, the GDPR would apply and be applied to the UK - if only because it would apply directly in all EU member states before the UK left and, in any case, organisations doing business in the EU or with EU individuals will have to comply with the GDPR.
But the government statement in mid-October made it clear that it is planning to adopt GDPR into British law, post-Brexit.
In other words, there really is no escape from GDPR, so organisations should start preparing sooner rather than later.
What is less clear is Privacy Shield, the replacement for the Safe Harbour agreement, which was ruled unlawful by the Court of Justice of the European Union (CJEU) in October 2015.
The background is that under EU data protection law, you're not allowed to "transfer" personal data outside of the European Economic Area (EEA) unless you use a recognised tool or an exception. What is meant by "transfer" is very broad. Mostly, it means shifting the physical location of personal data outside of the EEA.
But also, if staff or contractors have remote access from outside the EEA (say, from a support centre in India) to personal data that's located in the EEA, that's generally considered to be a "transfer". So a lot of situations are considered a transfer under GDPR.
The Safe Harbour scheme was designed to allow transfers to the US. Unfortunately for organisations that have US dealings, under the CJEU decision last year it's been killed so, after six months or so of feverish negotiation (to conclude long-standing discussions that started in 2013), the Privacy Shield scheme was adopted to replace Safe Harbour and enable transfers to the US.
That means that you can safely transfer personal data to organisations in the US that have subscribed to Privacy Shield - but not all organisations are eligible. Banks and telcos aren't eligible, for example. So it's not as big a pool as you'd like.
A lot of cloud providers have also signed up to the Privacy Shield, including Amazon, Google, IBM, Microsoft, Salesforce and Workday, but there is still an issue of "onward transfers" to a sub-processor that has to be worked out.
End of story? Not quite.
Privacy Shield could still be challenged, just as Safe Harbour was, and struck down by the CJEU. Certainly, privacy activists are no happier with Privacy Shield than they were with Safe Harbour and, indeed, it is already being challenged by groups like Digital Rights Ireland, the group which previously managed to persuade the CJEU to invalidate the EU Data Retention Directive.
So it's shaky ground at the moment, but it's difficult for organisations to know what else to do.
There are some other legally compliant ways to transfer personal data to the US, most commonly under what's known as standard contractual clauses or model clauses. Some cloud providers actually offer them as an opt-in.
A number of processors don't like model clauses as they, for example, offer audit rights to the controller or its data protection authority, so in some ways they are tighter than the Privacy Shield. But check with the cloud provider first as some offer them and some don't.
Another issue is that model clauses are also going to be challenged before the CJEU, so their validity may be in doubt as well, at least for transfers to the US.
Some organisations have decided that it's too difficult and that they will just keep personal data in the EU and leave it at that. However, unless you're running systems on IaaS and PaaS, most service providers don't really provide much choice as to where your data is actually stored. And with many SaaS services, you can't usually choose your regions or ‘geos'.
And, of course, even if your main data in persistent storage is kept in the EEA, because you've selected the option requiring it to be kept in a particular region, metadata may still be stored outside the EEA, and there might be other data that, for operational purposes, has to be stored globally or replicated globally.
But some data protection authorities didn't think that Safe Harbour, even before its invalidation, covered personal data stored outside the US. However, US cloud providers with global services might well process some personal data outside both EEA and US data centres.
So, for all of these reasons, some cloud providers offer model clauses as well. Not just because they don't have Privacy Shield, but because there's other data that can be considered personal data that could be kept outside the EEA, but not within the Shield's coverage.
Next page: Risks to Privacy Shield and the forthcoming Network and Information Systems Security (NIS) Directive
More than GDPR: Brexit, Safe Harbour and Privacy Shield, and the Network and Information Systems Security Directive
Part three: Pinsent Masons' consultant lawyer Kuan Hon explains how a variety of issues - not just the GDPR - is set to complicate cloud computing and data protection
Privacy Shield, too, will need to be updated to take account of the GDPR, so it is almost certainly going to be subject to amendment, even if the CJEU doesn't strike it down like it did with Safe Harbour. The Privacy Shield is due for its first review by the middle of 2017.
However, GDPR codes and certifications, referenced earlier, could help when they are approved. If an organisation has got an approved code or certification, whether it is a controller or processor, then personal data can be transferred to it under the GDPR. That's another mechanism beyond Privacy Shield and model clauses that could work.
If an organisation has signed up to a certification or code that has been approved under the GDPR, you can transfer to them in any country, not just the US. Again, that makes these codes and certifications well worth investigating - when they become available.
The NIS directive
If all that wasn't enough, there's also the Network and Information Systems Security (NIS) Directive (NISD) to consider.
It will impose security obligations and incident-notification obligations for all data, not just personal data, on two classes: operators of essential services, basically critical infrastructure, like banks, transport, utilities and healthcare; and, digital service providers.
The latter will encompass cloud providers, including SaaS providers, search engines, and online marketplaces. They are going to have security obligations and incident reporting obligations, albeit with a slightly lighter touch than for critical infrastructure organisations.
Countries could have tougher laws for essential services operators if they want to, but they are not allowed to impose tighter laws on digital service providers unless it's for law enforcement or national security purposes.
This directive will also come into force in 2018 - which will be a busy year - but it's a directive not a regulation, so it's up to individual member states to pass their own laws, which could well interpret or implement the directive differently. EU member states will also have to identify who are their essential operators nationally.
That means that the same bank's service could be considered essential in one country, but not essential in another. It all depends on the extent of operators' businesses in different countries and what the individual country decides.
The requirements for security when you're considered an essential operator under NISD, would also include when you're using cloud. What is more, those security requirements under NISD are slightly different from the GDPR's security requirements.
Again, you will have to make sure that your contract enables you to comply, by imposing the relevant security obligations on your cloud provider - which, again, may be difficult under the cloud provider's standard terms. You will have to check those terms carefully and negotiate them if necessary, if your organisation is designated as an essential services operator.
Incident notification requirements are also not the same as under GDPR. It's "incidents", not "personal data breaches", that must be notified, particularly incidents affecting availability and business continuity. The relevance of cloud here is that if you're an essential services operator and you're relying on a cloud service to provide an essential service, then you're legally obliged to notify any incident affecting the cloud service if it has a "significant" impact on the continuity of your essential service.
There is no direct obligation on the cloud provider here to notify its customers (unlike under GDPR). So, if your organisation is relying on cloud for providing its critical infrastructure service, you have got to make sure that you change your contracts with your cloud providers to require them to notify you of incidents affecting them, in order for you to be able to fulfil your organisation's own notification duties under NISD.
And the relevant authority that you have to notify under NISD could be different from the authority that you have to notify under GDPR.
What about Brexit?
The NISD is a directive, not a regulation. This requires national member laws to bring it into force and so the position here is a bit more uncertain, even though the UK is unlikely to have left the EU by the time member states are supposed to pass those national laws. But given the importance of cyber security and that more and more countries are passing cyber security laws, the UK will probably pass similar laws.
Besides, every indication from government so far has been that it will be business as usual until well after the UK has formally left the EU.
So, the message for the NIS Directive is the same as for the GDPR: you've got to start preparing now.
You have got to make sure that your contracts are right, that you can actually provide the security that is required, that you can notify incidents as required. You will almost certainly have to talk to your service providers, and not just any cloud companies you use.
Generally, you will need to update your systems and business processes so that you can have the right security level that's required under both of these laws, and also be able to detect and notify incidents as required.
Also, keep an eye out for what the UK is going to be doing under the NIS Directive as that remains more up in the air. Keep an eye out for official EU rules and guidance that will be coming out around GDPR, NISD and, of course, approved codes and certifications.
Indeed, there is a window of opportunity for the industry to help determine the content and shape of these tools, like standard contract clauses or certifications, which you may want to investigate with relevant industry bodies or business associations.
So, the key message is: Start now. The prospect of huge fines under GDPR alone ought to get the rapt attention of the board because the buck (no longer the euro?) will, literally, stop with them.
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.