Wann Ist ein Hash ein Personenbezogenes Datum? Das SRB-Urteil des EuGH und die Identität in Analytics
Mit dem Urteil EDPS gegen SRB hat der EuGH die Identifizierbarkeit zu einem relativen, kontextabhängigen Test gemacht. Was das für hash-basierte Analytics bedeutet — und warum ein täglich rotierender, gesalzener Hash sowohl der Lesart des Gerichts als auch der strengeren des EDSA standhält.
Die Frage, der jeder Analytics-Anbieter ausweicht, ist leicht zu stellen und schwer zu beantworten: Ist der Identifikator in deiner Datenbank ein personenbezogenes Datum? Am 4. September 2025 gab der EuGH die folgenreichste Antwort seit Jahren und stellte den gesamten Test auf den Kontext ab statt auf das Datum für sich.
Was EDPS gegen SRB tatsächlich entschied
Der Fall — EDPS gegen SRB, C-413/23 P — ging aus der Abwicklung der Banco Popular hervor. Das Single Resolution Board sammelte Kommentare von Aktionären, ersetzte die Identität jedes Autors durch einen alphanumerischen Code und übermittelte die codierten Kommentare an Deloitte als unabhängigen Bewerter. Deloitte besaß keinen Schlüssel zur Umkehr der Codes und keinen anderen Weg zu den Autoren.
Der EuGH entschied, dass pseudonymisierte Daten nicht automatisch für jede Partei, die sie berührt, personenbezogene Daten sind. Ob ein Datensatz personenbezogen ist, wird im Verhältnis zum Inhaber beurteilt — aus der Position des konkreten Empfängers, unter Berücksichtigung der ihm realistisch verfügbaren technischen, organisatorischen und rechtlichen Mittel.
Das ist der Test der relativen (oder kontextabhängigen) Identifizierbarkeit und die operative Lesart der "Mittel, die nach allgemeinem Ermessen wahrscheinlich genutzt werden" aus Erwägungsgrund 26. Ein Datum, das in der Hand des Verantwortlichen personenbezogen ist, kann in der Hand eines Empfängers, der wirklich niemanden re-identifizieren kann, nicht personenbezogen sein.
Das Spannungsverhältnis zum EDSA
Das Gericht stellte den Anbietern keinen Freibrief aus. Die Leitlinien 01/2025 des EDSA zur Pseudonymisierung verfolgen eine bewusst strengere Linie: Pseudonymisierte Daten bleiben personenbezogene Daten, solange irgendjemand — der Verantwortliche oder ein Dritter — die Mittel zur Re-Identifizierung behält. Der EDSA-Bericht vom Februar 2026 zu Anonymisierung und Pseudonymisierung ist das Gremium dabei, genau diese Lücke zwischen seiner Position und der des Gerichts aufzuarbeiten.
Für Entwickler ist die praktische Lesart konservativ. Geh nicht davon aus, dass ein gehashter Wert außerhalb des Anwendungsbereichs der DSGVO liegt, nur weil dein Dienst ihn nicht umkehren kann. Die richtige Frage lautet, ob eine Re-Identifizierung für irgendeinen Inhaber der Zusatzinformation nach allgemeinem Ermessen wahrscheinlich ist — und ob diese Zusatzinformation überhaupt noch existiert.
Warum die meisten Analytics-Hashes den Test nicht bestehen
Einen Identifikator zu hashen ist keine Anonymisierung. Ein SHA-256 einer E-Mail-Adresse ist deterministisch: dieselbe E-Mail ergibt stets denselben Digest. Wer eine Liste von Kandidaten-E-Mails hat, kann sie hashen und abgleichen. Der Hash ist ein stabiler, verknüpfbarer Schlüssel — bestenfalls Pseudonymisierung und unter beiden Lesarten ein personenbezogenes Datum, weil die Mittel zur Re-Identifizierung trivial verfügbar sind.
Dieselbe Falle erfasst eine gehashte IP, eine gehashte Geräte-ID oder jeden Digest einer Eingabe aus einem kleinen, aufzählbaren Raum. Determinismus plus erratbare Eingabe ergibt Re-Identifizierung. Die Hash-Funktion ändert die Bytes, nicht die Verknüpfbarkeit.
Was einen Hash wirklich verteidigbar macht
Zwei Eigenschaften bewegen einen Hash von "pseudonymisiertem personenbezogenem Datum" hin zu "nicht nach allgemeinem Ermessen re-identifizierbar": ein geheimes Salt, das nie zusammen mit den Daten gespeichert wird, und eine Eingabe, die nicht erschöpfend erraten werden kann und nicht über die Zeit fortbesteht. Das Identitätsmodell von Monoid baut genau darauf auf:
SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)
Die rohe IP und der User-Agent existieren nur so lange im Speicher des Workers, wie es zur Berechnung des Digests nötig ist; D1 speichert den Hash, nie die Eingaben. Das SALT_SECRET wird serverseitig gehalten und nie neben den Daten geschrieben, sodass ein Rainbow-Table- oder Brute-Force-Angriff auf die gespeicherten Hashes keinen Ankerpunkt hat. Und weil das Datum eine Eingabe ist, rotiert der Digest desselben Besuchers jede Mitternacht UTC. Es gibt keinen stabilen tagesübergreifenden Schlüssel zum Korrelieren.
Lass diese Konstruktion durch beide Tests laufen. Nach dem relativen Standard des EuGH besitzt kein Empfänger der gespeicherten Hashes — einschließlich Monoid, das seine eigene D1 abfragt — die nach allgemeinem Ermessen wahrscheinlichen Mittel zur Re-Identifizierung, weil das Salt getrennt ist und die Eingabe nicht aufzählbar. Nach dem strengeren "irgendjemand"-Standard des EDSA wird die nötige Zusatzinformation (rohe IP plus UA plus das geheime Salt für genau dieses Datum) nach Abschluss der Anfrage nirgends aufbewahrt. Die Mittel zur Re-Identifizierung sind nicht nur eingeschränkt; sie hören auf zu existieren.
So prüfst du deinen eigenen Stack
Das Urteil liefert eine konkrete Checkliste für jedes Analytics, auf das du dich verlässt:
- Ist die gehashte Eingabe aufzählbar? Eine E-Mail, eine Telefonnummer oder eine rohe IP lassen sich hashen und gegen eine Kandidatenliste abgleichen. Ist der Eingaberaum klein, ist der Hash in der Praxis umkehrbar.
- Ist ein geheimes Salt von den gespeicherten Daten getrennt? Ein Hash ohne Salt oder mit einem Salt im selben Speicher bietet keine echte Hürde gegen Re-Identifizierung.
- Besteht der Identifikator über Sitzungen hinweg fort? Ein stabiler Schlüssel, der die Aktivität einer Person über Wochen verknüpft, ist unter jeder Lesart ein personenbezogenes Datum. Ein täglich rotierender Schlüssel kann kein Profil ansammeln.
Der EuGH hat die Pseudonymisierung nicht zum sicheren Hafen erklärt, und der EDSA sorgt dafür, dass niemand sie so liest. Die dauerhafte Position ist die, die keine Auslegung braucht, um zu gewinnen: ein gesalzener, täglich rotierender Hash über einer nicht aufzählbaren Eingabe ist für niemanden nach allgemeinem Ermessen re-identifizierbar, weil das zur Umkehr nötige Material nie aufbewahrt wurde.
Comments
Loading comments…