It will be harder to use cloud computing to process personal data compliantly with the proposed General Data Protection Regulation. The GDPR would enshrine prescriptive, cloud-impracticable, elements of the Article 29 Working Party’s cloud guidance WP196, while omitting elements that recognize how cloud works. One GDPR objective is to modernize data protection laws but, rather than making laws technology-neutral, the GDPR would perpetuate 1970s models of computing/outsourcing embedded in the current Data Protection Directive.
The GDPR would significantly complicate all modern outsourcing arrangements, not just cloud; cloud is just the prime example. Building on my previous article, this article focuses on controller-processor contract requirements and the GDPR’s Article 26 on processors.
The main problem
Infrastructure cloud providers are treated as processors; equipment manufacturers, vendors and lessors are not. Individuals and organizations use infrastructure services for computing, storage and networking purposes instead of buying their own equipment. Under the GDPR, if controller-customers process any personal data in-cloud, the providers of these services (i.e., IaaS/PaaS and pure storage SaaS) are considered “processors”. This approach may deter cloud use despite its cost and flexibility benefits.
For example, organizations buying or renting equipment for self-processing of personal data needn’t specify in the contract the processing’s subject-matter, duration, nature, purpose or types of personal data, etc. But if organizations use infrastructure cloud for the same processing, Article 26(2) of the GDPR would force them to include this information in their contracts or face fines up to €10m or 2 percent of total annual turnover if higher.
How can that improve data protection?
Consent and “instruction”
GDPR Articles 26(1a), 26(2)(d) require controllers’ prior consent to sub-processors (strictly, “another processor”) who are “enlisted” by processors. Cloud providers offer services already built on sub-providers’ pre-existing services (example: Dropbox’s SaaS storage on Amazon’s IaaS). In such situations, surely customers must either consent, or not use that provider’s service. Providers can’t re-engineer their services to work with another sub-provider’s service just because one prospective customer objects to a sub-provider. Similarly, if a sub-provider (e.g. connectivity provider) is to be changed because of a strategic business decision, if one customer objects then, in reality, it will have to stop using the cloud service. (Cloud providers may have little say anyway in decisions made by their sub-providers, particularly large IaaS/PaaS sub-providers.)
Cloud providers don’t actively process personal data as customers “instruct.” Customers use cloud services directly themselves, for example self-service uploading, editing and deleting of personal data processed using the cloud service. Discussing processing of personal data under controllers’ “instructions” (GDPR Article 26(2)(a)) makes no sense in cloud. The Data Privacy Directive’s “instructions” requirement was intended to target processors’ unauthorized use or disclosure of personal data for their own purposes, e.g., Salems (Sweden).
This objective could equally be met by banning processors’ use or disclosure of personal data without controller authorization, instead of referring to “instructions.” But the GDPR would perpetuate the “instructions” requirement; indeed, requiring “documented instructions” may force more logging, with customers ultimately bearing the costs.
Security measures
Controllers and processors must take security measures appropriate to the processing and its risks (GDPR Articles 26(2)(c), (f), (h), 30). A controller knows the nature/purposes of its intended processing and can secure its data by encrypting data pre-upload or implementing backups internally or to another cloud, for example. But public cloud providers can’t tailor security measures for each of their hundreds, even thousands, of customers. Their services are standardized; the numbers involved make individual customization impracticable. Yet Article 30 would make them investigate every customer’s intended processing/risks and customize security accordingly, or risk €10m or 2 percent fines.
These providers could implement the highest possible security, passing costs on to all customers – or offer tiered services where, e.g., services for sensitive data would have higher security levels and cost more. But if a customer deliberately processes sensitive data using a cheaper low-security service, could the provider be liable for not checking the customer’s real use and applying higher security levels accordingly?
Cue longer contracts, with extra customer disclosures, representations, warranties and indemnities … even intrusive provider monitoring of customer usage (which customers don’t want), could increase costs and maybe reduce performance. Compelling provider intrusion into customers’ processing won’t improve data protection. For infrastructure services, shouldn’t controllers be primarily responsible for assessing services’ appropriateness for their intended processing, including security levels, rather making processors pry?
Audits and notification
Even WP196 (p.22) acknowledged, “individual audits of data hosted in a multi-party, virtualized server environment may be impractical technically and can in some instances serve to increase risk,” recognizing that third-party audits (although by customer-selected auditors) might be acceptable. Yet GDPR Article 26(2)(h) requires contractual audit rights for controllers. Processors must notify “personal data breaches” to controllers without undue delay (GDPR Article 31(2)), but what about breaches affecting others but not that controller? This unclear obligation will be difficult to apply to public cloud. Similarly with the obligatory contract term requiring processors to “assist” with controllers’ breach notification obligations, which will again increase costs.
Sub-processors
Flowing down processor contract obligations to sub-processor contracts (GDPR Article 26(2a), mirroring WP196) may be difficult, even impossible. If cloud providers are “processors,” their infrastructural sub-providers must be sub-processors, think data center operators and connectivity or network service providers. This problem goes beyond cloud. Imagine asking every third-party data center operator and carrier involved in a technology service’s delivery to sign a contract on Article 26(2)’s prescriptive terms for every customer who processes personal data using that service – cloud or not. Thousands of tailored contracts for every service involving personal data processing (cloud or not) is impracticable, and doesn’t necessarily help data protection.
Of possible assistance is that this flow-down is required only where sub-processors are enlisted for a “specific processing,” but the meaning of this is insufficiently clear. Could commoditized cloud escape being considered “specific processing” – or not?
The consequences
I argue that treating providers of infrastructure services (cloud or not) as “sub-processors” (strictly, “another processor”), with obligations beyond maintaining certain minimum security measures, regardless of whether they can access intelligible data, doesn’t make sense, and may lead to absurdities.
One consequence (presumably unintended) of the GDPR is that only large customers and providers are likely to have the resources and bargaining power to make the entire supply chain sign the detailed, prescriptive (and cloud-inappropriate) contracts that Article 26 would require. Small customers and providers will be unable to operate – or may choose not to comply, despite potentially huge fines, taking the risk that regulators with limited resources will not go after a “small fry.” But that would bring the GDPR into disrespect.
In practice, controller-processor contracts will be the best place to address the GDPR’s uncertainties, and similarly with sub-processor contracts – e.g., detailing the scope of cloud providers’ obligation to “assist” controllers with security, etc (and payment for that assistance).
There’s no “grandfathering” of pre-existing contracts that comply with current DPD requirements. With contracts expiring after the GDPR takes effect, change control or change of law clauses will need to be included now, so that they can be amended to comply with GDPR Article 26 (as well as to allocate responsibility among supply chain actors with appropriate liability/indemnity clauses).
Space doesn’t permit discussion of other problems the GDPR will cause for cloud, indeed sourcing and outsourcing generally. My key point is, laws drafted for old outsourcing models just won’t work for commoditized, standardized, pre-built, self-service public cloud, particularly infrastructure cloud, and other modern outsourcing models. Twenty-first century laws should strive towards technology-neutrality, rather than enshrining 1970s models of computer services bureaux.
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 Sa-aS, Pa-aS and I-aaS
Killing cloud quickly with DP…
photo credit: Window Seat via photopin(license)