These quotesi highlight why Pseudonymisation is the most misunderstood and underutilised means to achieve simultaneous data enablement and protection under the GDPR and globally.
After the Schrems II ruling, the debate on Pseudonymisation has gained momentum as many consider it as the most viable “supplementary measure” to transfer personal data to third countries not offering an equivalent level of protection.iiquote icon
Thomas Zerdick, Head of Technology and Privacy - European Data Protection Supervisor (EDPS)
Data Controllers may not be aware that the GDPR encourages the use of Pseudonymisation. I think that there are more than 16 occurrences of Pseudonymisation in the GDPR. And they are not aware that Pseudonymisation helps to reduce the risks associated with processing data and can help relax some GDPR obligations.iiiquote icon
Monir Azraoui, Technology Expert at Commission Nationale de l'informatique et des Libertés (CNIL)
Book
Click here to read the GDPR Pseudonymisation Memorandum submitted to EDPB Public Consultation on Guidelines 05/2021
READ MEMORANDUM
Unprotected Processing
by Default
  • Immediately Identifiable Data – data that includes information (e.g., name, country code number, address, etc.) that immediately reveals the identity of one or more individuals.
  • Readily Reidentifiable Data – data containing information that is not or is no longer immediately identifiable (using techniques that make it “less easy” to immediately identify an individual within a data set, such as by replacing names or other immediately identifying data with a recurring reference number or token), but for which reidentification remains easily accomplished by evaluating combinations of fields within a specific data set or through the use of readily available additional information.
Data Protection by Design and
by Default
  • Practicably Protected Data – data protected using techniques that make it impracticable to identify an individual within one or several specific data sets, without access to additional information held separately by the data controller or other authorised party (e.g., GDPR-compliant pseudonymisation).
  • Unlinkably Protected Data – data protected using techniques that make identifying an individual within one or several specific data sets impossible (e.g., GDPR-compliant anonymisation).

GDPR Pseudonymisation Software Embeds Controls that Travel with the Data to Maximize Its Value Lawfully

  • Maintain 100% accuracy compared to processing unprotected clear text
  • Enable up to 16X improved speed to insight by increasing the number of projects approved by 4X and reducing the time for privacy reviews by 75%
  • Eliminate restrictions on global data use by creating lawful borderless data for compliant Analytics, AI & ML

EDPB Recommends GDPR Pseudonymisation

Schrems II Unlawful Use Cases
USE CASE 6
Transfer to Cloud Services Providers or Other Processors Which Require Access to Data in the Clear
USE CASE 7
Remote Access to Data for Business Purposes
Schrems II Lawful Use Cases
USE CASE 1
Data Storage For Backup And Other Purposes That Do Not Require Access To Data In The Clear
USE CASE 2
Transfer Of Pseudonymised Data
USE CASE 3
Encrypted Data Merely Transiting Third Countries
USE CASE 4
Protected Recipient
USE CASE 5
Split or Multi-Party Processing
EDPB Recommendations https://edpb.europa.eu/system/files/2021-06/edpb_recommendations_202001vo.2.0_supplementarymeasurestransferstools_en.pdf
Pseudonymisation is recognised by the EDPB as a key supplementary measure that can be used to support continued processing under Schrems II.

GDPR Pseudonymisation FAQs

1 What are the Requirements for GDPR Pseudonymisation?
The definition of Pseudonymisation in GDPR Article 4(5) requires that the information value of data must be separated from the identity of data subjects and that additional securely stored information must be necessary to re-identify data subjects, and then only under controlled conditions. Under this new definition, GDPR-compliant Pseudonymisation is now defined as an outcome and not a technique.

With the elevation of Pseudonymisation to an outcome, to achieve GDPR-compliant Pseudonymisation it has become necessary to protect not only direct identifiers but also indirect identifiers. In addition, instead of being applied only to individual fields, GDPR-defined Pseudonymisation, in combination with the GDPR definition for Personal Data,iv requires that the outcome must apply to a data set as a whole (the entire collection of direct identifiers, indirect identifiers and other attributes), and consideration must be given to the degree of protection applied to all attributes in a data set.

With respect to the GDPR Article 4(5) requirement that the additional information necessary to relink to the identity of data subjects be kept separately and subject to technical and organisational measures:
  • This refers to the outcome for a dataset, not just treatment of individual fields in isolation: and
  • Requires more than mere possession by the data controller or other authorised party of information enabling reidentification. Instead, this requires that technical and organisational measures are implemented that make it impracticable for third parties to identify an individual without access to the specific additional information held separately by the data controller or other authorised party.
2 What are the Requirements for Using Pseudonymisation for Schrems II Compliance?
The following are the requirements for using EDPB Use Case 2: Transfer of Pseudonymised Datav as a compliant Schrems II supplementary measure:
  • Protecting all data elements: Footnotes 83 and 84 of the “EDPB Schrems II Recommendations”vi 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, and 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 Schrems II Recommendations requires 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 Schrems II Recommendations to protect against the use of information from different datasets to re-identify data subjects necessitates the use of different replacement tokens for differing purposes at different times (i.e., dynamism) to prevent re-identification by leveraging correlations among data sets without needing access to the “additional information held separately” by the EU data controller (see https://www.MosaicEffect.com);
  • Non-algorithmically-derived lookup tables: the requirement of Paragraph 89 of the EDPB Schrems II Recommendations 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-algorithmically-derived look-up tables in many instances; and
  • Controlled relinkability: The combination of the four preceding items are necessary to meet the requirement in Paragraph 85(1) of the EDPB Schrems II Recommendations 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.”
3 Does GDPR Compliant Pseudonymisation Enable Lawful Public Cloud Processing?
Yes. The processing of data that has been properly pseudonymised to GDPR requirements as described in FAQ 2 is lawful in public clouds provided the information necessary to relink the information to data subjects is under the exclusive control of an EU Data Controller as described in FAQ 2.vii
4 Does GDPR Compliant Pseudonymisation Enable Schrems II Derogations?
Yes. GDPR-compliant Pseudonymisation helps to enable lawful international transfer and processing of global data, including EU personal data, by establishing by default the processing of GDPR-compliant pseudonymised data as discussed in FAQs 1 and 2 above, whenever, wherever, and as often as possible to ensure protected processing within the control of the EU Data Controller, so that non-pseudonymised (i.e., identifying) data is processed only when necessary (helping to satisfy GDPR Articles 5(1)(b) Purpose Limitation and 5(1)(c) Data Minimisation requirements), provided that:
  • There is a legal basis to do so under Article 6 (e.g., based on Article 6(1)(a) consent, 6(1)(b) contract, 6(1)(f) legitimate interests, or 9(2)(j) scientific research by leveraging GDPR Pseudonymisation-enabled technical and organisational measures to satisfy the "balancing of interests" test); and
  • The processing satisfies derogation requirements (e.g., Article 49(1)(a) based on consent, Articles 49(1)(b) or (c) based on contract), which were expanded in the EDPB Schrems II Recommendations to enable repetitive use for specific situations.viii
5 Does GDPR Compliant Pseudonymisation Help to Enable Lawful Data Repurposing, Sharing and Combining?
Yes. Pseudonymisation is explicitly highlighted in GDPR Article 6(4)(e) as an “appropriate safeguard” that can be used by data controllers “in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected.”ix
6 Does GDPR Compliant Pseudonymisation Enable Legitimate Interest Processing When Consent and Contract are Not Enough?
Yes. Properly pseudonymised data (see FAQs 1 and 2 above) is recognized in the Article 29 Working Party Opinion 06/2014 as playing “…a role with regard to the evaluation of the potential impact of the processing on the data subject...tipping the balance in favour of the controller” to help support Legitimate Interest processing to protect data in use.x

The benefits of processing personal data using compliant Legitimate Interests processing as a legal basis under the GDPR include:
  • Under Article 17(1)(c), if a data controller can show they “have overriding legitimate grounds for processing” supported by technical and organizational measures to satisfy the balancing of interest test, they have greater flexibility in complying with Right to be Forgotten requests.
  • Under Article 18(1)(d), a data controller has flexibility in complying with requests to restrict the processing of personal data if they can show they have technical and organizational measures in place so that the rights of the data controller properly override those of the data subject because the privacy of the data subject is protected.
  • Under Article 20(1), data controllers properly using Legitimate Interests processing are not subject to the right of portability, which applies only to consent-based processing.
  • Under Article 21(1), a data controller properly using Legitimate Interests processing may show they have adequate technical and organizational measures in place so that the rights of the data controller properly override those of the data subject because the rights of the data subjects are adequately protected. However, data subjects always have the right under Article 21(3) to not receive direct marketing outreach as a result of such processing.
7 Does GDPR Compliant Pseudonymisation Relax Certain Re-Identification Obligations?
Yes.
  • Pseudonymisation helps to enable Article 11(2) relaxation of obligations to data subjects under Articles 15 (Right of Access by Data Subject), 16 (Right to Rectification), 17 (Right to Erasure - Right to be Forgotten), 18 (Right to Restriction of Processing), 19 (Notification Obligation Regarding Rectification or Erasure of Personal Data or Restriction of Processing), and 20 (Right to Data Portability) when processing does not require identification, if the data controller is not in a position to identify data subjects and the controller has informed data subjects accordingly. Data controllers not in possession of “Additional Information” necessary for re-identification satisfy this requirement.xi
  • Pseudonymisation helps to enable Article 12(2) relaxation of obligations under Articles 15 (Right of Access by Data Subject), 16 (Right to Rectification), 17 (Right to Erasure - Right to be Forgotten), 18 (Right to Restriction of Processing), 19 (Notification Obligation Regarding Rectification or Erasure of Personal Data or Restriction of Processing), and 20 (Right to Data Portability) in addition to the relaxation of obligations under Articles 21 (Right to Object to Automated Decision-Making) and 22 (Automated Individual Decision-Making, Including Profiling) to provide transparent information, communication and modalities for the exercise of the rights of the data subject if the data controller can demonstrate it is not in a position to identify data subjects. Data controllers not in possession of “Additional Information” necessary for re-identification satisfy this requirement.
8 Does GDPR Compliant Pseudonymisation Enable Privacy-Respectful Profiling and Digital Marketing?
Yes.
  • Pseudonymisation may help to reduce the risk that profiling “produces legal effects concerning [data subjects] or similarly significantly affects [data subjects]” under Article 22(1) if it is left up to the data subject whether to choose to participate in opportunities presented to them as a member of a properly implemented pseudonymised group.
  • Pseudonymisation may help to reduce the risk that profiling “decision[s are made] based solely on automated processing” under Article 22(1) if it is left up to the data subject whether to choose to participate in opportunities presented to them as a member of a properly implemented pseudonymised group.
  • Pseudonymisation may help to enable Article 22(2)(b) support for processing “authorised by Union or Member State law to which the controller is subject and which also lays down suitable measures to safeguard the data subject's rights and freedoms and legitimate interests.”
  • Pseudonymisation may help to enable Article 22(4) allowance for decisions “based on special categories of personal data referred to in Article 9(1)” premised on Article 9(2)(g) Union or Member State laws by ensuring that “suitable measures to safeguard the data subject's rights and freedoms and legitimate interests are in place.”
9 Does GDPR Compliant Pseudonymisation Help to Enable Data Protection by Design and by Default Obligations?
Yes.
  • Article 25(1) requires data controllers - for both primary and secondary processing - to “implement appropriate technical and organisational measures, such as Pseudonymisation.” (emphasis added)
  • Pseudonymisation helps data controllers to satisfy their obligations under Article 25(2) to “implement appropriate technical and organisational measures for ensuring that, by default, only personal data which are necessary for each specific purpose of the processing are processed.”
10 Does GDPR Compliant Pseudonymisation Help with Security and Data Breach Obligations?
Yes.
  • Article 32 explicitly recognises Pseudonymisation and encryption as measures to be considered when “taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk."
  • Pseudonymisation helps to ensure that data breaches are “unlikely to result in a risk to the rights and freedoms of natural persons.” This would mean that an incident would not qualify as a data breach under GDPR and thus would not have to be notified to a supervisory authority under Article 33, nor be communicated to data subjects under Article 34.
11 Does GDPR Compliant Pseudonymisation Help with Data Protection Impact Assessments?
Yes.
  • Pseudonymisation helps to satisfy Article 35(3)(b) obligations for “processing on a large scale of special categories of data referred to in Article 9(1).”
  • Pseudonymisation helps to satisfy that the Article 35(8) creation of and adherence to “approved codes of conduct referred to in Article 40 by the relevant controllers or processors shall be taken into due account in assessing the impact of the processing operations performed by such controllers or processors, in particular for the purposes of a data protection impact assessment.”
  • Pseudonymisation helps to enable Article 35(10) elimination of separate data protection impact assessment obligations under Articles 35(1)-(7) “[w]here processing pursuant to point (c) or (e) of Article 6(1) has a legal basis in Union law or in the law of the Member State to which the controller is subject, that law regulates the specific processing operation or set of operations in question, and a data protection impact assessment has already been carried out as part of a general impact assessment in the context of the adoption of that legal basis.”
12 Does GDPR Compliant Pseudonymisation Expand Lawful Processing?
Yes.
  • Article 89(1) provides that “processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include Pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner.”
  • Article 89(1) Pseudonymisation-enabled processing enables greater flexibility under:
    • Article 5(1)(b) with regard to purpose limitation;
    • Article 5(1)(e) with regard to storage limitation; and
    • Article 9(2)(j) with regard to overcoming the general prohibition on processing Article 9(1) special categories.
13 Does GDPR Compliant Pseudonymisation Help to Enable Processing of Special Category Data?
Yes.
  • Pseudonymisation may help to satisfy the Article 9(2)(g) exception to the general prohibition against the processing of special category data if the “processing is necessary for reasons of substantial public interest, on the basis of Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject.”
  • Pseudonymisation may help to satisfy the Article 9(2)(i) exception to the general prohibition against the processing of special category data if the “processing is necessary for reasons of public interest in the area of public health, such as protecting against serious cross-border threats to health or ensuring high standards of quality and safety of health care and of medicinal products or medical devices, on the basis of Union or Member State law which provides for suitable and specific measures to safeguard the rights and freedoms of the data subject, in particular professional secrecy.”
  • Pseudonymisation may help to satisfy the Article 9(2)(j) exception to the general prohibition against the processing of special category data if the “processing is necessary for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) [which explicitly cites Pseudonymisation] based on Union or Member State law which shall be proportionate to the aim pursued, respect the essence of the right to data protection and provide for suitable and specific measures to safeguard the fundamental rights and the interests of the data subject.”

Anonos Data
Embassy Software

Anonos Data Embassy® GDPR Pseudonymisation software enables companies to address privacy challenges while expanding lawful data use, sharing, and combining for all stakeholders in global data supply chains.

Data Embassy software produces state-of-the-art Variant Twins® (i.e., use case specific privacy-respectful versions of “digital twin” data) that protect both direct identifiers (e.g., passport number, credit card numbers) and indirect identifiers (e.g., date of birth, zip code, gender) to enable lawful complex processing of EU personal data.

Variant Twins create unmatched competitive benefits, not only preserving data processing and data accuracy, but also exponentially increasing Analytics, AI & ML opportunities.

Comparison of GDPR Pseudonymisation to Other Privacy Enhancing Technologies:
Chart

Click to Enlarge

The above chart compares a wide range of privacy enhancing technologies (PETs). After listing them, they are classified as using either cryptographic or non-cryptographic techniques (or in the case of Pseudonymisation, both).

The balance of the chart to the right is a “knock-out” analysis of the technologies using a series of evaluation and elimination criteria. In this analysis, once a PET has been eliminated, it is no longer evaluated against subsequent criteria.

The first criteria in column (1) is protection of data during computation for uses such as analytics, AI and machine learning. This is sometimes called protection in use, to contrast it with protection of data at rest and in transit. Encryption is the de facto standard for protection of data at rest and in transit, but is successful at doing so precisely because it renders data unusable for computation and does not protect data when in use.

The second criteria in column (2) considers the ability of the PET to provide results that deliver detailed record level protection. Differential Privacy and cohorts/clusters by definition provide aggregate results rather than record level results and thus fall out at this point.

The third criteria in column (3) looks at how well a PET succeeds at delivering effective protection, while preserving utility comparable to processing cleartext. Each of the PETs receiving a “No” evaluation suffers from an inability to resolve a fundamental tradeoff between protection and utility. Greater protection invariably results in a loss of utility and preservation of utility results in weaker protection, regardless whether the approach adds noise, masks or generalizes values, or synthesizes artificial data.

The fourth criteria in column (4) involves the ability of a PET to efficiently and effectively support AI and machine learning. Multi-party computing fails in this regard as a result of massive bandwidth requirements to coordinate calculations between participating nodes. Similarly, homomorphic encryption is not computationally feasible at the time and data volume scales required by these analytical techniques. And any future advances in computation power will still always leave them orders of magnitude slower than other PETs, which will also benefit relative to today’s performance from the additional computational power and speed.

The fifth criteria in column (5) looks at the ability of the remaining options to enable data-sharing and multi-cloud use cases. Confidential Computing via a Trusted Execution Environment, which has fared well up to this point now also drops out, as by its nature, the trusted execution environments that are used to achieve confidential computing are by design impenetrable silos, antithetical to data sharing.

At this point, the remaining PETs are GDPR Pseudonymisation and Anonos Data Embassy Variant Twins software, which not coincidentally leverages GDPR Pseudonymisation. Among PETs, only GDPR Pseudonymisation simultaneously:
  • Protects data during computation for analytics
  • Provides accurate (vs cleartext) record-level results
  • Reconciles the trade-off between protection and utility
  • Supports AI and machine learning
  • Supports data sharing and multi-cloud use cases
The sixth and final criteria in column (6) involves the ability to deliver scalable digital enforcement of enterprise-level data protection policies and controlled relinking, which knocks out GDPR Pseudonymisation as at PET standing on its own. Anonos Data Embassy Variant Twins succeed as the remaining PET by combining GDPR-Pseudonymisation with other PETs that do not distort data or add noise (e.g., masking, generalisation, tokenisation, and k-anonymity) and leverages patented technologyxii to enable:
  • The use of different pseudonyms at different times for different purposes (i.e., dynamism);
  • Controlled-Relinkability that allows relinking from protected subsets of data to the entire original source data sets under controlled conditions; and
  • Digital enforcement of Privacy Policies.
WHAT PSEUDONYMISATION NOW REQUIRES
Pseudonymisation is newly-defined in the GDPR, and is not the same as the old form of Pseudonymisation, which was primarily simple tokenisation of direct identifiers.

The GDPR requires that the "state-of-the-art" be taken into account when applying technical and organisational measures to protect data (Article 32). What is the state-of-the-art when it comes to Pseudonymisation?
Anonos technology is the only solution that meets all 50 Best Practices.
You can view a comparison of Anonos technology with the Best Practices here VIEW 50 BEST PRACTICES Anonos was granted European Patent 3,063,691 in 2020 for state-of-the-art technology that balances data protection and utility.

Anonos guarantees that it achieves the highest level of Schrems II and GDPR compliance while also enabling high data value and utility for global lawful borderless data.

REFERENCES TO EDPB, EDPS, ENISA OR THE CNIL DO NOT INDICATE ANY RELATIONSHIP, SPONSORSHIP, OR ENDORSEMENT BY SUCH PARTIES. ALL REFERENCES TO SUCH PARTIES CONSTITUTE NOMINATIVE FAIR USE UNDER APPLICABLE TRADEMARK LAWS.
LinkedIn Group Click to Join the LinkedIn Group