Wie Datenlecks entstehen
Wer wirksame Schutzmaßnahmen entwerfen will, muss die Angriffswege verstehen. Diese fünf häufigen Wege können personenbezogene Daten offenlegen:
- Diebstahl von Zugangsdaten und Phishing: Angreifer beschaffen sich gültige Zugangsdaten – durch Phishing, systematisches Ausprobieren von Passwörtern oder Anmeldeversuche mit Daten aus früheren Lecks. Sie melden sich als berechtigte Nutzer an und exportieren Daten mit deren Zugriffsrechten. Dabei wird keine technische Schutzmaßnahme umgangen. Der Angreifer erscheint als berechtigter Nutzer.
- Ungepatchte Schwachstellen: Angreifer nutzen bekannte oder bislang unbekannte Schwachstellen in Webanwendungen, APIs oder Infrastruktursoftware aus, um unbefugt auf Datenspeicher zuzugreifen. Häufige Angriffswege sind SQL-Injection, das Durchqueren von Verzeichnissen und das Umgehen der API-Authentifizierung.
- Fehlkonfiguration und versehentliche Offenlegung: Versehentlich über das Internet erreichbare Speicherbereiche, Datenbanken und APIs legen große Mengen personenbezogener Daten offen – oft ohne jede Anmeldung. Fehlkonfigurationen in Cloud-Umgebungen sind besonders häufig.
- Angriff über die Lieferkette: Angreifer kompromittieren einen Softwareanbieter, einen Betreiber verwalteter IT-Dienste oder ein quelloffenes Softwarepaket. Über dessen Vertrauensstellung greifen sie auf Kundendaten zu. Das betroffene Unternehmen hat keinen Hinweis darauf, dass der Angriff stattgefunden hat.
- Innentäter: Beschäftigte, Auftragnehmer oder ehemalige Beschäftigte mit berechtigtem Zugang schleusen Daten absichtlich aus – aus finanziellem Interesse, für einen Wettbewerbsvorteil oder aus anderen schädlichen Motiven. Das ist schwer zu erkennen, weil der Zugriff berechtigt aussieht.
Allen fünf Angriffswegen ist gemeinsam: Der Angreifer erreicht lesbare Daten im Klartext. Anonymisierung bei der Erfassung ändert das. Eine kompromittierte Datenbank liefert dann wesentlich weniger nutzbare personenbezogene Informationen. Pseudonymisierte Daten bleiben allerdings personenbezogen und sind nicht automatisch wertlos.
5 beispielhafte Datenlecks: Wie Anonymisierung die Folgen verändert hätte
Angriffsmuster 1: Patientenakten in einem elektronischen Krankenaktensystem offengelegt
Was geschah (Beispielszenario): Ein elektronisches Krankenaktensystem in einem regionalen medizinischen Zentrum wurde mit Zugangsdaten aus einem anderen Datenleck angegriffen. Der Angreifer nutzte diese Daten, um sich am Portal für elektronische Krankenakten anzumelden. Für die Verwaltungs-API fehlte eine Mehrfaktor-Authentifizierung. Der Angreifer exportierte ungefähr 500.000 Patientenakten mit Namen, Geburtsdaten, US-Sozialversicherungsnummern, Diagnosen, Versicherungskennungen und Wohnanschriften. Das Datenleck wurde erst 19 Tage später erkannt.
Rechtliche Folgen: Das Datenleck löste HIPAA-Mitteilungspflichten gegenüber allen 500.000 Betroffenen aus. Hinzu kamen eine Untersuchung durch das Office for Civil Rights (OCR) des US-Gesundheitsministeriums HHS und mögliche Sanktionen nach 45 CFR Part 160/164. Für Einrichtungen im EU-Gesundheitswesen würden entsprechende Mitteilungspflichten nach der Datenschutz-Grundverordnung (DSGVO) gelten.
Wie Anonymisierung die Folgen verändert: Hätte das Krankenaktensystem Patientenakten pseudonymisiert gespeichert und die Zuordnungstabelle in einem getrennten, besonders geschützten Tresor abgelegt, der über die Portal-API nicht erreichbar ist, hätte der Angreifer 500.000 Datensätze mit medizinischen Codes, anonymisierten Platzhaltern und klinischen Notizen exportiert. Ohne Zuordnungsschlüssel wären diese Daten für ihn weit weniger nützlich. Pseudonymisierte Akten gelten unter HIPAA weiterhin als geschützte Gesundheitsinformationen. Auch klinische Notizen können noch Identifikationsmerkmale enthalten. Eine Mitteilung entfällt deshalb nur nach den eng gefassten Ausnahmen des HHS oder nach einer dokumentierten Risikobewertung. Das rechtliche Risiko sinkt, verschwindet aber nicht.
Wichtige Erkenntnis: Nach dem Safe-Harbor-Standard zur De-Identifizierung gemäß HIPAA (45 CFR § 164.514(b)) sind de-identifizierte Gesundheitsinformationen keine geschützten Gesundheitsinformationen (PHI). Ein Datenleck mit de-identifizierten Daten erfordert keine Mitteilung.
Angriffsmuster 2: Lernplattform für die Klassen K–12 – Schülerdaten und FERPA-Verstöße
Was geschah (Beispielszenario): Angreifer drangen über einen ungepatchten API-Endpunkt in eine Cloud-Plattform für Schülerverwaltung und Lernmanagement ein. Sie griffen auf Datensätze von 2,5 Millionen Schülerinnen und Schülern aus 1.200 Schulbezirken zu. Darin standen Namen, Geburtsdaten, Wohnanschriften, Kontaktdaten der Eltern, Angaben zum Schulbesuch und Informationen über Behinderungen. Innerhalb von 48 Stunden nach dem Abfluss wurden die Daten in einem Darknet-Forum veröffentlicht.
Rechtliche Folgen: Verstöße gegen den Family Educational Rights and Privacy Act (FERPA), gegen Datenschutzgesetze einzelner US-Bundesstaaten für Schülerdaten – viele Bundesstaaten haben eigene Regeln für die Klassen K–12 – und Sammelklagen betroffener Familien. Mehrere Schulbezirke kündigten ihre Verträge mit der Plattform.
Wie Anonymisierung die Folgen verändert: Schülerakten enthalten sowohl Daten, die für den Betrieb nötig sind – etwa Einschreibestatus, Klassenstufe und Kurszuordnung –, als auch sensible personenbezogene Daten wie Wohnanschrift, Angaben zu Behinderungen und Elternkontakte. Letztere werden für die wichtigsten Unterrichtsfunktionen selten benötigt. Eine mit FERPA vereinbare Datenminimierung bei der Erfassung hätte sensible personenbezogene Daten verschlüsselt oder pseudonymisiert gespeichert und sie nur für Verwaltungszwecke zugänglich gemacht. Über die kompromittierte API wären dann nur anonymisierte Betriebsdaten abgeflossen.
FERPA und Anonymisierung: FERPA erlaubt die Offenlegung von „de-identified student records“ (de-identifizierten Schülerunterlagen) ohne Einwilligung der Eltern. Ordnungsgemäß de-identifizierte Daten lassen FERPA-Mitteilungspflichten entfallen und verringern das Risiko von Klagen erheblich.
Angriffsmuster 3: Finanzplattform – Transaktionsdaten mit personenbezogenen Angaben abgeflossen
Was geschah (Beispielszenario): Eine digitale Kreditplattform wurde durch eine SQL-Injection gegen ihre Kundendatenbank angegriffen. Der Angreifer entwendete Datensätze von 180.000 Kunden. Sie enthielten vollständige Namen, E-Mail-Adressen, Wohnanschriften, Einkommensangaben, Bankkontonummern und Bonitätswerte für die Kreditprüfung. Der Angriff blieb 34 Tage unentdeckt.
Rechtliche Folgen: Ein erweiterter Anwendungsbereich des PCI-DSS, Maßnahmen nach dem California Consumer Privacy Act (CCPA) für Betroffene in Kalifornien und Mitteilungspflichten nach dem Gramm-Leach-Bliley Act (GLBA). Finanzielle Sanktionen und Rufschäden beeinflussten die Kosten der Kundengewinnung länger als 18 Monate.
Wie Anonymisierung die Folgen verändert: Finanzplattformen verarbeiten personenbezogene Daten für zwei unterschiedliche Zwecke. Für die Kreditentscheidung brauchen sie die tatsächlichen Werte zum Zeitpunkt der Entscheidung. Für Prüf- und Compliance-Berichte brauchen sie einen dokumentierten Nachweis der Entscheidung, aber nicht unbedingt die zugrunde liegenden personenbezogenen Daten. Wären diese Daten nach der Kreditentscheidung anonymisiert und die tatsächlichen Werte durch Prüfplatzhalter ersetzt worden, hätte die Datenbank nur anonyme Datensätze und Prüfverweise enthalten. Der 34 Tage lang unbemerkte Abfluss hätte Daten mit deutlich geringerem Wert geliefert.
Angriffsmuster 4: Lieferkettensoftware – bösartiges Update legt Kundendaten offen
Was geschah (Beispielszenario): Ein Betreiber verwalteter IT-Dienste wurde über ein bösartiges Softwareupdate seines Werkzeugs zur Fernüberwachung und Fernverwaltung (RMM) kompromittiert. Der Angreifer erhielt Zugang zur Infrastruktur des Dienstleisters und darüber zu Kundennetzwerken. Aus den Kundensystemen flossen Beschäftigtendaten, Kundendatenbanken und Konfigurationsdateien mit Zugangsdaten und personenbezogenen Informationen ab. Betroffen waren Dutzende Kundenunternehmen.
Rechtliche Folgen: Der IT-Dienstleister musste mit Ansprüchen aus den Auftragsverarbeitungsverträgen seiner Kunden rechnen. Für die Kunden entstanden Mitteilungspflichten nach der DSGVO – einschließlich der Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden –, nach HIPAA bei Kunden aus dem Gesundheitswesen und nach anwendbaren Datenschutzgesetzen einzelner US-Bundesstaaten.
Wie Anonymisierung die Folgen verändert: Unternehmen, die nur die nötigen personenbezogenen Daten speicherten, Daten bei der Erfassung anonymisierten und Zuordnungstabellen von Betriebsdatenbanken trennten, boten dem Angreifer deutlich weniger sensible Daten. Bei Kunden mit ordnungsgemäß umgesetzter Anonymisierung enthielten die abgeflossenen Datensätze pseudonymisierte Platzhalter. Die Zuordnungstabellen lagen auf getrennten Systemen, die über das RMM-Werkzeug nicht erreichbar waren, und blieben geschützt. Für diese Kunden waren die Mitteilungspflichten geringer und das rechtliche Risiko minimal.
Angriffsmuster 5: Innentäter – Beschäftigter kopiert Kundendatenbank
Was geschah (Beispielszenario): Ein Vertriebsmitarbeiter eines B2B-Softwareunternehmens kopierte vor seinem letzten Arbeitstag die Datenbank der Kundenverwaltung (CRM) in einen privaten Cloud-Speicher. Die Datenbank enthielt 95.000 Kundenkontakte mit Namen, E-Mail-Adressen, Telefonnummern, Unternehmensangaben, Umsätzen und Geschäftshistorien. Anschließend nutzte der Mitarbeiter die Daten, um für einen Wettbewerber Kunden zu werben.
Rechtliche Folgen: Klagen wegen der unbefugten Nutzung von Geschäftsgeheimnissen, Ansprüche wegen Verletzung von Treuepflichten und Maßnahmen nach der DSGVO wegen der EU-Kundenkontakte in der Datenbank. Das Datenleck unterlag den Mitteilungspflichten nach Artikel 33 und 34.
Wie Anonymisierung die Folgen verändert: Angriffe durch Innentäter sind besonders schwer zu verhindern, weil die Täter berechtigten Zugang haben. Die Abwehr besteht darin, sicherzustellen, dass auch ein berechtigter Zugriff sensible personenbezogene Daten nicht unnötig offenlegt. Speichert ein CRM vollständige Kontaktdaten pseudonymisiert, während Namen und Kontaktinformationen nur für berechtigte Nutzer am Bildschirm sichtbar sind, kann ein ausscheidender Mitarbeiter weniger verwertbare Daten kopieren. Er könnte CRM-Datensätze mitnehmen, erhielte aber eine Datenbank mit anonymisierten Platzhaltern statt verwertbarer Kontaktdaten.
Anonymisierung als Schutz: Warum anonymisierte Daten für Angreifer weit weniger wert sind
Die wirtschaftliche Logik eines Datenlecks ist einfach. Angreifer – kriminelle Gruppen, die gestohlene Daten verkaufen, Staaten, die Informationen sammeln, oder Wettbewerber auf der Suche nach Vorteilen – profitieren nur, wenn die erbeuteten Daten einen Wert haben. Personenbezogene Daten sind wertvoll, weil sie:
- Zuordenbar sind: Sie lassen sich einer bestimmten Person zuordnen.
- Nutzbar sind: Sie können verwendet werden, um diese Person zu kontaktieren, zu betrügen oder auszunutzen.
- Verkäuflich sind: Sie können an andere verkauft werden, die sie ausnutzen.
Ordnungsgemäß anonymisierte Daten verlieren diese Eigenschaften weitgehend. Eine Datenbank mit pseudonymisierten Platzhaltern ([PERSON_1], [EMAIL_1], [PHONE_1]) lässt sich viel schwerer einzelnen Personen zuordnen, für Kontaktaufnahmen verwenden oder verkaufen, wenn die Zuordnungstabelle getrennt gespeichert ist. Automatisch wertlos ist sie nicht: Andere Datenfelder und Freitext können Personen weiterhin erkennbar machen. Pseudonymisierte Daten bleiben nach der DSGVO personenbezogen.
Für den Schutz bei einem Datenleck unterscheiden sich Verschlüsselung und Anonymisierung in einem entscheidenden Punkt:
- Verschlüsselte Daten: Erlangt der Angreifer den Schlüssel, kann er die Daten entschlüsseln. Der Schlüssel liegt häufig neben den Daten oder ist über dasselbe kompromittierte System erreichbar. Verschlüsselung verschafft Zeit, beseitigt das Risiko eines Datenlecks aber nicht.
- Anonymisierte Daten: Liegt die Zuordnungstabelle getrennt und erbeutet der Angreifer nur die pseudonymisierte Datenbank, braucht er für die erneute Zuordnung einen zweiten, unabhängigen Angriff auf den Tresor mit der Zuordnungstabelle. Diese zusätzliche Schutzebene erhöht Aufwand und Kosten des Angriffs erheblich.
Vier Schutzebenen, die zusammenwirken
1. Mit piisafe.eu prüfen
Bevor Sie Daten schützen können, müssen Sie wissen, welche Sie besitzen. Prüfen Sie Ihre öffentliche Website mit piisafe.eu auf unbeabsichtigt offengelegte personenbezogene Daten. So erkennen Sie Lücken bei der Datenminimierung.
Wann: Vierteljährlich und nach jeder Änderung der Infrastruktur. Die Oberfläche von piisafe.eu ist kostenlos. Für die Erkennung personenbezogener Daten benötigen Sie einen anonym.legal-API-Schlüssel ab 3 € pro Monat.
2. Daten bei der Erfassung über die API anonymisieren
Am wirksamsten ist die Anonymisierung bei der Erfassung, bevor Daten in eine Datenbank oder ein Protokoll geschrieben werden. Binden Sie die REST-API von anonym.legal in Ihren Datenfluss ein. So gelangen Daten bereits pseudonymisiert in Ihre Systeme.
Wann: An jeder Stelle, an der personenbezogene Daten in Ihre Systeme gelangen: beim Absenden von Formularen, beim Empfang über eine API, beim Hochladen von Dateien und bei Webhook-Ereignissen.
3. Arbeitsabläufe mit KI schützen
KI-Assistenten wie Claude Desktop, Cursor und Copilot werden zunehmend eingesetzt, um Kundendaten zu verarbeiten, Fehler im laufenden Betrieb zu untersuchen und Geschäftsunterlagen auszuwerten. Jede Eingabe an ein großes Sprachmodell kann personenbezogene Daten offenlegen. Nutzen Sie den MCP-Server, um Eingaben zu anonymisieren, bevor sie die KI erreichen.
Wann: Sobald Sie einen KI-Assistenten für Aufgaben einsetzen, die Kunden- oder Beschäftigtendaten enthalten können.
4. Sensible Daten auf einem vom Netz getrennten Rechner verarbeiten
Für besonders sensible Daten – klinische Akten, Finanzinstrumente und Verschlusssachen – sollte die Verarbeitung niemals eine Internetverbindung erfordern. anonym.plus läuft vollständig auf dem Rechner, auf dem es installiert ist, und verarbeitet personenbezogene Daten ohne Internetverbindung mit lokalen Sprachmodellen. Die Daten verlassen das Gerät nie.
Wann: Wenn Sie Daten verarbeiten, die niemals nach außen übertragen werden dürfen: Patientenakten, vertrauliche anwaltliche Kommunikation und Unterlagen für die sorgfältige Prüfung im Finanzbereich.
Die Frage nach 4,88 Mio. €: Kosten der Anonymisierung und eines Datenlecks
Laut IBM Cost of a Data Breach Report 2024 betragen die durchschnittlichen Gesamtkosten eines Datenlecks 4,88 Mio. US-Dollar (ungefähr 4,5 Mio. €). Dazu zählen Erkennung und Eskalation, Benachrichtigungen, Maßnahmen nach dem Vorfall und entgangenes Geschäft. Aufsichtsrechtliche Geldbußen sind nicht enthalten. Nach der DSGVO können sie beträchtlich sein: bis zu 20 Mio. € oder 4 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
Die folgende beispielhafte Schätzung beruht auf unseren eigenen Annahmen, nicht auf einer Studie. Sie zeigt mögliche Kosten für ein mittelgroßes europäisches Unternehmen nach einem erheblichen Datenleck:
| Kostenart | Beispielhafte Spanne |
|---|---|
| Reaktion auf das Datenleck (forensische Untersuchung, Rechtsberatung, Öffentlichkeitsarbeit, Benachrichtigungen) | 500.000 €–2 Mio. € |
| Aufsichtsrechtliche Untersuchung und mögliche Geldbuße | 100.000 €–über 20 Mio. € |
| Betriebsunterbrechung und verlorene Kunden | 500.000 €–5 Mio. € |
| Sammelklagen und Vergleiche | 200.000 €–über 10 Mio. € |
| Rufschaden (langfristige Folgen für den Umsatz) | 1 Mio. €–über 20 Mio. € |
| Gesamtes mögliches Kostenrisiko | 2,3 Mio. €–über 57 Mio. € |
Die Einführung einer umfassenden Anonymisierung personenbezogener Daten – einschließlich Prüfung, API-Anbindung, Schulung der Beschäftigten und Dokumentation – kostet pro Jahr Zehntausende Euro, nicht Millionen.
Häufig gestellte Fragen
Entfallen durch Anonymisierung die Mitteilungspflichten nach der DSGVO?
Ordnungsgemäß anonymisierte Daten, bei denen eine erneute Zuordnung zu Personen nach allgemeinem Ermessen nicht möglich ist, sind nach der DSGVO keine personenbezogenen Daten. Ein Datenleck mit tatsächlich anonymisierten Daten löst keine Mitteilungspflicht nach Artikel 33 oder 34 aus. Pseudonymisierte Daten, für die ein Zuordnungsschlüssel existiert, bleiben dagegen personenbezogen. Nach Artikel 34 Absatz 3 Buchstabe a entfällt die Benachrichtigung betroffener Personen, wenn Maßnahmen wie Verschlüsselung oder Pseudonymisierung die Daten für Unbefugte unzugänglich gemacht haben.
Lässt sich Anonymisierung mit den Anforderungen des laufenden Betriebs vereinbaren?
Ja. Genau darin liegt der Nutzen der Pseudonymisierung. Beschäftigte im Kundenservice, Abrechnungssysteme und berechtigte Arbeitsabläufe können Daten bei Bedarf mit dem Zuordnungsschlüssel wiederherstellen. Die Datenbank selbst speichert nur Platzhalter. Der Schlüssel wird getrennt und mit strengen Zugriffsbeschränkungen aufbewahrt. Ein Datenleck in der Datenbank allein reicht damit nicht aus, um Personen erneut zu identifizieren.
Reichen verschlüsselte Datenbanken nicht aus?
Die Verschlüsselung gespeicherter Daten schützt vor dem physischen Diebstahl von Speichermedien, aber nicht vor den meisten Szenarien eines Datenlecks. Kompromittiert ein Angreifer Zugangs- oder Datenbankdaten oder nutzt er eine SQL-Injection-Schwachstelle aus, greift er über die Anwendungsschicht auf die Daten zu. Dort werden die Daten entschlüsselt verarbeitet. Eine Pseudonymisierung mit getrennt gespeichertem Zuordnungsschlüssel verringert in solchen Fällen den Schaden: Wer den Datenspeicher erreicht, erhält nicht automatisch auch den Schlüssel.
Wie wirkt sich Anonymisierung auf Datenanalysen und Geschäftsauswertungen aus?
Eine einheitliche Pseudonymisierung erhält einen großen Teil des analytischen Werts und senkt zugleich das Risiko der erneuten Identifizierung. Zusammengefasste Kennzahlen und Trendanalysen funktionieren häufig mit pseudonymisierten Daten. Verknüpfungen, Freitextanalysen und Kohortenstudien können jedoch beeinträchtigt sein. Prüfen Sie deshalb jeden Anwendungsfall. Der einzige Unterschied: Für Auswertungen auf Ebene einzelner Personen müssen die ursprünglichen Werte wiederhergestellt werden. Dieser Vorgang ist zugriffsbeschränkt und überprüfbar.
Wie schnell lässt sich Anonymisierung bei der Erfassung einführen?
Bei einer Erfassung über die API dauert die Anbindung für Entwickler, die REST-APIs kennen, üblicherweise 1–3 Tage. Für die API von anonym.legal ergänzen Sie Ihren Datenfluss um einen einzigen Verarbeitungsschritt: Sie senden den Text an die API, erhalten die anonymisierte Fassung und schreiben diese in Ihre Datenbank. Der MCP-Server für Arbeitsabläufe mit KI lässt sich in weniger als 5 Minuten einrichten.
Verlangt die EU-KI-Verordnung eine Anonymisierung von Daten?
Artikel 10 der EU-KI-Verordnung verlangt für Trainings- und Validierungsdaten von Hochrisiko-KI-Systemen „Daten-Governance- und Datenverwaltungsverfahren, die für die Zweckbestimmung des Hochrisiko-KI-Systems geeignet sind“. Dazu gehören Maßnahmen zur Erkennung von Verzerrungen und zur Sicherung der Datenqualität. Das setzt mittelbar voraus, dass bekannt ist, welche personenbezogenen Daten der Trainingsdatensatz enthält. Für KI-Systeme im Betrieb, die personenbezogene Daten verarbeiten, begründen Artikel 10 und Artikel 25 der DSGVO zum Datenschutz durch Technikgestaltung zusammen eine starke Vorgabe für die Anonymisierung bei der Datenaufbereitung.
Worauf bezieht sich Zero-Knowledge bei anonym.legal?
Zero-Knowledge bezeichnet nicht die Verarbeitung. Verschlüsselungsschlüssel werden mit Argon2id auf Ihrem Gerät abgeleitet. Eigene Muster, die Sie speichern, werden im Browser verschlüsselt; auf dem Server liegt nur der verschlüsselte Inhalt. Bei der Nutzung der anonym.legal-API werden Ihre Daten während der Übertragung durch TLS verschlüsselt. Der Erkennungsdienst muss den Text lesen, den er untersucht. Der Text wird im Arbeitsspeicher verarbeitet. Verschlüsselt gespeichert wird er nur, wenn Sie den Verlauf aktivieren, oder als Zuordnung von Platzhaltern für eine umkehrbare Anonymisierung. Diese Zuordnung bleibt standardmäßig 24 Stunden gespeichert, bei Wahl einer dauerhaften Speicherung bis zu 30 Tage. Der Schlüssel für die Verarbeitungsart „Verschlüsseln“ wird mit der Anfrage gesendet. Deshalb kann der Dienst den Text während der Verarbeitung lesen.
Ist Anonymisierung umkehrbar? Was ist, wenn wir die ursprünglichen Daten brauchen?
anonymize.solutions unterstützt sowohl Anonymisierung, die für Analysen und langfristige Speicherung nicht umkehrbar ist, als auch Pseudonymisierung, die für betriebliche Abläufe umkehrbar ist. Die Verarbeitungsarten zum Rückgängigmachen der Pseudonymisierung und zum Entschlüsseln stellen bei Bedarf die ursprünglichen Werte wieder her. Die Zuordnungstabelle wird geschützt und getrennt von der Betriebsdatenbank gespeichert. Zugriffsbeschränkungen sorgen dafür, dass nur berechtigte Arbeitsabläufe die Pseudonymisierung rückgängig machen können.