The GDPR’s coming, soon to be law they say
Middle of 20-18 may be the fateful day!
What will this mean for clo-ud? Will cloud be here to sta-ay?
Don’t want to be pessimistic, not sure how we’ll find a way
Killing cloud quickly with DP, killing cloud quickly, with DP, tearing up SaaS, PaaS and I-aaS
Killing cloud quickly
With DP…?[1]
1. Introduction
It’ll be tough to use cloud computing for processing personal data and comply with the proposed GDPR.[2] Indeed, it’s tough to use cloud compliantly with data protection laws now, especially if you try to follow slavishly the Article 29 Working Party’s cloud guidance.[3] However, the GDPR will make compliance an order of magnitude harder.
It’s not because cloud computing is inherently privacy-invasive in itself, no more so than a computer is inherently privacy-invasive – at least with infrastructure cloud (IaaS/PaaS, pure storage SaaS).[4]
It’s because the GDPR would set in stone the most prescriptive, cloud-impracticable, elements of WP196, while omitting parts of WP196 that actually recognised how cloud works. Rather than making data protection laws truly technology-neutral, the GDPR will perpetuate the 1970s models of computing/outsourcing embedded in the 1995 Data Protection Directive (DPD).[5] Unfortunately, the new rules’ impact extends far beyond cloud – modern outsourcing arrangements generally will become more complex, although the problems are starkest with cloud.
Previously, I outlined some key issues.[6] This article focuses on controller-processor contract requirements.
2. Cloud contracts
GDPR Article 26, headed ‘Processor’, provides (emphasis added):
…1a. The processor shall not enlist another processor without the prior specific or general written consent of the controller. In the latter case, the processor should always inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the opportunity to the controller to object to such changes.
2. The carrying out of processing by a processor shall be governed by a contract or other legal act under Union or Member State law, binding the processor to the controller, setting 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, the obligations and rights of the controller and stipulating in particular that the processor shall:
(a) process the personal data only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the processor is subject; in such a case, the processor shall inform the controller of that legal requirement before processing the data, unless that law prohibits such information on important grounds of public interest;…
(c) take all measures required pursuant to Article 30 [security];
(d) respect the conditions referred to in paragraphs 1a and 2a for enlisting another processor;…
…(f) assist the controller in ensuring compliance with the obligations pursuant to Articles 30 to 34 [security, breach notifications to regulators/data subjects, data protection impact assessments, prior consultation of regulators] taking into account the nature of processing and the information available to the processor;…
…(h) make available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller. The processor shall immediately inform the controller if, in his opinion, an instruction breaches this Regulation or Union or Member State data protection provisions.[7]
2a. Where a processor enlists another processor for carrying out specific processing activities on behalf of the controller, the same data protection obligations as set out in the contract or other legal act between the controller and the processor as referred to in paragraph 2 shall be imposed on that other processor by way of a contract or other legal act under Union or Member State law, in particular providing sufficient guarantees to implement appropriate technical and organisational measures in such a way that the processing will meet the requirements of this Regulation. Where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations.
The main problem is that infrastructure cloud providers are considered ‘processors’ under data protection laws if controller customers process any personal data in-cloud, regardless of context. Infrastructure cloud services are used for customers’ computing, storage and/or networking purposes (whether internally and/or to serve customers’ own customers in turn), instead of buying their own servers/storage/networking equipment. If a controller buys or rents computing/storage/networking equipment for processing personal data, the equipment manufacturer and rental company are not generally considered ‘processors’. Use similar equipment through cloud, however, and cloud providers are treated as ‘processors’. This approach is not technologically-neutral. Rather, it discriminates against cloud, and may deter cloud use despite its known costs/flexibility benefits.
Under Article 26(2), where organisations buy or rent servers/storage/networking equipment for self-processing of personal data, they’re not legally obliged to specify, in the purchase or rental contract, the processing’s subject-matter/duration, nature/purpose or types of personal data or data subject categories processed. Organisations don’t want to give vendors/rental companies all that information, and vendors/rental companies don’t really want to know – TMI, it’s none of their business what organisations use bought/rented equipment for, that’s up to each organisation. Now, change that to use of infrastructure cloud. Article 26(2) would force controller organisations to tell cloud providers, in their contracts, all about the organisation’s planned personal data processing, whether organisations want to or not, or face fines of up to €10m or 2% total annual turnover if higher. How will that improve data subjects’ protection? Quite the opposite, arguably.
Now, consider prior consent to sub-processors (Articles 26(1a), 26(2)(d)). Suppose a prospective customer of SaaS provider S wants to store personal data using S’s service. S’s service was built on IaaS provider I’s service (classic example: Dropbox’s SaaS storage on Amazon’s IaaS). How can it make sense to ask customers to ‘consent’ to S’s use of I’s service? Surely, in reality, the only choice customers have is to consent to I, or not to use S’s service, because S can’t feasibly re-engineer its entire SaaS service to work with another IaaS/PaaS service just because one prospective customer objects to I. What kind of ‘consent’ is that? How does requiring such consent, or imposing contractual requirements for such consent, help data protection? Similarly, if a sub-provider is to be changed because of a strategic business decision by S or I (eg switching connectivity provider to another carrier because I’s business connection with S’s current carrier has terminated), in reality S will have little or no say if the decision was made by I and, whether the decision was made by S or I, again if one customer of S objects, in reality it will simply have to stop using S’s service.
On to ‘instructions’ (Article 26(2)(a)). Cloud providers don’t actively process personal data as customers ‘instruct’; customers use cloud services directly themselves, in self-service fashion.[8] For example, S’s customer may upload, edit and delete personal data stored on S’s service by clicking buttons or typing in its web browser, which invisibly sends commands over the Internet to S’s software application (running on I’s service) to store, amend or delete data stored on S’s (or rather I’s) equipment. Or, a customer of I may upload personal data to I’s servers to process in virtual machines configured and started by the customer. Are commands to S’s or I’s software ‘instructions’? Discussing processing of personal data in accordance with controllers’ ‘instructions’ makes no sense in cloud. The DPD’s ‘instructions’ requirement was aimed against processors’ unauthorised use or disclosure of personal data for their own purposes.[9] This objective would be equally, indeed better, served had GDPR specifically banned processors’ use or disclosure of personal data without controller authorisation, rather than perpetuating the outdated ‘instructions’ requirement.[10] What’s the difference between ‘instructions’ and ‘documented instructions’, anyway? How would you ‘document’ http requests sent when customers click buttons in their browsers, if those are ‘instructions’ (log everything)?
Next, security (Article 26(2)(c), (f), (h)). Article 30 GDPR (security) requires measures appropriate to the particular personal data processing and its risks. A risk-based approach is sensible, but making processors as well as controllers assess risks and take measures is again at odds with cloud. A controller, who obviously knows the nature/purposes of its intended processing, can secure data e.g. by encrypting securely before upload (if using cloud only for storage), implementing backups internally or to another cloud service, and take other appropriate measures. But public cloud providers can’t tailor security measures to the individual needs of hundreds, even thousands or millions, of customers, because their services are standardised/commoditised and because of the numbers involved. Yet, Article 30 would make them investigate every customer’s intended personal data processing/risks and customise security accordingly, or risk €10m/2% fines. One workaround may be to implement the highest possible levels of security, passing costs on to all customers – or perhaps offer tiered services where, say, services meant for sensitive data would cost more because higher security levels would be provided. But what if a customer deliberately chooses to process sensitive personal data using a cheaper lower-security service? Could the provider still be liable for not finding out the customer’s real use and providing higher security accordingly? Cue longer contracts, with extra customer disclosures, representations/warranties and indemnities… and intrusive proactive provider monitoring of customer usage, which customers don’t want, and would add to costs, perhaps affect performance, and certainly can’t help improve data protection. For infrastructure services, shouldn’t controllers be primarily responsible for assessing services’ appropriateness for their intended processing, including security levels, rather than turning processors into prying processors?
Even WP196 (p 22) acknowledged that ‘individual audits of data hosted in a multi-party, virtualised server environment may be impractical technically and can in some instances serve to increase risk’, recognising that third-party audits (although by auditors chosen by customers) might be acceptable instead. Yet Article 26(2)(h) requires contractual audit rights for controllers. Processors will have to notify ‘personal data breaches’ to controllers without undue delay (Article 31(2)), as a direct GDPR obligation, but of what exactly isn’t stated: what about a breach affecting others but not that controller? Again, this very brief obligation will be difficult to apply to public cloud, as will the contractual obligation on processors to ‘assist’ with controllers’ breach notification obligations (which will no doubt increase costs), where it’s unclear what ‘taking into account the nature of processing and the information available to the processor’ means.
The biggest issue is probably Article 26(2a)’s requirement (mirroring WP196) regarding sub-processor contract terms. If a cloud provider is a ‘processor’ then logically any sub-providers, including indeed infrastructural sub-providers, are sub-processors: for example, data centre operators and connectivity/network service providers (as personal data transmission is clearly ‘processing’). This goes way beyond cloud. Imagine asking every third-party data centre operator and carrier involved in a service’s delivery to sign a contract on Article 26(2)’s detailed terms for every end customer who processes personal data using that service – cloud or not. Thousands or millions of tailored contracts per service that involves personal data processing (cloud or not) is impracticable, and doesn’t necessarily help data protection. Of course, as practitioners who’ve struggled with implementing hundreds or thousands of model clauses know, rigid prescriptiveness may have to win out.
A data centre operator may – or may not – have access to intelligible data processed on its premises: it depends on the arrangements. Similarly, a carrier/ISP has technical ability to ‘tap’ data flowing through its cables, but would have access to intelligible data only where not securely-encrypted pre-transmission. Arguably, treating providers of infrastructure services (cloud or not) as ‘sub-processors’ with obligations beyond maintaining a certain minimum level of security, regardless of whether they can access intelligible data, doesn’t make sense, and may lead to absurdities.
3. Practical issues
Contracts will be king. The many uncertainties in the GDPR’s text seem best addressed by ensuring they are covered in detail in controller-processor contracts, and indeed sub-processor contracts – for example, the scope of a cloud provider’s obligation to ‘assist’ controllers with their obligations on security, data protection impact assessment etc (and the costs of providing such ‘assistance’). And for contracts that may expire after the GDPR takes effect, suitable change control/change of law clauses need inclusion even now, to enable contracts to be amended for compliance with Article 26 (as well as to allocate responsibility and liability among supply chain actors appropriately).
Systems will also have to be engineered to increase cloud logging/recording, which is good for transparency but again may increase complexity and certainly costs.
One consequence (presumably unintended) of GPDR is that only the largest cloud customers and cloud providers are likely to have the resources and bargaining power to force the whole supply chain to enter into the required sub-processor contracts. This means small customers and cloud providers will be unable to operate – or may simply not comply, despite the potentially huge fines, taking the risk that regulators with limited resources will not go after them as ‘small fry’. But this would bring the GDPR into disrespect.
4. Concluding remarks
Space doesn’t permit discussion of other problems GDPR will cause for cloud, and indeed sourcing/outsourcing generally. However, at the risk of being repetitious, like the DPD, Article 26 of the GDPR only works for 1970s outsourcing, when controllers gave exclusive control of personal data to computer service bureaux by delivering tapes/disks containing personal data (often the only tapes or disks storing that data), and ‘instructing’ them to handle that data actively for particular purposes in particular ways, eg payroll processing. Commoditised, standardised, pre-built, self-service public cloud, particularly infrastructure cloud, just doesn’t follow that service model. 21st century laws should strive towards technology-neutrality, rather than enshrining 1970s models.
W Kuan Hon is a senior researcher working on cloud law projects at QMUL, and a consultant lawyer for 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.
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] With apologies to the Fugees and, for traditionalists, Roberta Flack
[2] This article uses the version approved by the European Parliament’s LIBE Committee and COREPER (the Council’s Committee of Permanent Representatives), at http://data.consilium.europa.eu/doc/document/ST-5455-2016-INIT/en/pdf.
[3] http://ec.europa.eu/justice/data-protection/article-29/documentation/opinion-recommendation/files/2012/wp196_en.pdf
[4] Chapter 8, Cloud Computing Law (OUP 2013), Millard ed; earlier open version http://idpl.oxfordjournals.org/content/2/1/3.full
[5] http://www.iicom.org/intermedia/intermedia-january-2016/dark-clouds
[6] http://www.scl.org/site.aspx?i=ed43376
[7] Discussed previously – n.7. At least this is no longer a direct GDPR obligation, but it’s still not a sensible requirement in my view.
[8] n.5.
[9] Eg Salems (Sweden) http://www.datainspektionen.se/documents/beslut/2013-05-31-salems-kommun.pdf
[10] n.5.
