Comply with Schrems II with the only Technology built to solve a Legal Problem: Data Embassy

NO. Anonymisation and Pseudonymisation are VERY different under the GDPR. Anonymisation, which is not defined under the GDPR, is an attempt to remove processing from GDPR jurisdiction. To be successful, Anonymisation must delete all means of relinking back to source data, reducing the value of data to near zero. Pseudonymisation is redefined under the GDPR to include functional separation of information value from identity, requiring protection of both direct and indirect identifiers with context-aware, use case-specific controls. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 1 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation a higher standard than pre-GDPR Pseudonymisation. Pseudonymisation is redefined under the GDPR to include functional separation of information value from identity, requiring protection of both direct and indirect identifiers with context-aware, use case-specific controls. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 2 at https://www.SchremsII.com/TenTruths]

NO. Failed attempts at Anonymisation to remove data from GDPR jurisdiction is unlikely to satisfy the new heightened requirements for Pseudonymisation under the GDPR. To be successful, GDPR Pseudonymisation must functionally separate information value from identity, which requires the protection of both direct and indirect identifiers with context-aware, use case-specific controls. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 3 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation requires protection of more than direct identifiers. Pseudonymisation as redefined under the GDPR must functionally separate information value from identity. This requires the protection of both direct and indirect identifiers with context-aware, use case-specific controls. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 4 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation provides greater value than Anonymisation. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 5 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation requires dynamism. Pseudonymisation as redefined under the GDPR must functionally separate information value from identity. This requires the protection of both direct and indirect identifiers with context-aware, use case-specific controls that use different tokens at different times for different purposes to avoid unauthorised reidentification via the Mosaic Effect. Newly redefined GDPR Pseudonymisation maximises both the protection and value of data by enabling auditable, dynamically enforced control over who, when and why information value is linkable to identity. [See Truth No. 6 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation can satisfy Schrems II requirements for Technical Supplementary Measures. A central tenet of GDPR-compliant Pseudonymisation is separation of information value from the identity of the data subjects, where the sole means to relink the Pseudonymised data to the underlying identities is via “additional information.” This additional information must be stored separately and securely and access must be restricted as per established policies and controls. This separation, when implemented correctly, satisfies a crucial requirement of Schrems II as well as GDPR Article 11(1), which states:

If the purposes for which a controller processes personal data do not or do no longer require the identification of a data subject by the controller, the controller shall not be obliged to maintain, acquire or process additional information in order to identify the data subject for the sole purpose of complying with this Regulation.

GDPR-compliant Pseudonymisation can enable cross border data transfers to happen lawfully and securely, unlike in the past where data service providers in the EU had to resort to legal treaties like the Privacy Shield to make this happen. With GDPR-compliant Pseudonymisation, data exporters and vendors in the EU can lawfully use cloud based data processing solutions, even when they are located outside of the EU (or operated in the EU by US or other non-EEA/Adequacy Countries subject to obligations to disclose data), because the additional information required to relink the data to identities of data subjects is available only in the EU under the control of the data controller. Even if this data were to be intercepted, properly GDPR Pseudonymised data does not expose the identities of EU subjects. As more use cases of lawful cross border data sharing and transfers emerge and more organizations realise the benefits of GDPR Pseudonymisation, we will likely see exponential increase in the adoption and implementation of GDPR-compliant Pseudonymisation. [See Truth No. 7 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation enables EU-based redress for failure to properly Pseudonymise data. Under GDPR, if there is a breach in user privacy arising out of improperly pseudonymised data, then the data controller or service provider in the EU responsible for sharing, distributing or transferring this data can be held accountable. This legal safeguard provides EU subjects with access to legal recourse within the jurisdiction of the EU, instead of having to rely on legal mechanisms outside of the EU for redress. This also serves as a strong incentive for the data controller to ensure that it has properly Pseudonymised data in compliance with GDPR requirements, lest it expose itself to lawsuits, claims or injunctive relief (termination of processing by supervisory authorities. [See Truth No. 8 at https://www.SchremsII.com/TenTruths]

YES. GDPR Pseudonymisation is an example of distributed trust controls to enable trusted data. The ubiquitous availability of high speed Internet and convergence of technologies such as 5G, IoT, Big Data and cloud computing has led to a prodigious amount of data being generated and shared across industry verticals. This poses security and privacy risks – how do we ensure that this data is transferred safely and only used in an appropriate way? Advanced data protection techniques such as GDPR-compliant Pseudonymisation, that more effectively address data privacy concerns, help to meet these challenges. By embedding distributed trust controls in data transfers, distribution and sharing, GDPR Pseudonymisation helps to facilitate wider and faster adoption of these technologies, while ensuring compliance with GDPR and other applicable laws. [See Truth No. 9 at https://www.SchremsII.com/TenTruths]

YES. Pseudonymisation satisfying heightened requirements under the GDPR enables significant statutory benefits. Pseudonymisation can not only help data controllers comply with GDPR regulations, it can also enable a host of GDPR statutory benefits such as:

• Tip the balance in favor of Legitimate Interests processing (GDPR Articles 5(1)(a) and 6(1)(f) and WP 217)
• Allow more flexible change of purpose (GDPR Article 5(1)(b) and WP 203)
• Allow more expansive data minimisation (GDPR Articles 5(1)(c) and 89(1))
• Allow more flexible storage limitation (GDPR Articles 5(1)(e) and 89(1))
• Provide enhanced security (GDPR Articles 5(1)(f) and 32)
• Facilitate more expansive further processing (GDPR Article 6(4) and WP 217)
• Allow more flexible profiling (WP 251 rev.01 - Annex 1 and GDPR Recital 71 and Article 22
• Allow lawful sharing and combining of data (GDPR Recitals 42 and 43, Articles 11(2) and 12(2), and EDPB Guidelines 05/2020)

[See Truth No. 10 at https://www.SchremsII.com/TenTruths]

NO. Privacy guarantees associated with differential privacy provide minimum real-world value. While mathematically elegant, differential privacy guarantees reflect the artificial use constraints imposed on data, processes and users necessary for differential privacy to work. These artificial use constraints are inconsistent with real-world data use conditions, so differential privacy is not realistic for real-world distributed processing removed from protected enclaves.

NO. Watermarks offered in connection with differential privacy solutions provide minimum real-world value. They serve to identify the party responsible for violating the artificial use (enclave) constraints necessary for differential privacy to work. However, once a party violates these artificial use (enclave) constraints, the effectiveness of differential privacy is nullified.

YES. Differential privacy provides the “worst of all worlds” under the GDPR since the data is neither Anonymous so it outside of the scope of GDPR jurisdiction (because the data controller retains the original identifying data) nor is it GDPR-compliant Pseudonymous and entitled to the statutory benefits identified in FAQ 10 above (because the direct and indirect identifiers are not protected to prevent reidentification without “additional information” that is kept separately and securely as required under Article 4(5))

NO. Synthetic data does not protect real-time dynamically changing data. Synthetic data requires recalibration of all of the interrelationships and correlations within a synthetically prepared data set each time material changes occur in the underlying data, so it can only provide “after the fact” versus real-time protection.

NO. Neither differential privacy nor synthetic data enable relinking to identity for longitudinal studies, nor the ability to contact at-risk study participants.

NO. Processing that takes 1 second using GDPR Pseudonymised data or cleartext data will take several days using Homomorphic Encryption. Sophisticated business processes cannot tolerate such speed. While advances are being made in Homomorphic Encryption, its high computational overhead and extended processing times result in a high carbon footprint making it impracticable for sophisticated decentralised data processing, sharing, combining, relinking or longitudinal studies in the near future.

No. There is no grace period for complying with Schrems II – the obligation to comply was immediate upon the ruling of the CJEU on 16 July 2020.

NO. New SCCs cannot be used without Technical Supplementary Measures. Technical Supplementary Measures are required whenever there is a surveillance risk in the initial or any subsequent destination country. In these situations, Contractual and Organisational Supplementary Measures alone are not sufficient.

NO. In the Schrems II ruling, the Court of Justice of the European Union was adamant that SCCs can only be lawful if supplemented by Technical Supplementary Measures when there is any surveillance risk in the initial or any subsequent destination country. In these situations, Contractual and Organisational Supplementary Measures alone are not sufficient.

No. Updating SCCs is not enough. SCCs “are not capable of binding the authorities of that third country, since they are not party to the contract.” Schrems II requires the implementation of technically-enforced Supplementary Measures for transfers to non-EEA / Adequacy Countries henever there is a surveillance risk in the initial or any subsequent destination country. In these situations, Contractual and Organisational Supplementary Measures alone are not sufficient.

Yes. Unless you implement Technical Supplementary Measures that ensure an essentially equivalent level of protection, “you must avoid, suspend or terminate” all international data transfers based on SCCs.

Under the CJEU ruling, Supervisory Authorities have an affirmative obligation to stop transfers that do not comply with Schrems II requirements. In addition to business operation disruptions from termination of data flows, companies face penalties of €20 million or 4% of their global turnover, whichever is greater.

Yes. Due to the significant publicity regarding the potential negative effects of Schrems II, lack of corporate change may constitute “wilful blindness to a course of action” or “reckless conduct by knowing of the risk but doing nothing.” This opens Board members and senior executives to potential personal and criminal liability. In addition, auditors have an obligation to report data protection violations to authorities under the International Ethics Standards Board for Accountants (IESBA), and Non-compliance with Laws and Regulations (NOCLAR).

No. Encryption only protects data in transit and in storage. Anonymisation is not recognised as a suitable Schrems II Supplementary Measure by the European Data Protection Board (EDPB). Schrems II requires organisations to protect data when in use by using technically-enforced Supplementary Measures that protect data from unauthorised access. These technical controls must ensure that EU personal data does not reveal the identities of data subjects when processed outside of EEA / equivalency countries. Processing of personal data in the clear outside of the EEA / Adequacy Countries is unlawful under Schrems II.

The EDPB highlights two use cases of data transfers that are unlawful under Schrems II: (i) Transfer to Cloud Services Providers or Other Processors Which Require Access to Data in the Clear (EDPB Unlawful Use Case 6); and (ii) Remote Access to Data for Business Purposes (EDPB Unlawful Use Case 7).

The EDPB has highlighted the transfer of GDPR Pseudonymised data (EDPB Lawful Use Case 2) as lawful. This means that Cloud Processing and Remote Access for Business Purposes (EDPB Unlawful Use Cases 6 and 7) can be made legal by transforming data into GDPR-Pseudonymised data (Lawful Use Case 2) before processing in the cloud or making it available for remote access.