Membership Login / Register (0)

Cloud computing & the EDPB: 2021 in retrospect

January 7, 2022

WP196 guidance on cloud computing and data protection laws, issued by the Article 29 Working Party (predecessor of the European Data Protection Board or EDPB), dates from 2012. So it’s very long in the tooth, particularly in computing years (which are very much shorter than dog years!).

The EDPB’s 2021-22 work programme mentions the possibility of “Any additional guidance on legal implications relating to technological issues, such as Cloud computing, Artificial intelligence/Machine Learning, Digital Identity & Identity Federation, Data Brokers, Internet of Things, and payment methods” – but that’s a long list, and guidance on AI and IoT could well be prioritised over updating the cloud guidelines.

Given the increasing prevalence of cloud use for technology infrastructure and services, much EDPB guidance is of course relevant to cloud, even if it doesn’t explicitly mention cloud – particularly SaaS services.

However, certain EDPB guidance does explicitly mention cloud or hosting, especially EDPB documents issued in 2021. Those documents are summarised below in chronological order of publication (final publication, where adopted formally) – 2021 seems to have been the year of cloud and the EDPB, if you like! The EDPB can be forgiven for missing out February, August, September and December, given the double helpings in both Mar and May, and triple in July, so it’s still an even dozen.

Pre-2021 documents are not covered, although cloud computing was mentioned in some (e.g. the certification-related Guidelines 1/2018, and 4/2018, and obviously the EDPB’s 2019 joint letter with the EDPS to the European Parliament’s LIBE Committee with their assessment of the US CLOUD Act’s impact on the EU data protection framework and on negotiations with the USA on cross-border access to electronic evidence). SaaS is generally excluded, as flagged above. My focus is mainly on IaaS/PaaS.

January 2021

EDPB-EDPS Joint Opinion 1/2021 on standard contractual clauses between controllers and processors

  • In relation to hosting (and cloud is of course often used for hosting), “In some cases, the processor might not be aware of the exact purpose of the processing, for instance when hosting data. Therefore, and in accordance with the provision of Article 28.3 of the GDPR, the EDPB and EDPS are of the opinion that the Clause should be completed with the obligations applying with respect to the security of the processing to the controller which, in particular, has to provide all useful information to the processor to comply with the relevant requirements in this respect”. This is welcome acknowledgement that cloud providers may not know the processing purpose (or indeed nature of the data hosted), in the “cloud of unknowing” (part 1, part 2).

March 2021

Guidelines 01/2020 on processing personal data in the context of connected vehicles and mobility related applications (obviously relevant to other IoT processing too):

  • Recognises that personal data from connected vehicles etc can be stored in cloud computing infrastructure, and must be adequately secured against unauthorized access (para.60).
  • Recommends developing a secure in-car application platform, physically divided from safety relevant car functions, so that access to car data does not depend on unnecessary external cloud capabilities (para.75).
  • Local data processing should be considered by car manufacturers and service providers, whenever possible, to mitigate the potential risks of cloud processing (para.76).

EDPB letter to EU security agency ENISA on ENISA’s draft European Cybersecurity Certification Scheme for Cloud Services (EUCS) on the certification of the cybersecurity of cloud services (part of the European Cybersecurity Certification Framework under the 2019 EU Cybersecurity Act) (see also Nov 2021 below)

  • The EDPB would like the EUCS scheme to: cater specifically for personal data and special category personal data, including derived personal data; take account of personal data processing risks (i.e. risks to people not just ICT systems); reinforce EUCS security requirements to comply with data protection rules on security of processing at all assurance levels (the EUCS scheme provided for different assurance levels: basic, substantial and high); include requirements about location of data processing at all assurance levels; differentiate portability control from the GDPR data portability right; involve the cloud provider’s data protection officer (DPO) at the early design stage; provide for contractually guaranteed information and audit rights at all assurance levels; reflect GDPR’s personal data breach requirements for all assurance levels; and allow independent audits at all assurance levels.

April 2021

Guidance on certification criteria assessment (Addendum to Guidelines 1/2018 on certification and identifying certification criteria in accordance with Articles 42 and 43 of the Regulation), issued in draft for consultation as an annex to 1/2018 (briefly mentioned above), but to date not yet finally adopted – but I will count this for April

  • Certification scheme owners must, at an early stage, consider the market demand and benefits for all stakeholders of the proposed certification mechanism, e.g., is it aimed at the use of a “specific technology, like cloud computing services”? (para.9)
  • Scheme scope should be explained in detail; “This explanation should not just state that the scheme covers “cloud computing” as this is too general; ” (para.21). “For example, the scope of a certification mechanism related to cloud computing could be SaaS, IaaS and PaaS. Additionally, SaaS can be further divided in sub-categories because providing storage capacities is very different from providing other services (e.g., support for software upgrades). A company might also decide to certify only of one of its service offerings, or even a part of a particular service in certain circumstances. The scheme owner should ensure this is clear and allow for a suitable ToE [target of evaluation] that reflects the scope to be determined. In this cloud computing example the target of evaluation could go to a level of detail, like for instance: “Data storage service provided by MySaaSDataStorage” (para.22).

May 2021

Under the GDPR, adherence to approved codes of conduct may be used as an element to demonstrate compliance. Only two codes have been approved so far. The EDPB adopted two positive Art.64 GDPR opinions on two draft decisions on Codes it considered to be compliant with Art. 40 and 41 GDPR, submitted by the Belgian and French SAs respectively, on transnational Codes of Conduct: (respectively) opinion the EU CLOUD Code of conduct for cloud service providers, and opinion on the CISPE Code of conduct for cloud infrastructure service providers (i.e. IaaS). The formal decisions approving those codes were issued in June. These Codes aim to provide practical guidance and define specific requirements (i.e., Art. 28 GDPR) for adhering EU processors; however, they cannot be used to legitimise international transfers of personal data (on which see Jul below).

These count as two – that’s two opinions in May!

June 2021

EDPB Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data, that is  the well-known Schrems II supplementary measures guidance:

  • This mentioned “storage in a cloud situated outside the EEA offered by a service provider, is also considered to be a transfer. More specifically, if you are using an international cloud infrastructure you must assess if your data will be transferred to third countries and where, unless the cloud provider is established in the EEA and it clearly states in its contract that the data will not be processed at all in third countries” (para.13)
  • Use case 1 covered data storage for backup and other purposes that do not require access to data in the clear using a hosting service provider in a third country – where encryption meeting certain conditions could provide an effective supplementary measure (para.84). While this did not mention cloud, it would include cloud hosting.
  • Use case 6 was about transfers to cloud services providers or other processors which require access to data in the clear (paras.94-95): “where unencrypted personal data is technically necessary for the provision of the service by the processor, transport encryption and data-at-rest encryption even taken together, do not constitute a supplementary measure that ensures an essentially equivalent level of protection if the data importer is in possession of the cryptographic keys.” While “the EDPB is, considering the current state of the art, incapable of envisioning an effective technical measure to prevent that access from infringing on the data subject’s fundamental rights”, at least “The EDPB does not rule out that further technological development may offer measures that achieve the intended business purposes, without requiring access in the clear” – and here, I strongly espouse the development and use of technical measures not yet acknowledged by the EDPB beyond multiparty computation (MPC), namely confidential computing/TEEEs/enclaves. I think their adoption will be accelerated by the post-Schrems II need for supplementary measures that can prevent a data importer from having intelligible access to “data in use” (not just data in storage or data in transit/transmission). 

July 2021

Guidelines 07/2020 on the concepts of controller and processor in the GDPR gives some cloud examples:

  • Cloud provider as processor – a standardised cloud storage service where the customer is a controller (some cloud customers could, of course, be processors acting for a controller): ” Insofar as the cloud service provider does not process the personal data for its own purposes and stores the data solely on behalf of its customers and in accordance with instructions, the service provider will be considered as a processor” (para.30)
  • A service provider hosting encrypted data is still a processor, even though it doesn’t know that it’s personal data (para.40, Hosting services example – cf. the “cloud of unknowing” articles above)
  • Joint controllership with the cloud service – “the administrator of a fan page hosted on Facebook, by defining parameters based on its target audience and the objectives of managing and promoting its activities, must be regarded as taking part in the determination of the means of the processing of personal data related to the visitors of its fan page” (para.66) – see also Guidelines 8/2020 on the targeting of social media uses
  • The entity hosting a shared database (e.g., within a group) is a processor (para.71 both examples)
  • Means of processing – nothing prevents the processor from offering a pre-defined service but the controller must make the final decision to actively approve the way the processing is carried out, at least insofar as concerns the essential means of the processing… a processor has a margin of manoeuvre as regards non-essential means: “A municipality uses a cloud service provider for handling information in its school and education services. The cloud service provides messaging services, videoconferences, storage of documents, calendar management, word processing etc. and will entail processing of personal data about school children and teachers. The cloud service provider has offered a standardized service that is offered worldwide. The municipality however must make sure that the agreement in place complies with Article 28(3) of the GDPR, that the personal data of which it is controller are processed for the municipality’s purposes only. It must also make sure that their specific instructions on storage periods, deletion of data etc. are respected by the cloud service provider regardless of what is generally offered in the standardized service (para.84).

The EDPB adopted draft Guidelines 04/2021 on codes of conduct as tools for transfers (complementing EDPB Guidelines 1/2019 on codes of conduct establishing the general framework for the adoption of codes of conduct). This was intended to clarify the application of Arts.40(3) and 46(2)(e) GDPR whereby a CoC, once approved by a competent SA and granted general validity within the EEA by the Commission, may be adhered to and used by controllers and processors not subject to the GDPR to provide appropriate safeguards for transfers of data outside of the EU. It has not yet been formally adopted in final form.

  • One cloud example is given (para.7): “Company XYZ is headquartered in Italy and has affiliates in Germany, the Netherlands, Spain and Belgium. For the purpose of managing the IT tools used by the group, Company XYZ uses the services of a cloud service provider based in a third country with no presence in the EU. Data processed as part of the use of IT tools involves transfers of data from Company XYZ and its affiliates to the cloud service provider, for the purpose of storage of data. As the cloud service provider in the third country has adhered to a code of conduct to be used as a tool for transfers relating to cloud services approved under article 40-5, data flows from Company XYZ and its affiliates to the cloud service provider can be framed with the code of conduct to which the cloud service provider has adhered. In this case, the use of a code of conduct by the cloud service provider instead of other transfer tools such as BCRs appears more appropriate to the extent that a code of conduct does not require the controller/processor acting as importers to have a presence in the EEA while a presence in the EEA is required for a group of companies for using BCRs. The code of conduct also presents benefits for addressing multiple transfers of data with a single tool compared to (fully) contractual solutions such as SCCs”.

The EDPB adopted draft Guidelines 02/2021 on virtual voice assistants, not yet finalised.

  • On the common requirement for VVA users to be required to bundle their VVA service with other services, Example 4: “A VVA designer requires its users to have an account to access the VVA service. This user account is not specific to the VVA service and can be used for other services offered by the VVA designer such as email, cloud storage and social media…”, resulting in complexity and transparency problems (para.55).
  • It mentions the common practice of many VVAs using cloud speech recognition services, and the importance of security even before transmission to the cloud:  If working as currently designed, VVAs do not send any information to the speech recognition cloud service until the wake-up expression is detected. However, software vulnerabilities could allow an attacker to bypass the VVA set-up and security measures. It could then be possible for example to get a copy of all data sent to the VVA cloud and forward it to a server controlled by the attacker” (para.117)
  • Further on security, “Data lawfully processed or derived by VVAs allow building a fairly accurate profile of their users as VVA know or can infer the location, the relations and the interests of their users. VVAs are increasingly present in users’ homes and smartphones. This circumstance increases the risk of mass surveillance and mass profiling. Consequently, the security measures to protect the data both in transit and at rest, in the devices and in the Cloud, should match those risks” (para.118).

October 2021

The EDPB launched its first coordinated enforcement action, whereby national supervisory authorities target certain topics, focusing on the use of cloud based services by the public sector.

November 2021

EDPB follow up letter to ENISA on the EUCS (see Mar 2021 above):

  • EUCS must be compatible with Schrems IISchrems II.

And there we have it – 2021 as viewed through EDPB guidance relating to cloud computing!

Perhaps there won’t be many more of such guidelines. Given the ever-rising rate of cloud adoption and cloud’s multipurpose nature (at least if IaaS/PaaS), in the not too distant future we might not be referring to EDPB guidance regarding cloud use anymore, just as today we wouldn’t refer to EDPB guidance regarding “computing tech/software use”.

profile picture of dr kuan hon

Dr W Kuan Hon is an Editor of the Encyclopedia of Data Protection & Privacy and a guest lecturer for AI MSc students at Imperial College London. Formerly a Director with the Privacy, Security & Information Law team at Fieldfisher, Kuan is Of Counsel at Dentons from 10 Jan 2022.