The EDPB notes in their Schrems II preliminary guidance that “Transfer to cloud services providers or other processors which require access to data in the clear” (EDPB Use Case 5)[1] is unlawful. 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 we are asked regarding the use of EDPB Use Case 2 (Pseudonymisation) for transforming otherwise unlawful EDPB Use Case 5 (Cloud-based Processing).
Q1: Does Pseudonymising EU data after it is in US-operated clouds or other technology platforms resolve Schrems II issues?
A1: No, Pseudonymisation must occur prior to transferring EU Personal Data to a US-operated cloud or other third-country-operated infrastructure. However, Supervisory Authorities may hesitate to strictly enforce this requirement to provide companies the opportunity to remediate data already in the cloud by Pseudonymising it.
Subject to the possible one-time exception for remediation of data already in the cloud, EDPB Use Case 2 requires that the Pseudonymisation be performed by an EU data exporter prior to transferring the data to the cloud or other infrastructure. Adequate technical and organisational measures must be in place to ensure the non-relinkability of the EU data to identities without the use of “Additional Information” (sometimes referred to as “Keys”). These Keys must remain in the possession of the EU data exporter or a specifically enumerated authorised EU-based third-party, which clearly does not include US cloud or other third-country technology providers.
The above results are possible using advanced Pseudonymisation techniques that satisfy the requirements of GDPR Article 4(5)[3] in accordance with best practices established by the European Cybersecurity Agency (ENISA).[4]
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 data in US-operated clouds and other third-party-operated infrastructures:
First, cleartext EU personal data in US operated clouds and other third-party infrastructures can be replaced with properly Pseudonymised data. In the highest value use cases of Advanced Analytics, AI and ML, the results produced by lawfully processing GDPR-compliant Pseudonymised data have 100% accuracy and fidelity when compared to the results of processing in the clear.[5] 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.
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: How do cloud-native business applications comply with Schrems II requirements?
A3: In contrast to cloud-based Advanced Analytics, AI and ML which can be successfully supported using GDPR-compliant Pseudonymisation (see FAQ 2 above), cloud-native business applications like O365, M365, and D365 must either (i) be supported by an Article 49 derogation or (ii) arrangements must be made for a non-cloud-based solution to comply with Schrems II requirements.
GDPR Article 28(1) imposes an affirmative obligation on controllers to “use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of [the GDPR] and ensure the protection of the rights of the data subject.” While US cloud and other third-country infrastructure operators stress that they have valid Standard Contractual Clauses (SCCs) in place, SCCs by themselves do not make processing lawful under Schrems II. The Schrems II ruling holds emphatically that Supplementary Measures are required. However, cloud providers operate under a “Shared Responsibility Model”,[6] which makes it clear that responsibility for ensuring the lawfulness of application-specific data is the obligation of the data controller. A careful reading of cloud provider data protection addendums verifies this result.
Q4: What is the penalty for Schrems II non-compliance?
A4: In the Schrems II ruling, the CJEU states five times that the GDPR-required remedy for violating Schrems II requirements is injunctive termination of processing since monetary damages cannot repurchase fundamental rights[7] This highlights the immediate potential disruption to business operations and shifts the burden of proof onto data controllers to regain the right to process data. Since there is no grace period, compliance became mandatory as of the CJEU ruling in July 2020. Now, eight months later organisations must evaluate the availability of defences to overcome potential claims of non-compliance. Waiting to establish a defensible position for using US-based and other non-EEA cloud, SaaS, and outsourcing solutions creates the risk of personal exposure for Board members and officers.[8] This risk is even more significant in the UK, where the UK GDPR includes additional provisions that impose criminal liability for non-compliance.[9] In addition, auditors are starting to evaluate whether adequate balance sheet/claims reserves are set aside for future Schrems II-related losses and are obligated to report non-compliance to authorities.[10]
Q5: What is the Most Important Supplementary Measure for Schrems II compliance?
A5: The EDPB recognises three types of Supplementary Measures – Contractual, Organisational, and Technical Supplementary Measures. However, the EDPB states that only one of the three types of supplementary measures is suitable for protection against foreign governments: technical measures.[11]
The EDPB highlights GDPR-compliant Pseudonymisation as a Technical Supplementary Measure that “travels with the data.”[12]
Anonos is the source for GDPR-compliant Pseudonymisation that meets the state-of-the-art requirements of the GDPR. Click here for more information on Pseudonymisation.
The EDPB highlights the importance of best practices established by the European Union Agency for Cybersecurity (ENISA).[13] ENISA has released guidelines on requirements for GDPR-compliant Pseudonymisation. Click here to view information on how Anonos meets all 50 of these requirements.
Other Resources:
The Board Risk Assessment Framework is now available to view and download at https://www.SchremsII.com/Board2
Join the Schrems II Linkedin Group with over 4,800 of your colleagues: https://www.linkedin.com/groups/12470752/
Are you Schrems II Compliant Quiz (in 2 questions): https://www.anonos.com/TakeTheQuiz
[1] See Use Case 6: Transfer to cloud services providers or other processors which require access to data in the clear at paragraphs 88 and 89 of EDPB Recommendations 01/2020 on Measures that Supplement Transfer Tools to Ensure Compliance with the EU Level of Protection of Personal Data at https://edpb.europa.eu/sites/edpb/files/consultation/edpb_recommendations_202001_supplementarymeasurestransferstools_en.pdf
[2] Id, at paragraphs 80 - 83.
[3] Id, see footnote 69.
[4] Id, see paragraph 135. See also https://www.enisaguidelines.com.
[5] See https://www.anonos.com/data-scientist-expert-opinion
[6] See https://cloudsecurityalliance.org/blog/2020/08/26/shared-responsibility-model-explained/
[7] See
http://curia.europa.eu/juris/document/document.jsf?text=&docid=228677&pageIndex=0&doclang=EN&mode=lst&dir=&occ=first&part=1&cid=9745404 at paragraphs 121, 135, 146, 154, and 203(3)
[8] See https://normcyber.com/advisory-note/data-protection-directors-personal-liability/ and https://www.financierworldwide.com/roundtable-risks-facingdirectors-officers-aug17.
[9] UK data protection law includes sections 171 and 198, not found in the EU GDPR. Under Section 171, it is a criminal offense to knowingly or recklessly re-identify information that is de-identified personal data without the consent of the controller responsible for de-identifying the personal data. Under Section 198, a “director, manager, secretary or similar officer of the body corporate” may be found personally liable for failing to comply with data protection requirements “by consent, connivance, or in a way that is attributable to neglect.”
[10] See International Ethics Standards Board for Accountants (IESBA) Non-compliance with Laws and Regulations at
https://www.ifac.org/system/files/publications/files/IESBA-NOCLAR-Fact-Sheet.pdf at page 3. Also, Accountancy Europe, which unites 50 professional organisations from 35 countries, notes that when non-compliance is committed intentionally, it “may be considered as fraud by stakeholders” and notes that this is “particularly relevant in case of breaches of …data protection rules” (emphasis added). See https://www.accountancyeurope.eu/wp-content/uploads/Fraud-recommendations-to-strengthen-the-financial-reporting-ecosystem.pdf at page 5.
[11] Id, at paragraph 48.
[12] Supra, Note 1 at Executive Summary where the EDPB states “In its recent judgment C-311/18 (Schrems II) the Court of Justice of the European Union (CJEU) reminds us that the protection granted to personal data in the European Economic Area (EEA) must travel with the data wherever it goes.”
[13] Id, at paragraph 135.
This article originally appeared in Linkedin. All trademarks are the property of their respective owners. All rights reserved by the respective owners.
CLICK TO VIEW CURRENT NEWS
