UPDATED Schrems II Top 5 FAQs for Lawful Cloud Processing

Answers to the following Top 5 FAQs are provided below:

Q1: Does adopting new SCCs or BCRs by themselves (without implementing new technical supplemental measures) enable my company to lawfully use cloud-based services?

Q2: How can my organisation comply with Schrems II requirements for data in US-operated clouds and other third-party technical infrastructures?

Q3: What type of Pseudonymisation is required to satisfy EDPB Use Case 2: Transfer of Pseudonymised Data?

Q4: Can my organisation rely solely on the commitments of hyper-scaler/cloud providers?

Q5: Is there joint and several liability among data supply chain participants for failing to comply with Schrems II requirements?

At the request of members of the Schrems II and Pseudonymisation LinkedIn group ("Schrems II Working Group," with the 9,200+ CLO, CPO, CDO, and CIOs and staff members), this article provides Top 5 FAQs for Schrems II lawful cloud processing in light of proposals by the UK Domestic Data Protection Team (regarding proposed updates to the UK data protection regime) the ICO (regarding consultations on (i) protecting international data transfers and (ii) updating guidance on anonymisation and pseudonymisation) in the context of final European Data Protection Board (EDPB) Schrems II Guidance and European Commission (EC) Standard Contractual Clauses (SCCs).

The Final EDPB Schrems II Guidance states that “Transfer to cloud services providers or other processors which require access to data in the clear” (EDPB Use Case 6) is unlawful.[1] However, the EDPB notes that “Transfer of Pseudonymised Data” (EDPB Use Case 2)[2] is lawful. The following FAQs respond to the top 5 questions asked by members of the Schrems II Working Group regarding requirements for lawful cloud-based processing.

Q1: Does adopting New SCCs or BCRs by themselves (without implementing new technical supplemental measures) enable my company to lawfully use cloud-based services?

A1: No. The Schrems II ruling does not require new SCCs or new BCRs, it requires the implementation of new Technical Supplementary Measures.

The Court of Justice of the European Union (CJEU) mandated that the processing of EU personal data cannot reveal the identity of individual data subjects in countries that (i) are not members of the European Economic Area (EEA), (ii) have not received an EU Adequacy Decision, or (iii) otherwise are found not to provide an adequate level of protection.

Processing EU personal data using cloud services provided by organisations organised, directly or indirectly, under the laws of the US or other non-EEA/non-Equivalency third-countries is considered an international data transfer, regardless of the physical location of the servers on which processing occurs, due to the potential access to such data by third-country government agencies.[3]

The EDPB clarified that the Schrems II compliance requires Technical Supplementary Measures,[4] which may be satisfied using GDPR Pseudonymisation, including when using cloud services.[5]

It was within this context, that the EC separately determined that new SCCs should be adopted. Continuing with existing, or updating SCCs/BCRs, without implementing technical supplementary measures is generally unlawful because government authorities in Third Countries are not bound by contractual (SCC) or corporate (BCR) restrictions. Protecting EU personal data when stored or transmitted (using encryption) but processing identifying data in cleartext form (when decrypted and vulnerable) is generally unlawful under Schrems II.

IMPORTANT UK NOTE: In the context of UK-EU data transfers, it is important to note that the final EC SCCs stipulate that anonymisation “requires rendering the data anonymous in such a way that the individual is no longer identifiable by anyone, in line with recital 26 of Regulation (EU) 2016/679, and that this process is irreversible.”[6] In addition, the Final EDPB Schrems II Guidance highlights that you must consider the availability of external data sets enabling unauthorised re-identification.[7] Therefore, relying on a localised approach to anonymisation as recently proposed by the UK could expose organisations to the risk of cross-border data transfer and other violations under the EU GDPR. For further details, see Memorandum submitted to: DataReformConsultation@dcms.gov.uk; IDTA.consultation@ico.org.uk; and anonymisation@ico.org.uk.

Q2: How can my organisation comply with Schrems II requirements for data in US-operated clouds and other third-party technical infrastructures?

A2: Generally, there are 3 ways to comply with Schrems II requirements with respect to processing data in US-operated clouds and other third-party-operated infrastructures:

First, the processing of cleartext EU personal data in US operated clouds and other third-party infrastructures can in many situations be transformed into processing properly Pseudonymised data (see Q3 below regarding EDPB requirements for Pseudonymisation). In the highest value use cases of advanced analytics, AI, and ML, the results produced by lawfully processing GDPR-compliant Pseudonymised data can have 100% accuracy and fidelity when compared to the results of processing data in the clear.[8] In addition to complying with Schrems II requirements, the processing of GDPR-compliant Pseudonymised data helps organisations comply with Secondary Processing obligations under Article 6.4 (for processing beyond purposes authorised by Consent or Contract), Data Protection by Design and by Default obligations under Article 25, and Security of Processing obligations under Article 32, which apply to all processing of EU personal data – whether internal or external to the EU. [SEE ALSO: article on December 2021 EDPS webinar: Pseudonymous Data: Processing Personal Data While Mitigating Risks]

Second, when processing EU personal data in the clear is required, for example, to communicate with or with regard to an EU data subject, the desired use must fall within a GDPR Article 49 derogation.

Third, if neither of the above two options is available, to comply with Schrems II requirements, the desired processing must occur within the EEA or a country that has received a valid EU equivalency decision (frequently referred to as “localisation”).

Q3: What type of Pseudonymisation is required to satisfy EDPB Use Case 2: Transfer of Pseudonymised Data?

A3: Only GDPR-compliant Pseudonymisation meeting the requirements of the EDPB as noted below will satisfy the requirements for EDPB Use Case 2: Transfer of Pseudonymised Data.[9] This does not include pre-GDPR techniques sometimes referred to as "Pseudnymisation" but which fail to satisfy the EDPB requirements set forth below.

IMPORTANT UK NOTE: Recent UK proposed definitions for "Pseudonymisation" fail to satisfy the EDPB requirements set forth below. For further details, see Memorandum submitted to: DataReformConsultation@dcms.gov.uk; IDTA.consultation@ico.org.uk; and anonymisation@ico.org.uk.

Pseudonymisation was previously understood to generally refer to replacing direct identifiers with tokens for individual fields independently within a data set. Under the EDPB Final Schrems II Guidance, it is clear that EU GDPR-compliant Pseudonymisation requires all of the following:

• Protecting all data elements: Footnotes 83 and 84 of the EDPB Final Schrems II Guidance highlight that achieving GDPR Pseudonymisation status must be evaluated for a data set as a whole, not just particular fields. This requires assessing the degree of protection for all data elements in a data set, including more than direct identifiers, extending to indirect identifiers and attributes. This is underscored by the definition of “Personal Data” under GDPR Article 4(1) as more than immediately identifying information and extending to “any information relating to an identified or identifiable natural person ('data subject'); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”
• Protecting against singling out attacks: Paragraph 85 of the EDPB Final Schrems II Guidance mandates protection against "singling out" of a data subject in a larger group effectively making the use of either k-anonymity or aggregation mandatory.
• Dynamism: complying with the requirements in Paragraphs 79, 85, 86, 87 and 88 of the EDPB Final Schrems II Guidance to protect against the use of information from different datasets to re-identify data subjects necessitates the use for differing purposes of different replacement tokens at different times (i.e., dynamism) to prevent re-identification by leveraging correlations among data sets without access to the “additional information held separately” by the EU data controller (see https://www.MosaicEffect.com);
• Non-algorithmic lookup tables: the requirement of Paragraph 89 of the EDPB Final Schrems II Guidance to take into account the vulnerability of cryptographic techniques (particularly over time) to brute force attacks and quantum computing risk will necessitate the use of non-algorithmic derived look-up tables in many instances; and
• Controlled re-linkability: The combination of the four preceding items are necessary to meet the requirement in Paragraph 85(1) of the EDPB Final Schrems II Guidance that, along with other requirements, the standard of EU GDPR pseudonymisation can be met only if “a data exporter transfers personal data processed in such a manner that the personal data can no longer be attributed to a specific data subject, nor be used to single out the data subject in a larger group, without the use of additional information.”

Q4: Can my organisation rely solely on the commitments of hyper-scaler/cloud providers for the purposes of Schrems II compliance?

A4: Relying solely on the commitments of hyper-scaler/cloud providers puts organisations at risk for Schrems II noncompliance for the reasons highlighted below:

Q5: Is there joint and several liability among data supply chain participants for failing to comply with Schrems II requirements?

A5: Yes. Clauses 3 and 12 of the new EC SCCs[10] provide that data controllers and processors are jointly and severally liable to data subjects, each of whom can seek redress in EU courts.

For more information on avoiding data supply chain risk, see TOP 5 REQUIREMENTS TO AVOID SCHREMS II DISRUPTIONS TO DATA SUPPLY CHAINS

NOTES:

[1] See Use Case 6: Transfer to Cloud Services Providers or Other Processors Which Require Access to Data in the Clear at paragraphs 94 and 95 of EDPB Recommendations 01/2020 on Measures that Supplement Transfer Tools to Ensure Compliance with the EU Level of Protection of Personal Data (Version 2.0)

[2] EDPB Use Case 2: Transfer of Pseudonymised Data at paragraphs 85 - 89 of EDPB Recommendations 01/2020 on Measures that Supplement Transfer Tools to Ensure Compliance with the EU Level of Protection of Personal Data (Version 2.0)

[3] The CJEU noted that FISA Section 702 "does not indicate any limitations on the power it confers to implement surveillance programmes for the purposes of foreign intelligence or the existence of guarantees for non-US persons potentially targeted by those programmes" (see paragraph 180 of CJEU ruling) and that EO 12333 allows for access to data in transit and does not "delimit in a sufficiently clear and precise manner the scope of ... bulk collection of personal data." (see paragraph 183 of CJEU ruling). See Fieldfisher analysis that "Under FISA, when the government issues directives to a US 'electronic communications service providers' (according to guidance issued by the Department of Justice, this definition is broad enough to capture any company that provides its employees with corporate email or a similar ability to send and receive electronic communications, regardless of the company's primary business or function) that compel the providers to “immediately provide the government with all information, facilities, or assistance necessary to accomplish the acquisition” of communications. In practice, the government sends the providers “selectors” (such as telephone numbers or email addresses) that are associated with specific "targets" (such as a non-US person or legal entity). Service providers must comply with these directives in secret and are not allowed to notify their users." (emphasis added) at https://www.fieldfisher.com/en/insights/us-surveillance-s702-fisa-eo-12333-prism-and-ups Also relevant is the position taken by NOYB on their website at https://noyb.eu/en/next-steps-eu-companies-faqs: "The US Cloud Act gives the US government access to any data, stored anywhere, by US corporations in the cloud, while Section 702 of the Foreign Intelligence Surveillance Act (FISA) allows the US attorney general and director of intelligence services to jointly authorise the targeted surveillance of people outside the US, as long as they are not a US citizen....FISA 702 and EO 12333 have no territorial limitation. They also apply to servers in the EU that are operated by a US “electronic communication service provider” or where certain operations are outsourced to a US provider. The location for hosting is therefore irrelevant(emphasis added)....In some cases, providers may have sufficiently limited the factual access (“possession, custody or control”) from US entities, so that an EU/EEA server is factually beyond the reach of the US government. For example, this may be the case if an EU entity is bound by the GDPR to not provide data to the US parent company and there is no factual access by the US parent company."

[4] See paragraph 53 of EDPB Recommendations 01/2020 on Measures that Supplement Transfer Tools to Ensure Compliance with the EU Level of Protection of Personal Data (Version 2.0)

[5] See Supra Note 2.

[6] See footnote 2 in Annex II COMMISSION IMPLEMENTING DECISION (EU) 2021/914

[7] See Paragraphs 79, 85, 86, 87 and 88 of EDPB Recommendations 01/2020 on Measures that Supplement Transfer Tools to Ensure Compliance with the EU Level of Protection of Personal Data (Version 2.0)

[8] See https://www.anonos.com/data-scientist-expert-opinion

[9] See Supra Note 2.

[10] See Clauses 3 and 12 in Annex II COMMISSION IMPLEMENTING DECISION (EU) 2021/914

This article originally appeared in LinkedIn. All trademarks are the property of their respective owners. All rights reserved by the respective owners.