Comment—EDPS to EU institutions: revert to expensive 20th century outsourcing, longer documents

Is cloud usable for personal data after the 2 July 2020 EDPS report, Outcome of own-initiative investigation into EU institutions’ use of Microsoft products and services (including Office 365 and Azure)?

Following Dutch government discussions, in January 2020 Microsoft updated its online services terms, moving data processing terms into a separate Data Protection Addendum (DPA). This was (with other documents) reviewed by the EDPS, who supervises data protection by EU institutions (institutions) like the European Commission under the (GDPR-based) Regulation (EU) 2018/1725. It says its recommendations might ‘interest’ other EU public sector bodies and that where, as here, the Regulation’s provisions ‘follow the same principles’ as GDPR, both should be interpreted ‘homogeneously’: effectively, that GDPR regulators should approach GDPR similarly in supervising the public and private sector bodies regulated by the GDPR.

Unfortunately, its recommendations, implemented literally, would force institutions to last-century outsourcing models, cost EU taxpayers more and ‘gift’ lawyers with (unnecessarily) longer contracts. They are at odds with market practice, indeed technical and commercial realities. Previous EDPS documents were knowledgeable, it boasts excellent technical experts, so it is unclear what drove its retrograde approach to market-common cloud terms that had evolved following regulators’ 2012 cloud opinion.

Key opinions/recommendations made by the EDPS include:

• insufficient clarity or contractual controls regarding processing/data categories where Microsoft acts as controller, including its right to change standard terms unilaterally and processing purposes; it wasn’t clear enough that standard contractual clauses for international transfers (SCCs) and its DPA override other terms
• the terms should include more detailed ‘instructions’ on many aspects; they did not to give institutions enough control over sub-processors, eg institutions’ right to terminate on change of sub-processors was ‘meaningless’, and lacked ‘meaningful’ audit rights
• institutions had insufficient knowledge or control over data locations, international data transfers and contractual/organisational/technical safeguards for transfers including data in transit, on which specific detailed instructions should be given per product/service; also, Microsoft had over-broad rights to disclose data to third parties, including non-EEA government agencies, without having to notify institutions. Indeed the EDPS’s ‘strong’ preference was for processing to take place only in the EEA
• before deploying third party products/services that will process a large amount of personal data, institutions should comprehensively assess data protection risks, including checking for ‘unlawful’ data flows to vendors and configuring/liaising with vendors to eliminate them. Institutions should gain ‘sufficient assurance’ on the nature, scope, subject-matter, data categories and purposes etc of processing and risks to data subjects, to be able to meet their transparency obligations to data subjects, and consider whether other solutions allow higher privacy safeguards 

Even the EDPS admitted its recommendations seem ‘a tall order’ for most Microsoft customers. Institutions raised concerns that a hyperscale service provider would find the advocated contractual changes ‘contrary to commercial sense, or impractical, or both’. But as Microsoft had shown willing to ‘entertain’ solutions for compliance needs, the EDPS thinks data protection could be bolstered in a ‘commercially acceptable’ way for ‘numerous customers’. So, it encourages EU institutions ‘not to be disheartened at the prospect of negotiating instructions’ that ‘they consider necessary’ to protect data subjects, ‘even when faced with a business partner of considerable heft’.

The issue isn’t negotiating heft, or Microsoft’s willingness. What the EDPS thinks necessary for cloud data protection is not feasible, even necessary, for adequate protection. If the European Data Protection Board (of which the EDPS is a member) or national GDPR regulators follow the EDPS, they could kill cloud—which, for many people and businesses, has proved a lifeline, even lifesaver, during the pandemic crisis. Private sector customers generally have less bargaining power than institutions, but tech-savvy customers wouldn’t raise most of the EDPS’s recommendations. Conversely, cloud providers would find their implementation difficult or impossible.

It’s not just because cloud is hyperscale. It’s because of how cloud works. Cloud enables self-service use (typically Internet-accessed) of commoditised, standardised software applications, application development/hosting, or infrastructure/equipment for computing, storage and networking (SaaS, PaaS and IaaS respectively). Unlike 1980’s outsourcing, where providers procured customer-specified infrastructure and customer-selected sub-processors from scratch and actively processed data for customers, cloud’s ‘direction of travel’ is reversed. Customers decide whether or not to use infrastructure prebuilt by providers, including sub-providers/sub-processors. That’s how cloud offers efficiencies and economies of scale. Also, data ‘processed’ by providers is, essentially, whatever customers choose to process using cloud services (particularly multiuse IaaS/PaaS and storage SaaS). None of this is new.

Microsoft’s 21 July 2020 DPA tried accommodating the EDPS to provide greater assurances on customer choices, transparency, processes and accountability—within real-world limits:

• clarifying beyond crystal what data protection obligations (including disclosure restrictions) apply to which products/services/data types, including that SCCs and the DPA override other terms (their overriding nature was already clear, I feel); customer choices upon Microsoft’s DPA updates for new features/software; and a ‘noddy’ chart of data types incorporating ‘personal data’. Obviously, it is sensible for all (not just cloud) service providers to make these clear, particularly if documentation structures are complex
• further describing/circumscribing the scope/purposes of Microsoft’s controllership for its (defined) ‘legitimate business operations’, qualified by ‘incident to delivery of the Online Services’. Controllers have statutory obligations anyway, though Microsoft explicitly accepts that responsibility. Purposes not described are explicitly prohibited
• in respect of Microsoft’s sub-processors:
  • redefining/confining sub-processors/sub-contractors to be ‘Subprocessors’ by reference to Article 28 (let courts decide!), authorising them as such, explicitly mentioning limitations on Subprocessors disclosing data
  • increasing notice of new Subprocessors to 30 days
  • committing to notify new services’ new Subprocessors before their availability
  • expanding its Subprocessors list for data type (customer data or pseudonymous), but (contrary to the EDPS’s recommendations) the list does not specify the Subprocessors for each product/service separately, nor does it set out Subprocessor safeguards/security measures
• restricting geographic data location except ‘in accordance with’ the DPA and safeguards ‘provided below’ (presumably SCCs; still mentioning Art 46(2) safeguards and documentation of transfers/safeguards). Also, ‘[T]taking into account such safeguards’, Customer appoints Microsoft to transfer data to the US ‘or any other country’ where Microsoft/its Subprocessors operate, and to process data to provide Services ‘except as described elsewhere’ in the DPA
  • this reflects reality. In a globalised world, cloud or not, knowing/controlling all data locations as narrowly as the EDPS wants won’t actually protect personal data. With remote access and encryption, EEA location alone can’t guarantee data protection, while non-EEA-located data isn’t necessarily insecure or challenging to control. Separated geographic locations may even help against natural disasters
  • a key EDPS concern with ‘transfers’ is non-EEA authorities’ access to EU/EEA data. However, its recommended prohibitions on disclosure will only force multinationals (including EU-based ones who, if globally-operating, may also have ‘links to’ third-country governments) to decide which country’s laws to break. So, Microsoft’s new termination/modification rights for government requirements (eg conflicting with DPA/services) make sense from its perspective
• detailing (already-implemented) encryption of data in transit and at rest, and access controls. (Knowing countries where data may transit, as the EDPS wants, is technically impossible with Internet routing, but security measures like encryption help against interception)

Given the cloud’s nature, terms cannot be amended to meet all EDPS recommendations:

• realistically, providers cannot commit not to change standardised terms unless every single customer agrees
• customer-only controllership is impossible. Many providers’ ‘controller’ purposes are unexceptionable, even necessary. Providers must be controllers eg in promptly addressing cyberattacks on services—not awaiting/following multiple customers’ (probably different) anti-attack ‘instructions’ (Microsoft’s cyberattack-fighting expertise probably exceeds institutions’)! ‘Processing’ is broad. Controllers, by definition, ‘process’ for their own purposes (eg measuring volumes of data stored/transmitted to charge customers and accordingly calculate commissions to the employees who landed them). Do not assume all own-purpose processing must be against data subjects’ interests/rights
• subject-matter, types of data subjects, processing nature, etc in DPAs and SCCs must be generic—imagine ‘tailoring’ rental contracts to list every planned processing/data type etc before organisations can rent (multiuse) computers for data processing! Numerous checkboxes in SCCs for controllers to tick would create unnecessary bureaucracy
• ‘instructions’ cannot only be via documents. Self-service cloud customers type/click to 'instruct’ services eg to delete/edit data. They do not send contracts to providers saying ‘Edit/delete data’! Microsoft always, rightly, included customers’ service ‘use and configuration’ within ‘documented instructions’ (though it has deleted ‘final’). Also, long ‘instructions’ per customer on security etc are antithetical to pre-built standardised cloud. (Incidentally, how does the EDPS expect providers’ ‘obligation to inform’ to be detailed? This obligation should not even be contractual.)
• sub-processor changes—customer termination rights seem fair. Providers’ complex, strategic (often region/world-wide) supply chain decisions for standardised services shouldn’t be blockable by one customer. It is unreasonable to require continued servicing of that customer nevertheless
• individual audit rights—unworkable, and could impair security for all customers. Even for highly-regulated banks, despite theoretically unlimited audit rights, the European Banking Authority acknowledged third-party certifications and third-party/internal audit reports from cloud providers might be acceptable. Unsurprisingly, Microsoft’s audit terms weren’t amended. Prediction: separately-agreed collective EU institutions’ data protection (wider than security) audits?

Hopefully, cloud contracts’ drafting/negotiation will not change following the EDPS’s unattainable recommendations. Cloud providers might reassess their data protection terms’ scope but those need to be clear anyway, just as customers should conduct proper risk assessments before using cloud (although, to provide proper privacy notices for transparency, surely they don’t need as much detail from providers as the EDPS suggests—as previously mentioned, customers know what they’re going to be using cloud for!). The ultimate aim should be to protect personal data adequately against misuse or unauthorised access/loss/corruption, whatever the technology used. This is achievable in cloud without the fine-grained control of all processing aspects that the EDPS demands.