EU Data Protection and Data Embassy Principles

In the aftermath of Schrems II, supplementary measures are required to avoid unnecessary disruption to international commerce

Data Embassy principles, which are summarised at www.DataEmbassy.com, maximise lawful and ethical secondary data processing of EU personal data, including analytics, AI and ML. They do so by technically enforcing established EU data protection principles to satisfy additional requirements mandated by the Court of Justice of the European Union (CJEU) in Data Protection Commissioner v. Facebook Ireland Limited, Maximillian Schrems (Case C-311/18), “Schrems II.”

Data Embassy principles comprise:

1. GDPR Pseudonymisation: Enforcing GDPR-compliant Pseudonymisation[1] as per ENISA guidelines.[2] This is in accordance with the new standard set by GDPR Article 4(5) requirements that technically enforce WP29 and EDPS recommendations for Functional Separation.[3] Note that the effectiveness of these protections is appealable by data subjects to an EU supervisory authority, ensuring the availability of effective judicial remedy under Article 47 of the EU Charter.
2. Data Minimisation: Enabling Data Minimisation compliant with GDPR Article 5(1)(c) by enforcing Article 25(1) Data Protection by Design and by Default techniques using GDPR-compliant Pseudonymisation.[4]
3. Unlinkable Personal Data: Restricting processing to a form of personal data that does not enable the identification of data subjects as provided under GDPR Articles 11(2) and 12(2) by keeping the “additional information” needed for relinking in the sole possession of the EU-based data exporter. This activates significant and far-reaching changes in a data controller’s obligations that greatly facilitate “compliance with the level of protection essentially equivalent to that guaranteed within the EU by the GDPR.”[5]
4. Demonstrability: Proactive technical enforcement enables data controllers to demonstrate compliance with their accountability and demonstrability obligations under GDPR Article 5(2).
5. Responsibility: Technical and organisational measures enable data controllers to demonstrate compliance with their accountability and responsibility obligations under GDPR Article 24.

 Magali Feys, Data Protection Lawyer - Anonos Chief Strategist - Ethical Data Use

For more information see www.DataEmbassy.com

[1]  It is critical to note that under the GDPR, pseudonymisation is defined as an outcome and not a technique. Before the GDPR, pseudonymisation was widely understood to mean replacing direct identifiers with tokens and was applied to individual fields within a data set. It was merely a Privacy Enhancing Technique (“PET”). In addition, instead of being applied only to individual fields, GDPR pseudonymisation, in combination with the GDPR definition for personal data, now requires that the outcome should apply to a data set as a whole (the entire collection of direct identifiers, indirect identifiers and other attributes). This means that to achieve GDPR-compliant pseudonymisation, you must protect not only direct identifiers but also indirect identifiers. You must also consider the degree of protection applied to all attributes in a data set. Further, to retain any value, you must do so while still preserving the data’s utility for its intended use. As a result, pre-GDPR approaches (using a static token on a direct identifier, which is too often still incorrectly referred to as “pseudonymisation”) will rarely, if ever, meet the heightened GDPR requirements to satisfy “appropriate safeguard” requirements for lawful international data transfers under EU law. The new legal definition of “pseudonymisation” under Article 4(5) requires separation of the information value of data from individual identities so that the only way to re-identify a data subject is by accessing “additional information” that is held separately. Additional information on GDPR compliant pseudonymisation is available at www.Pseudonymisation.com

[2] The ENISA publication Recommendations on Shaping Technology According to GDPR Provisions: An Overview on Data Pseudonymisation at https://www.anonos.com/hubfs/ENISA_Pseudonymisation_Recomendations_GDPR_November_2018.pdf highlights the following benefits, among others, from GDPR-compliant pseudonymisation:

1.     Pseudonymisation serves as a vehicle to “relax” certain data controller obligations, including:

a.     Lawful repurposing (further processing) in compliance with purpose limitation principles;

b.     Archiving of data for statistical processing, public interest, scientific or historical research;

c.     Reduced notification obligations in the event of a data breach.

2.     Pseudonymisation supports a more favourable (broader) interpretation of data minimisation.

3.     Pseudonymisation goes beyond protecting “real-world personal identities” by protecting indirect identifiers.

4.     Pseudonymisation provides for unlinkability between data and personal identity, furthering the fundamental data protection principles of necessity and data minimisation.

5.     Pseudonymisation decouples privacy and accuracy, enabling Data Protection by Design and by Default while at the same time allowing data about individuals to remain more accurate.

Additional information on ENISA guidelines for GDPR compliant pseudonymisation is available at www.ENISAguidelines.com 

[3] Functional separation involves using appropriate safeguards to separate information value from identity to enable the discovery of trends and correlations independent from any subsequent authorised application of the insights gained to the individuals concerned. Under the GDPR, the concept of functional separation is embodied in the Article 4(5) requirement of pseudonymisation that the information value of data be separated from the identity of data subjects and that additional securely stored information be necessary to re-identify under controlled conditions. The Article 29 Working Party, the predecessor to the current European Data Protection Board (EDPB) prior to the GDPR, in Opinion 03/2013 on Purpose Limitation highlighted the “prominent role in our analysis for different kinds of safeguards, including technical and organisational measures to ensure functional separation, such as full or partial anonymisation, pseudonymisation, aggregation of data, and privacy-enhancing technologies.” See https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2013/wp203_en.pdf at pages 13, 26, 27, 29, 30, 31, 32, 33, 40, and 46. In addition, s 2015 report by the European Data Protection Supervisor (“EDPS”), Meeting The Challenges of Big Data – A Call For Transparency, User Control, Data Protection By Design And Accountability, highlighted functional separation as a potential solution to help resolve conflicts between innovative data use and data protection. See https://edps.europa.eu/sites/edp/files/publication/15-11-19_big_data_en.pdf at page 15. Additional information on functional separation is available at www.MosaicEffect.com

[4] Article 25 of the GDPR imposes new requirements for Data Protection by Design and by Default which means organisations must integrate or ‘bake in’ significant data protection capabilities into processing practices, from the design stage through the full data lifecycle. Previously known as ‘Privacy by Design’, this concept has long been part of data protection law. However, two key changes which are newly mandated under the GDPR are:

1.      legal mandate to support more than just privacy by design; Data Protection by Design and by Default requires the most stringent implementation of privacy by design; and

2.     Heightened requirements, including the need to “implement appropriate technical and organisational measures, such as pseudonymisation, which are designed to implement data-protection principles, such as data minimisation.”

[5] Under GDPR Article 11(2), if the purposes for which an organisation processes personal data do not or no longer require identification of an individual, and  if a data controller can show it is not in a position to identify data subjects and has, if possible, notified them of that fact, then it does not need to comply with the following data subject rights:

1.     Article 15 - Right of access by the data subject;

2.     Article 16 - Right to rectification;

3.     Article 17 - Right to erasure ('right to be forgotten');

4.     Article 18 - Right to restriction of processing;

5.     Article 19 - Notification obligation regarding rectification or erasure of personal data or restriction of processing;

6.     Article 20 - Right to data portability;

Provided that under 11(2) the Data Subject may provide additional information enabling his or her identification for the purpose of exercising his or her rights. Likewise, under GDPR Article 12(2), for similar reasons to those outlined for Article 11(2) a data controller again need not act on requests under Articles 15 to 20 as well as:

7.     Article 21 - Right to object, and

8.     Article 22 - Automated individual decision-making, including profiling, because of the nature of the protective measures in place.