Data controllers: be prepared. Your service providers (if well-advised) will want to negotiate or renegotiate your contracts.
Why? The General Data Protection Regulation (GDPR). This would make service providers and other data processors directly liable, across the European Economic Area, for security and certain other data protection-related matters. The EU institutions, each with their own version of the text and currently in horse-trading ‘trilogue’ negotiations, aim to agree and adopt GDPR by the end of 2015. That’s not far off, in the scheme of things, although there should be a two-year lead time before the GDPR takes effect (directly) in all EEA Member States.
What’s the big difference? Under the current Data Protection Directive, only data controllers have obligations and liabilities under data protection laws, in most Member States (although in a few, such as Ireland, processors do have direct liabilities under national implementing laws). Controllers determine the purposes and means of processing personal data; processors are engaged by controllers to process personal data on their behalf, i.e. service providers. A controller must put in place a contract (processor agreement, or Article 17 agreement) with its processor, requiring the processor to process personal data only in accordance with the controller’s instructions, and to implement certain security measures. The controller also has to ensure the processor’s compliance with those measures.
But that’s only a few new obligations for processors, right? Well… not necessarily. Thing is, there are major differences between the European Parliament’s and Council of Ministers’ texts, in several respects – including regarding Article 77, compensation for any person who’s suffered damage as a result of: processing that’s not compliant with the GDPR (Council’s version), or unlawful processing or ‘action incompatible with’ the GDPR (Parliament). Under Parliament’s text, that person has the right to claim compensation from the processor for the damage suffered, instead of the controller, if they wish. If more than one ‘controller or processor’ is ‘involved’ in the processing, each is jointly and severally liable for the entire amount of the damage, unless they have an ‘appropriate written agreement’ determining responsibilities ‘pursuant to Article 24’.
So there’s two points here. Firstly, a processor could get sued, perhaps because it’s seen as bigger (what I term the phenomenon of the ‘princelier-pocketed processor’) – even if the damage was the controller’s fault. The (now less princely-pocketed) processor will then have to try to claim from the controller. There’s no allocation of liability based on fault, not at all: indeed the Commission, who proposed the original GDPR, intended liability to be strict,[1] because the policy aim was to ensure that the person who’s been damaged can get compensation in full, from whoever. Secondly, Article 24 applies only to joint controllers, so what’s a poor processor to do? Become a controller, so that it can negotiate an Article 24 agreement with the ‘real’ controller to allocate responsibilities according to fault? That doesn’t seem right, and I’d suggest this is a drafting glitch on the part of Parliament.
What about the Council’s text? It would certainly be better for processors. But here’s where you’ll have to indulge me (or look away now). Some heavy lifting on Chapter VIII (remedies, liabilities and sanctions) happened within the Council internally in late 2013.[2] Then nothing for ages. The 16 March 2015 version of Article 77[3] was identical to the one in the December 2014 version of the Council’s draft text.[4] However, there was then a sudden flurry of Council activity on Chapter VIII in late March-May 2015. So I’d like to think that maybe my talk of 9 March in Brussels on cloud providers and GDPR,[5] where some Commission officials and industry attendees were present, might have played a small part in triggering another look at Chapter VIII, who knows…[6]
Whatever the reason for the Council’s revisiting of Chapter VIII, its (internally-agreed) version is now much more measured as regards processors. A processor would be liable only where ‘it has not complied with obligations of this Regulation specifically directed to processors or acted outside or contrary to lawful instructions of the controller’ (Article 77(2)) – in which case it could still be sued for the entire damage. A controller or processor would be able to escape liability on proving that it’s ‘not in any way responsible for the event giving rise to the damage’ (Article 77(3)). This is still a big ask, as even partial responsibility for the ‘event’ could land a processor with the full bill, responsibility for the event isn’t always the same as responsibility for the damage, and Article 77(2) doesn’t require any causation: if a processor has breached GDPR processor obligations in any way or failed to follow lawful controller instructions, seemingly it’s back on the hook, even if its breach or failure was minor and had nothing to do with the particular damage for which compensation is claimed. At least a processor which has paid ‘full compensation’ for the damage would be entitled to claim back a share from other controllers and processors involved, ‘corresponding to their part of responsibility for the damage’ (Article 77(5)). But working out who’s responsible for what part of the damage won’t be easy. We don’t know yet whose approach will prevail in trilogue. But processors will certainly want detailed liability allocation and indemnity provisions in their contracts with controllers.
Where can processors be sued?
As clarified by the Council’s Article 77(6), in any Member State where it has an ‘establishment’[7] or (with a get-out for public authorities) where the data subject has their ‘habitual residence’.
What powers would data protection authorities (DPAs) have against processors?
Pretty much the same as they’d have against controllers. I’d highlight powers to obtain information and conduct investigatory audits, including access to ‘any premises’ of processors, and ‘any data processing equipment and means’ (Article 53). The famously huge fines, which you’ll know about if you’ve not been living under a rock since 2012, could be imposed on processors as well as controllers.
When will processors be subject to GDPR?
In many situations. Firstly, by having an ‘establishment’ in the EEA and processing personal data ‘in the context of’ that establishment’s activities (Article 3(1)).[8] In light of Google Spain,[9] ‘establishment’ and ‘context’ will be interpreted broadly. It’s not inconceivable that an EEA data centre owned (or maybe just used) by a non-EEA processor could be considered its ‘establishment’ for this purpose. Here’s the kicker. Tentative agreement was reached in trilogue on parts of GDPR, including the provisions on territorial scope.[10] GDPR will apply to the worldwide processing of controllers or processors caught by the ‘establishment’/’context’ ground.
It gets worse for processors not ‘established’ in the EU. If personal data of data subjects ‘present in the Union’ are processed, and the processing activities are ‘related to’ the offering of goods or services to such data subjects (free or paid) or the monitoring of their behaviour (where the behaviour takes place in the EU), the processor – not just controller – is caught. Let’s take a concrete example. Suppose a US business hosts its e-commerce website using a US IaaS or PaaS service, and the business offers goods/services to EU data subjects. Not only is the US business caught (where the policy concern is understandable), but also the US cloud provider, which merely provides IT resources for use by its customers, now has to comply with the GDPR in relation to its US and indeed worldwide data processing. That can’t be right (or, as those who use much bigger words than me would say, that seems like regulatory over-reaching). There’s more, but let’s consider another question first.
How will processors be liable?
Let’s count the ways. Security is the main one.[11] Processors as well as controllers must provide a security level ‘appropriate’ to the processing’s risks.[12] However, this means processors will have to conduct risk assessments for each customer and indeed processing. In an infrastructure cloud context, where providers offer commoditised mixed use IT resources for customers’ self-service usage, how can it be workable for providers to customise their security measures for different customers? Could providers simply decide to go for the ‘highest common denominator’ on the security front, raising costs all round?[13] This would lead to what I term the ‘prying processor’, who may have to ask the processor all sorts of questions about the intended processing. If you rent a computer from a rental company, the company isn’t legally required to make sure the computer is secure enough for your use – that’s up to you. But GDPR would effectively impose an obligation like that on infrastructure cloud providers.
There’s another twist. Processors may be liable for implementing security appropriate to the processing risks, even when there’s no controller. Let me elaborate. A person using a processor (eg cloud provider) to process personal data might be exempt from data protection law obligations, ie wouldn’t be considered a controller, due to the processing being purely for their personal household purposes (and similarly for law enforcement or national security purposes). But that person’s processor would still be caught by GDPR. This is a biggie. A consumer webmail or photo-sharing service, for example, will be subject to GDPR’s processor obligations, including on security. What if a consumer’s personal data is stolen from the service because the consumer used a weak password or succumbed to a phishing attack, ie it was the user’s fault (not the provider’s)? The processor may still have to prove that it wasn’t responsible for the ‘event’. And remember, a consumer could process not only their own personal data but other people’s, who could sue the princelier-pocketed processor rather than the consumer.
What other obligations would be imposed on processors?
Restrictions on international transfers, tentatively agreed in trilogue. Also, requirements on record-keeping, and (if Parliament has its way) data protection by design and default, and appointment of data protection officers. Some of Parliament’s obligations are imposed on controllers ‘or processors’, but exactly when should these obligations be discharged by processors in lieu of controllers, e.g. data protection impact assessments and prior consultation of DPAs,[14] and risk analysis obligations (which Parliament would introduce)? This really needs to be clarified.
What about processors’ obligations to controllers?
The processor agreement that controllers would have to sign with processors under Article 26 GDPR would much have a longer list of required provisions, going far beyond the processor security measures currently required under Article 17 of the Data Protection Directive. The Council version in particular is very prescriptive: the contract must set out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects. Again, in cloud, this conjures up the prying processor. If you rent a computer, you don’t want to tell the rental company (and it probably doesn’t want to know!) what you’re going to be using it for, what personal data you’ll be processing with it, etc. But you’ll have to if you use infrastructure cloud. And the Council would require audit rights (even onsite inspections? Parliament), and contractual obligations on processors to ‘assist’ controllers’ compliance with controllers‘ own obligations regarding security, security breach notification, data protection impact assessments and prior consultation with DPAs. How’s that going to work in standardised commodity cloud? How far must a cloud provider go to ‘assist’ each customer individually?
What about use of sub-processors?
The GDPR’s requirements on processors’ use of sub-processors echo those in the Article 29 Working Party’s cloud opinion WP196, so it’s going to be hard for SME cloud providers to get their sub-providers (typically large US cloud providers) to agree to the required sub-provider contract obligations. In fact, GDPR (and current interpretations of the Data Protection Directive) would favour the largest cloud providers, who have more control over their supply chain and can implement the detailed requirements insisted upon regarding security, sub-processor contracts etc. Which will be great for those providers, but maybe not so good for a competitive marketplace or consumer choice: have lawmakers really considered these consequences?
Grandfathering
Will existing processor agreements be grandfathered, i.e. allowed to continue? Or will they have to be updated when GDPR takes effect, to comply with the new processor agreement requirements? I suspect there won’t be any grandfathering, as there’s specific provision (under debate) on existing adequacy decisions and the like, but GDPR is silent regarding existing processor agreements. However, processors will want to renegotiate their agreements with controllers anyway, to address the liability problem.
What else?
I’ve saved the best for last – well, nearly. Are you sitting down? Sure? Here we go then. Under the Council’s Article 26(2), ‘The processor shall immediately inform the controller if, in his opinion, an instruction breaches this Regulation or Union or Member State data protection provisions.’ From the way it’s drafted, this isn’t a required contractual term, it seems to be an absolute GDPR obligation on processors. So now we’ll have the ‘policing processor’, too. And it’s not limited to cloud. Any processor, any processor, will have to know all about the GDPR and the data protection laws of the EU and every Member State, and be forced to provide continuing legal advice to its controllers (probably upping its fees accordingly). Surely this is going to be completely unrealistic. But hey, processors will be needing to hire lots of lawyers across the EU…
So what will all this do to cloud?
I’ve been banging on for years[15] about how cloud is different from the 1970s computer bureaux services which the current Data Protection Directive was drafted for (but whose assumptions GDPR would perpetuate), and the need for E-Commerce Directive defences/immunities to apply to personal data and neutral cloud intermediaries unless they have knowledge and control. For example, I don’t think infrastructure cloud providers should have any security obligations if controllers upload encrypted personal data – it’s up to the controller to take steps (eg to backup its data); the provider has no idea what kinds of data were uploaded. I think privacy is very important, but laws need to be sensible, and perceived as sensible and at least attempt to strike a reasonable balance between competing public interests in order to have any chance of being respected and obeyed on the Internet.[16] GDPR’s provisions just aren’t technologically-neutral, requiring customisations which aren’t likely to be possible with commodity cloud, and it seems to cast the net far too widely, while not clarifying sufficiently the allocation of responsibilities and liabilities between controllers and processors. There’s a risk that non-EEA providers could raise prices generally, refuse services to EEA customers, refuse to handle personal data (although they’d still be liable even if the customer promises not to use the service for personal data but lies), at worst close their EEA operations, stop using EEA datacentres or withdraw free services from consumers. All this would have an impact on innovation and availability of services: to what extent has that been considered? Of course, GDPR could just be ignored, if it’s considered to be too wide, particularly as enforcement against non-EEA processors may be problematic in practice, but the prospect of huge fines will certainly focus boardroom minds.
Is it all doom and gloom? Not necessarily. GDPR may pave the way for some business opportunities too. But that’s for another time…
Will GDPR really improve privacy for data subjects? Hmmmm. I shall be diplomatic and say nothing.[17] One thing’s for sure, GDPR will keep lawyers in work for some time to come.
So there you have it. The GDPR will increase focus on processors’ princelier pockets, and usher in the era of the prying processor and the policing processor – as well as lots of contract work for lawyers!
W Kuan Hon is a joint law/computing science PhD student at QMUL, a senior researcher working on cloud law projects at QMUL, and a consultant lawyer to Pinsent Masons. This article is written in a purely personal capacity and should not be blamed on QMUL, Pinsent Masons or any other organisation with whom she may be associated. Thanks to @mcanning for a hint on the title.
This article may be copied/redistributed under a Creative Commons CC-BY-NC 2.0 UK licence https://creativecommons.org/licenses/by-nc-nd/2.0/uk/, attributing Kuan Hon kuan0.com and linking to this article.
[1] 7084/15 fn.134, http://data.consilium.europa.eu/doc/document/ST-7084-2015-INIT/en/pdf
[2] http://data.consilium.europa.eu/doc/document/ST-14863-2013-INIT/en/pdf
http://data.consilium.europa.eu/doc/document/ST-15076-2013-INIT/en/pdf
http://data.consilium.europa.eu/doc/document/ST-14863-2013-REV-1/en/pdf
[3] N.1.
[4] Which echoed Parliament’s in imposing joint and several liability, but at least ‘without prejudice to recourse claims between controllers and processors’.
[5] http://admin.cloudscapeseries.eu/Repository/document/PresentationCSVII/KuanHon_GDPRCloud%20Providers.pdf
[6] Someone from a large technology organisation emailed me afterwards to say ‘I think it’s a good thing to be the ‘scary’ presentation at a cloud conference’, so maybe I did manage to frighten them into reconsidering Chapter VIII!
[7] Which, following Google Spain (Case C-131/12 Google Spain SL and Google Inc. v Agencia Española de Protección de Datos (AEPD) and Mario Costeja González (Grand Chamber), 13.05.2014, ECLI:EU:C:2014:317.), could mean that a non-EEA organisation with a subsidiary in an EEA Member State may be sued directly in that Member State.
[8] What if a processor has ‘establishments’ in more than one Member State? There’s no room to get into the ‘one stop shop’ problems, let’s just say that there will be some! See e.g. http://www.out-law.com/en/articles/2015/march/bureaucracy-will-prevail-in-one-stop-shop-data-protection-regime-uk-and-ireland-warn/
[9] N.7.
[10] Leaked Council document 10680/15, http://www.statewatch.org/news/2015/jul/eu-council-dp-reg-debriefing-trialogue-10680-15.pdf.
[11] See http://www.out-law.com/en/articles/2015/march/data-security-rules-for-data-processors-fail-stated-aim-of-eu-data-protection-reforms-says-expert/ predicting that outsourcing agreements will become more detailed regarding security arrangements. I think they’re going to balloon a lot more than that, as I’ll get to shortly.
[12] It’s deemed to be in the legitimate interest of controllers to process personal data as strictly necessary for network and information security (Rec.39). Processors need to be clearly allowed to do that too.
[13] But at least increasing security all round.
[14] Where processors ‘should assist’ controllers to comply with obligations ‘deriving from’ DPIAs and prior consultation (Council Rec.74a). How would this work with commodity cloud?
[15] See http://www.kuan0.com/publications.html.
[16] Chris Reed’s short yet clear ‘Making Laws for Cyberspace’ book is a must-read. I don’t just say that because he’s my main PhD supervisor, and he’s not paying me a penny for my continual plugging of his book!
[17] But point you to Chris Pounder’s excellent blogs, e.g. http://amberhawk.typepad.com/amberhawk/2015/08/councils-exceptions-from-the-data-protection-regulation-degrade-the-privacy-protection-below-directive-9546ec.html
