Pseudonymisierung schützt personenbezogene Daten, indem die unmittelbare Zuordnung zu einer Person von der fachlichen Verarbeitung getrennt wird. Entscheidend ist nicht das Ersetzen eines Namens durch eine Nummer. Entscheidend ist, wer mit welchen zusätzlichen Informationen die Verbindung wiederherstellen kann und ob diese Möglichkeit wirksam begrenzt wird.
Ein brauchbares Verfahren enthält deshalb einen Datenfluss, eine Rollenverteilung und einen geregelten Rückführungsprozess. Das folgende Beispiel zeigt diese Entscheidungen für eine fiktive Kundenbefragung mit wiederholten Erhebungen. Die Analysten sollen Entwicklungen erkennen können; der Kundenservice soll weiterhin berechtigte Auskunfts- oder Berichtigungsanfragen bearbeiten können. Dafür braucht nicht jede beteiligte Person Zugriff auf die Identität.
Was die rechtliche Definition praktisch verlangt
Artikel 4 Nummer 5 der DSGVO beschreibt eine Verarbeitung, bei der personenbezogene Daten ohne zusätzliche Informationen nicht mehr einer bestimmten betroffenen Person zugeordnet werden können. Die zusätzlichen Informationen werden gesondert aufbewahrt und durch technische sowie organisatorische Maßnahmen geschützt. Artikel 25 und 32 nennen Pseudonymisierung als mögliche Schutzmaßnahme im jeweiligen risikobezogenen Zusammenhang.
Für den Verantwortlichen, der die Zuordnung vorhält und nutzen kann, bleiben die Daten personenbezogen. Eine Rechtsgrundlage, transparente Informationen und angemessene Speicherfristen sind weiterhin erforderlich. Pseudonymisierung erlaubt nicht von sich aus eine neue Analyse oder die Weitergabe eines ansonsten unzulässigen Datenbestands.
Die Perspektive eines gesonderten Empfängers muss differenziert betrachtet werden. Der EuGH hat im Urteil C-413/23 P vom 4. September 2025 zur Verordnung 2018/1725 klargestellt, dass pseudonymisierte Daten nicht in jeder Lage für jede Person personenbezogen sein müssen. Maßgeblich sind die vernünftigerweise nutzbaren Identifizierungsmittel im konkreten Kontext. Daraus folgt jedoch keine pauschale Freistellung des übermittelnden Verantwortlichen; insbesondere ist seine Informationspflicht bei der Erhebung aus seiner damaligen Perspektive zu beurteilen. Eine Vertragsklausel „Empfänger bekommt keinen Schlüssel“ ersetzt die tatsächliche Prüfung nicht.
Im Beispiel zuerst den notwendigen Zusammenhang bestimmen
Ein Dienstleistungsunternehmen will drei Befragungsrunden vergleichen. Die fachliche Frage lautet: Verbessern sich Bewertungen nach einer geänderten Terminplanung bei denselben teilnehmenden Kunden? Ohne irgendeinen stabilen Zusammenhang wären nur getrennte Querschnitte möglich. Mit einer vollständigen Kundenakte wäre die Analyse dagegen unnötig personenbezogen.
Die Projektentscheidung erlaubt deshalb ein zufällig vergebenes Projektpseudonym, das ausschließlich innerhalb dieser Befragung stabil bleibt. Es wird nicht als allgemeine Kundenkennung in Vertrieb, Abrechnung oder Personalbewertung übernommen. Die Analysten erhalten außerdem nur die für die Frage benötigten Bewertungen und grobe Gebietsangaben. Die Gestaltung der Fragen selbst wird nach dem Leitfaden für Umfragen und Fragebögen begrenzt.
Eine zweite Forschungsfrage, die einzelne Beschwerden nachverfolgen soll, wäre damit noch nicht freigegeben. Sie würde andere Rückführungen und möglicherweise zusätzliche Daten erfordern. Das Team müsste Zweck, Rechtsgrundlage, Information und Zugriffe erneut prüfen. Ein einmal erzeugtes Pseudonym schafft keine unbegrenzte Erlaubnis, alle später verfügbaren Informationen daran anzuhängen.
Die zwei Datenbestände tatsächlich trennen
Im Beispiel existieren eine Zuordnungstabelle und ein Auswertungsbestand. Die Trennung wird sowohl in den Berechtigungen als auch im Betrieb umgesetzt. Zwei Dateien im selben allgemein zugänglichen Projektordner erfüllen den geplanten Schutz nicht.
| Bestandteil | Enthält im Beispiel | Zuständige Rolle | Ausgeschlossener Regelzugriff |
|---|---|---|---|
| Zuordnungstabelle | Projektpseudonym und interne Kundenkennung | Kleine, benannte Vertrauensstelle | Analysten und reguläres Berichtsteam |
| Auswertungsbestand | Projektpseudonym, Befragungsrunde, Bewertungen, grobes Gebiet | Freigegebene Analysten | Vertrieb und unbeteiligte Fachbereiche |
| Rückführungsprotokoll | Anlass, Freigabe, Zeitpunkt und ausführende Rolle | Kontrollfunktion mit begrenztem Zugriff | Allgemeine Projektmitglieder |
| Managementbericht | Zusammengefasste Ergebnisse ohne Projektkennungen | Projektleitung | Kein Zugriff auf Rohantworten aus dieser Rolle |
Die Vertrauensstelle muss keine besondere gesetzlich vorgeschriebene Institution sein. Im Beispiel bezeichnet der Begriff eine klar abgegrenzte interne Funktion. Sie erhält einen eigenen Berechtigungskreis und führt Rückführungen nur nach dem dokumentierten Verfahren aus. Die Analyseleitung kann diese Beschränkung nicht durch einen gewöhnlichen Projektauftrag umgehen.
Auch Administratoren und Dienstleister werden betrachtet. Hat dieselbe privilegierte Rolle uneingeschränkt Zugriff auf beide Datenbanken, bleibt ein gemeinsamer Kompromittierungsweg bestehen. Das kann zusätzliche Begrenzungen, getrennte Konten oder eine besonders kontrollierte Notfalladministration erfordern. Die tatsächliche Infrastruktur bestimmt, welche Trennung belastbar ist.
Ein Verfahren passend zum Angreifermodell auswählen
Zufällige Tokens, kryptografische Verfahren und Hashfunktionen haben unterschiedliche Eigenschaften. Die ENISA-Untersuchung zu Pseudonymisierungstechniken beschreibt unter anderem Wörterbuchangriffe, systematisches Ausprobieren und Angriffe mit Vorwissen. Ein ungesalzener Hash einer E-Mail-Adresse kann durch das Berechnen bekannter Kandidaten wieder zugeordnet werden. „Nicht umkehrbar“ bedeutet bei einer Hashfunktion deshalb nicht, dass eine Identifizierung praktisch ausgeschlossen ist.
Im Befragungsbeispiel entscheidet sich das Team für zufällige Projektkennungen mit einer gesonderten Zuordnungstabelle. Für eine andere Anwendung könnte ein Verfahren mit geheimem Schlüssel sinnvoll sein. Dann muss die Geheimhaltung dieses Schlüssels ebenso geplant werden wie seine Verfügbarkeit für berechtigte Vorgänge. Die Auswahl erfolgt anhand benötigter Verknüpfbarkeit, verfügbarer Zusatzinformationen und möglicher Angreifer.
Das Team schreibt seine Annahme ausdrücklich auf: „Eine Person mit Zugriff auf den Auswertungsbestand soll nicht allein mit allgemein verfügbaren Kundeninformationen die Befragten zuordnen können.“ Anschließend prüft es, ob seltene Kombinationen diese Annahme widerlegen. Ein sehr kleines Gebiet, ein genauer Termin und eine ungewöhnliche Beschwerde können die Person trotz sicherem Token erkennbar machen.
Die Konsequenz ist im Beispiel eine gröbere zeitliche Darstellung und das Zusammenfassen kleiner Auswertungsgruppen. Ein fester Mindestwert für Gruppengrößen wird nicht als allgemeine gesetzliche Garantie ausgegeben. Er ist eine interne Entscheidung, deren Eignung vom übrigen Datenbestand und vom Wissen der Empfänger abhängt.
Rückführungen mit einem ausgefüllten Vorgang steuern
Eine Kundin beantragt die Berichtigung ihrer versehentlich falsch zugeordneten Befragungsantwort. Der Kundenservice prüft die Anfrage im bestehenden Kontaktprozess und eröffnet den Vorgang P-17. Er sendet der Vertrauensstelle nur die notwendige Kundenkennung und den konkreten Auftrag. Das gesamte Support-Ticket mit weiteren Kundendetails wird nicht an die Analysten weitergeleitet.
Die Vertrauensstelle ermittelt das betroffene Projektpseudonym. Die zuständige Fachrolle bestätigt, welcher Antwortdatensatz geprüft und gegebenenfalls korrigiert werden muss. Das Analyseteam erhält den Auftrag für dieses Pseudonym und die erforderliche Änderung, aber keine vollständige Namensliste. Anschließend bestätigt es die Umsetzung. Im Rückführungsprotokoll bleiben Zweck, Freigabe und Ergebnis des Vorgangs dokumentiert.
Für ungewöhnliche Rückführungen sieht das Beispiel eine zusätzliche Freigabe vor. Dazu zählt etwa der Wunsch, alle kritischen Bewertungen namentlich aufzulisten. Ein solcher Wunsch wird nicht als normale Fehlerkorrektur behandelt. Er würde den Schutzgedanken des Projekts verändern und benötigt eine eigene rechtliche und organisatorische Bewertung.
Der Auskunftsprozess muss diese Rollen rechtzeitig einbeziehen. Die technische Trennung darf nicht dazu führen, dass zuständige Mitarbeiter eine berechtigte Anfrage einfach mit „Wir haben nur Nummern“ ablehnen. Umgekehrt werden nach Artikel 11 nicht zusätzliche Identifikationsdaten allein dafür gesammelt, Betroffene künftig identifizieren zu können, wenn die Voraussetzungen dieser Vorschrift vorliegen.
Schlüssel, Backups und Exporte gemeinsam absichern
Eine sicher getrennte produktive Zuordnung kann ihren Nutzen verlieren, wenn ein nächtlicher Export beide Tabellen in ein ungeschütztes Archiv schreibt. Deshalb umfasst die Prüfung Sicherungskopien, Wiederherstellungsumgebungen, Testdaten und Supportpakete. Produktive Identitäten gehören nicht ungeprüft in Entwicklungs- oder Demonstrationssysteme.
Die Verschlüsselung personenbezogener Daten ergänzt die Pseudonymisierung. Sie schützt beispielsweise die gespeicherte Zuordnung und deren Übertragung. Sie ersetzt aber nicht die Rollenprüfung: Ein angemeldeter Benutzer mit zulässigem Entschlüsselungszugriff kann weiterhin zu viele Daten sehen, wenn seine fachlichen Rechte zu weit reichen.
Im Backup- und Wiederherstellungsplan wird festgehalten, wie getrennte Bestände wiederhergestellt werden, ohne die Zugriffsschranken aufzuheben. Die Wiederherstellung wird mit erfundenen Datensätzen nachvollzogen. Dabei muss auch geprüft werden, ob gelöschte Zuordnungen aus alten Sicherungen unbemerkt erneut produktiv werden könnten.
Löschung und Freigabe anhand konkreter Nachweise abschließen
Projektpseudonym, Rohantworten und Zuordnungstabelle können unterschiedliche Lebenszyklen haben. Im Beispiel wird vorab entschieden, wann die benötigte Längsschnittauswertung endet und ob danach noch ein berechtigter Zuordnungszweck besteht. Die Entscheidung wird mit den geplanten Betroffenenrechten und notwendigen Nachweisen abgestimmt. Eine ewige Aufbewahrung „für mögliche Rückfragen“ ist keine präzise Fristbegründung.
Die Entfernung der Zuordnungstabelle führt nicht automatisch zu anonymen Daten. Verbleibende Merkmale und anderweitig vorhandene Verknüpfungsmöglichkeiten müssen erneut bewertet werden. Soll ein Bericht veröffentlicht werden, wird gerade die Sicht eines größeren, unbekannten Empfängerkreises geprüft. Für den geregelten Abschluss verbindet das Team seine Entscheidung mit dem Löschkonzept.
Bei einer behördlichen Herausgabe reicht ein ersetzter Name ebenfalls nicht, wenn der übrige Text die Person erkennen lässt. Die Prüfung und Schwärzung personenbezogener Angaben bei einer IFG-Anfrage zeigt, wie die Herausgabefassung und ihre verbleibenden Zuordnungsmöglichkeiten kontrolliert werden.
Die endgültige Freigabe des Beispiels enthält die zugelassenen Felder, die Rollenmatrix, das verwendete Verfahren, die geprüften Zuordnungsangriffe und den Ablauf P-17. Als noch nicht zulässig werden allgemeine Kundenprofilierung, Vertriebsexporte und namentliche Bewertungen festgehalten. Die nächste Überprüfung wird bei neuen Datenfeldern, zusätzlichen Empfängern oder Änderungen der technischen Zugriffswege ausgelöst. So bleibt Pseudonymisierung ein überprüfbarer Schutz im Betrieb und nicht lediglich eine Beschriftung auf einer Tabelle.