# Pseudonymization (Article 4(5) GDPR)

Pseudonymization as a technical and organizational measure: separation of the additional information, distinction from anonymization, the persisting link to a person, and special forms such as encryption and de-identification.

> Quelle: https://www.thomashelbing.com/en/wissen/dsgvo-hub/begriffe-und-definitionen/1.2.5-pseudonymisierung
> Sprache: en



Pseudonymization is the processing of personal data in such a manner that the personal data can no longer be attributed to a specific person without the use of separately kept additional information (Article 4(5) GDPR). It is not a data type of its own but a protective measure that reduces the risk of linking a data record to an identity. Pseudonymized data remain personal data.

<Callout type="info">
  * Pseudonymization separates the data record from the additional information, which is kept separately and protected by technical and organizational measures (Article 4(5) GDPR).
  * Pseudonymized data remain personal data and continue to be fully subject to the GDPR.
  * It must be distinguished from anonymization: only the latter removes data from the scope of the GDPR.
  * The GDPR treats pseudonymization as a risk-reducing measure, for example in data protection by design (Article 25 GDPR) and in the security of processing (Article 32(1)(a) GDPR).
  * Encryption, too, is in substance a form of pseudonymization, as long as a key allows the data to be made readable again.
</Callout>

## 1. Overview [#1-overview]

### 1.1 Legal definition and function [#11-legal-definition-and-function]

Article 4(5) GDPR defines pseudonymization as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information. The precondition is that such additional information is kept separately and is subject to technical and organizational measures that ensure the absence of attribution.

The word "pseudonym" stands for an invented name or alias. In substance, the real name or another identifying feature is replaced by an identifier, so that identifying the person is precluded or substantially impeded. Earlier data protection law already knew this idea; § 3a of the former German Federal Data Protection Act (BDSG) required pseudonymization primarily as a privacy-friendly design.

### 1.2 Legal nature: a measure, not a data type [#12-legal-nature-a-measure-not-a-data-type]

Pseudonymization is not a constituent element of the concept of [personal data](/docs/dsgvo-hub/begriffe-und-definitionen/1.2.1-personenbezogene-daten), but a technical and organizational measure. It reduces the risk of connecting a data record with the identity of a person, but does not change the fact that the link to a person can persist ([CJEU, judgment of 4 September 2025, C-413/23 P, EDPS/SRB](https://curia.europa.eu/juris/liste.jsf?num=C-413/23)).

Recital 28 GDPR assigns pseudonymization this function: it can reduce the risks to the data subjects and support the controller as well as the processor in complying with their obligations, but it expressly does not exclude other data protection measures. As an incentive, Recital 29 GDPR permits general analysis within the same controller, provided that the controller has taken the necessary measures and keeps the additional information separately.

## 2. Distinction from anonymization [#2-distinction-from-anonymization]

Pseudonymization and anonymization are frequently confused in practice, but they have opposite legal consequences. The GDPR does not expressly define anonymization. Anonymous information is information which does not relate to an identified or identifiable natural person, or personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable (Recital 26 GDPR). Where anonymous data exist, they are non-personal data to which the GDPR does not apply.

The decisive difference lies in reversibility. With pseudonymization, a possibility of attribution continues to exist; it is merely relocated and protected. With genuine anonymization, the possibility of attribution is eliminated permanently. Encryption can be placed in the same category: as long as a key makes the data readable again, the link to a person is retained.

| Feature                    | Pseudonymization                                    | Anonymization                 | Encryption                       |
| -------------------------- | --------------------------------------------------- | ----------------------------- | -------------------------------- |
| Attribution to a person    | possible via separately held additional information | permanently precluded         | possible via key or password     |
| Legal consequence          | remains personal data                               | non-personal data             | remains personal data            |
| GDPR applicable            | yes                                                 | no                            | yes                              |
| Classification in the GDPR | separately defined (Article 4(5) GDPR)              | not defined (Recital 26 GDPR) | special form of pseudonymization |

## 3. Types of pseudonymization [#3-types-of-pseudonymization]

Whoever controls the assignment rule determines for whom the data are pseudonymous and for whom they are attributable. The assignment rule may be a sequential or a random numbering. According to who holds the rule, three constellations can be distinguished.

### 3.1 Assigned by the data subject [#31-assigned-by-the-data-subject]

The data subject assigns the pseudonym themselves, for example a freely chosen user ID. As long as only the data subject can establish the connection to their identity, the provider processing the data generally lacks any link to a person.

### 3.2 Assigned by a trusted third party [#32-assigned-by-a-trusted-third-party]

A trusted third party assigns the pseudonym and alone controls the assignment rule. Here there is an organizational separation between the holder of the assignment rule and the body working with the data. This separation is the core of the statutory definition.

### 3.3 Assigned by the controller itself [#33-assigned-by-the-controller-itself]

The controller assigns the pseudonym itself and retains the assignment rule. One example is the dynamic IP address: to third parties it functions like a pseudonym, yet the access provider can establish the attribution to the person. The fact that pseudonyms can be reversed comparatively easily in this way shows how closely pseudonymization and the persisting link to a person are connected.

<Callout type="warn">
  Case example: A physician labels blood samples with a sequential number and hands them over to a laboratory. For the laboratory, the samples are pseudonymous because only the physician controls the assignment. However, if the laboratory has to bill the patient directly, the pseudonymization is broken and the link to a person is established for the laboratory. Anyone who knows the additional information must treat the data as personal data.
</Callout>

## 4. Persisting link to a person and legal consequences [#4-persisting-link-to-a-person-and-legal-consequences]

Pseudonymized data remain personal data and may be processed only in accordance with the requirements of the GDPR. Pseudonymization exempts neither from the choice of a legal basis nor from the information, data subject and documentation obligations. Whether the data are personal for a particular body depends on whether that body has a realistic possibility of re-identification: for a recipient without such a possibility, the data may be factually anonymous, whereas for the body with access to the assignment they remain personal data ([CJEU, judgment of 4 September 2025, C-413/23 P, EDPS/SRB](https://curia.europa.eu/juris/liste.jsf?num=C-413/23)).

At the same time, pseudonymization is one of the central protective measures of the GDPR. It forms part of data protection by design and by default, which names it expressly as an example (Article 25(1) GDPR). In the context of security of processing, Article 32(1)(a) GDPR lists pseudonymization alongside encryption as an appropriate measure to ensure an appropriate level of security.

## 5. Special forms [#5-special-forms]

### 5.1 Encrypted data [#51-encrypted-data]

Encrypted data are likewise pseudonymized data. With the appropriate key or password, they become readable again, so that the link to a person is retained. Data stored in encrypted form in the cloud are therefore also personal data. For encryption to fulfill its protective purpose, it must correspond to the state of the art. The GDPR names encryption alongside pseudonymization expressly as a measure to ensure an appropriate level of security (Article 32(1)(a) GDPR).

### 5.2 De-identification of passenger data [#52-de-identification-of-passenger-data]

A special form of pseudonymization is de-identification in the law on passenger data. § 5 of the German Passenger Name Record Act (FlugDaG) implements Article 12 of Directive (EU) 2016/681 and requires that certain data elements by which the passenger's identity could be established be masked out after six months (Article 12(2) of Directive (EU) 2016/681). Making the data accessible again is permitted only under certain conditions. Because this process remains reversible, it is in substance a pseudonymization and not an anonymization.

## 6. Placement within the data protection principles [#6-placement-within-the-data-protection-principles]

Pseudonymization interlocks with several principles of processing. It is a practical instrument of [data minimization](/docs/dsgvo-hub/einzelthemen/grundsaetze-der-verarbeitung/1.3.3.5-datenminimierung), because it reduces the immediate link to a person in the processed data records. At the same time, it serves [integrity and confidentiality](/docs/dsgvo-hub/einzelthemen/grundsaetze-der-verarbeitung/1.3.3.8-integritaet-und-vertraulichkeit) by reducing the risk of unauthorized attribution. However, it does not replace any of these obligations, but flanks them as one of several protective measures.

<Cards>
  <Card title="Personal data" href="/docs/dsgvo-hub/begriffe-und-definitionen/1.2.1-personenbezogene-daten" description="Article 4(1) GDPR: identifiability and distinction from anonymization." />

  <Card title="Data minimization" href="/docs/dsgvo-hub/einzelthemen/grundsaetze-der-verarbeitung/1.3.3.5-datenminimierung" description="Article 5(1)(c) GDPR: pseudonymization as a means of reduction." />

  <Card title="Integrity and confidentiality" href="/docs/dsgvo-hub/einzelthemen/grundsaetze-der-verarbeitung/1.3.3.8-integritaet-und-vertraulichkeit" description="Article 5(1)(f) GDPR: protection through technical and organizational measures." />

  <Card title="Article 4 GDPR" href="https://dsgvo-gesetz.de/art-4-dsgvo/" description="Definitions, point (5): pseudonymization." />

  <Card title="Article 32 GDPR" href="https://dsgvo-gesetz.de/art-32-dsgvo/" description="Security of processing, paragraph 1(a)." />
</Cards>


---

## About the author

This article was written by [Dr. Thomas Helbing, specialist lawyer for IT law in Munich](https://www.thomashelbing.com/en).

Since 2020 and continuously through today (2026), Handelsblatt has [recognized](https://www.thomashelbing.com/en#auszeichnungen) Dr. Helbing as one of **"Germany's Best Lawyers"** in IT law and data protection law.

According to Kanzleimonitor.de (2024 to 2026 editions), he ranks among the **leading lawyers for data protection and IT law** and is listed among the **top 100 lawyers in Germany (2024/25)**. Kanzleimonitor is considered a particularly meaningful market study because it is based exclusively on personal recommendations from in-house counsel.

Dr. Helbing has **many years of advisory experience in data protection and IT law** and advises clients of all sizes, from startups through fast-growing SaaS companies and unicorns to international corporate groups.

His [professional background](https://www.thomashelbing.com/en#stationen) covers the **full spectrum of IT and technology law practice**. He began his career at a major international law firm, then gained **in-house experience at a DAX-listed company**, and is himself an **entrepreneur and founder of several digital ventures**. He also has **hands-on programming experience**, which allows him to understand technical systems, software architectures and digital business models not only from a legal perspective but also from a technical one.

For many years, his [clients](https://www.thomashelbing.com/en#referenzen) have included **technology companies and SaaS providers**, leading **German research institutions** and a **systemically important German bank**. His advisory focus lies in particular on **GDPR compliance, the data economy, SaaS, AI regulation and IT contract law**.