Tips and tricks: Contracting with cloud providers in the aftermath of the Schrems II judgment

In 2020, the Court of Justice of the European Union (CJEU) issued its Schrems II judgment. The CJEU ruled that the adequacy decision on the EU-US Privacy Shield was invalid and that the standard contractual clauses (SCCs) may need to be supplemented by supplementary measures to ensure an adequate level of protection. This came as a shock to many companies using cloud services as many cloud providers access, and even store, (personal) data outside the EEA. Some even questioned whether they could continue working with such cloud providers without being in breach of the GDPR.

Since then, the European Data Protection Board (EDPB), who oversees the consistent application of GDPR, published its Recommendations 1/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data (read our analysis of these recommendations). These Recommendations provide for a complex transfer impact assessment that needs to be performed before a transfer outside the EEA can be allowed. Meanwhile, several regulatory authorities have taken initiatives to enforce the CJEU’s decision, and also the European Data Protection Supervisor (EDPS), who oversees the protection of personal data and privacy by EU institutions, launched two investigations into the use of cloud services by EU institutions. In addition, the first related national decisions have started to come out and numerous additional cases on data transfers are pending before EU data protection authorities.

Here, we discuss the key data transfer considerations related to working with cloud providers. We identify alternative service offerings that cloud providers have been proposing to their customers and some key contractual points of attention. We also touch on the codes of conduct relating to cloud services which have recently been approved by the Belgian and French data protection authorities (the EU Cloud Code of Conduct and the CISPE Code of Conduct respectively).

Contracting with a cloud provider established in the EEA

Companies sometimes consider working with an EEA-based cloud provider as data sharing between a company established in the EEA and an EEA-based cloud provider, in principle, does not involve data transfers under the GDPR. As a consequence, these processing activities would not require a data transfer mechanism and associated data transfer impact assessment. In this scenario, incorporating an adequate data processing agreement in the cloud contract would suffice.

In its Recommendations 1/2020, the EDPB clarifies that not only processing (such as storage) in a cloud environment located outside the EEA, but also remote access from a third country (eg for the delivery of support services), is considered to be a data transfer under the GDPR. Consequently, even when using a cloud provider established in the EEA, companies need to check whether the cloud provider transfers any personal data outside the EEA. A typical situation where a cloud provider established in the EEA transfers personal data outside the EEA is for the delivery of support services. Many cloud providers use the “follow the sun” model to offer 24/7 support services which means that personal data may be accessed by affiliates or subcontractors from countries in various time zones. In such case, an appropriate data transfer mechanism will need to be put in place and, if needed, complemented with supplementary measures (as discussed below) to ensure an adequate level of protection. If there are no transfers of personal data outside the EEA, the EDPB recommends to clearly state in the cloud contract that the personal data will not be processed at all in third countries.

An important contractual point of attention in this respect is to make sure that any clause confirming that the company’s data will not be processed at all outside the EEA prevails over any other (potentially conflicting) provisions of the agreement (for example, a standard services description).

Selecting a data center location within the EEA

Several global cloud providers offer their customers the option to select a data center located in the EEA. Some cloud providers offer this option for all their products, while others offer it only for a subset. Often, an EEA data center location option also comes with an additional cost.

While this option can be helpful to mitigate some data protection related risks associated with working with non-EEA based cloud providers, choosing this option, again, does not mean that there would be no transfer of personal data outside the EEA. As set out above, data transfers may occur when access to the cloud data is required from outside the EEA for the delivery of support and maintenance services. If this is the case, the company needs to rely on a data transfer mechanism and perform a data transfer impact assessment (as discussed further below). Whether or not the company’s data will be processed outside the EEA and that the company has chosen for the “EEA data center location” are to be clearly set out in the cloud contract. It is important to make sure that the data center locations are not listed in an operational document (often hyperlinked in the contract) which the cloud provider would be able to change in its sole discretion.

Data transfers outside the EEA must be assessed carefully

If the cloud provider transfers the company’s personal data outside the EEA (which is likely for the majority of the international cloud providers), the company using the cloud services will need to carry out a data transfer impact assessment to determine on a case-by-case basis if, and which, supplementary measures are required. The purpose of this assessment is to determine whether the legal framework in the country to which the personal data is transferred might affect the contractual safeguards included in the SCCs (ie the transfer mechanism on which most companies are relying at this moment). If gaps are identified, the company needs to assess whether it is able to fill those gaps in protection by implementing supplementary measures. Identifying the required supplementary measures and performing the data transfer impact assessment are complex tasks given the threshold and requirements set by the EDPB.

As pointed out by the EDPB in its Recommendations 01/2020, there are situations in which no supplementary measures are able to fill the gaps in the protection. The EDPB stated that this, among others, is the case when cloud providers in countries where the legal framework is problematic (eg in terms of powers of the public authorities) would not be able to properly deliver the cloud services if the personal data are pseudonymised or encrypted (eg because a helpdesk outside the EEA needs access to the personal data to resolve an incident). In such case, the EDPB is of the opinion that companies need to refrain from allowing the data transfer.

In case the company believes that there are supplementary measures that are able to fill the gaps of protection, the question arises as to what kind of supplementary measures must be taken to ensure an adequate level of protection. The EDPB’s Recommendations 01/2020 contain a non-exhaustive list of examples of contractual (eg obligation to implement certain technical measures included in an annex), organisational (eg internal policies for governance of transfers) and technical (eg pseudonymisation, encryption) supplementary measures. It is important to note that the required measures for a particular transfer will depend on the gaps in the protection identified in the data transfer impact assessment and that there is no one-fits-all solution. Some measures may remedy the shortfalls only in some countries, or for some types of transfers, and the assessment will always require careful consideration of all aspects of the transfer.

The EDPB also provided a number of examples of technical measures in this respect (subject to further conditions), including the:

• use of strong state-of-the-art encryption before transmission of the data, when the decryption keys are retained solely under control of the cloud user in the EEA (or in a country with an essentially equivalent protection); and/or
• implementation of pseudonymisation and sufficient aggregation before transfer, provided that the additional information needed to single out individuals remains under the exclusive control of the cloud user in the EEA (or in a country with an essentially equivalent protection).

Codes of Conduct

The GDPR also provides the option to rely on an approved code of conduct as a transfer mechanism (Article 46.2(e) GDPR).

Recently, both the Belgian and French data protection authorities each approved a code of conduct (EU Cloud Code of Conduct and the CISPE Code of Conduct respectively). These codes specify the processor obligations of article 28 GDPR (ie the obligations that are to be included in a data processing agreement) and related GDPR obligations (including the obligations on security measures) for practical implementation by cloud providers. The aim of these codes of conduct is to make it easier for cloud customers to determine whether certain cloud services are appropriate for their intended purposes as adherence to a code should facilitate certain due diligence obligations that the customer would otherwise have needed to carry out on an individual basis.

However, these codes of conduct may not be confused with codes that could serve as a transfer mechanism under the GDPR. The GDPR refers to codes of conducts for the implementation of several obligations: not only can a code constitute a data transfer mechanism, it can also serve to implement other GDPR obligations such as security obligations and Article 28 processor obligations. Currently, these two approved codes do not (yet) implement the data transfer requirements of the GDPR and, therefore, cannot be used as an alternative transfer mechanism instead of SCCs.

While none of these codes of conducts (already) qualify as a code of conduct in the meaning of Article 46.2(e) GDPR, adherence thereto could potentially be taken into account as a risk mitigating measure in the context of the data transfer impact assessment. Where relevant, it is recommended to include a contractual commitment for the cloud provider to adhere to the relevant code of conduct during the term of the cloud contract.

Moreover, in spite adherence to a future code of conduct that would cover data transfers could relieve an organisation of some of the paperwork exercise that comes with the use of standard contractual clauses, it is important to note that the need to perform a data transfer impact assessment remains present, as the EDPB is of the opinion that the Schrems II decision also covers other data transfer tools included in article 46 GPDR (such as codes of conduct and binding corporate rules).

Conclusion

Following the Schrems II judgment, companies are required to perform a data transfer impact assessment before any personal data is processed outside the EEA. This is also the case in the cloud context which now seems to be a key area of attention for the EDPS, the EDPB as well as the national data protection authorities.

For companies to avoid the need to perform such a data transfer impact assessment, companies could consider working with a cloud provider established in the EEA or a data center location in the EEA. In such case, it is important to make sure that the contract with the cloud provider clearly states that no personal data is shared outside the EEA. However, even when a cloud provider is established or a data center is located in the EEA, it is likely that there will be a transfer of personal data outside the EEA as a result of which a data transfer impact assessment is needed.

As stated above, this is a complex exercise that requires careful consideration of all aspects of the transfer. If a data transfer impact assessment would reveal that the legal framework in the country to which the personal data is transferred might affect the contractual safeguards included in the SCCs, companies should either adopt supplementary measures or not proceed with the transfer if the identified gaps in the protection of the SCCs cannot be filled. Companies need to check that these supplementary measures are clearly reflected in their cloud contract.

If you require further information or legal advice in this respect, please contact the authors.