Der bequeme Glaube
E-Mail-Adressen hashen, Telefonnummern hashen – und schon gilt die Liste als "anonymisiert": bedenkenlos verschickt, bedenkenlos an eine Agentur übergeben, außerhalb des Datenschutzrechts. Dieser Glaube leistet in vielen Marketing-Teams sehr viel Arbeit. Und er ist falsch – rechtlich wie mathematisch.
Was die Aufsichtsbehörden tatsächlich sagen
Die DSGVO klärt das in Erwägungsgrund 26: "Einer Pseudonymisierung unterzogene personenbezogene Daten, die durch Heranziehung zusätzlicher Informationen einer natürlichen Person zugeordnet werden könnten, sollten als Informationen über eine identifizierbare natürliche Person betrachtet werden." Die im Januar 2025 angenommenen Leitlinien 01/2025 des Europäischen Datenschutzausschusses zur Pseudonymisierung bauen genau auf diesem Ausgangspunkt auf.
Hashing ist Pseudonymisierung – eine Transformation, die sich rückgängig machen lässt, wenn jemand die passenden Zusatzinformationen besitzt. Gehashte Kundendaten bleiben in diesem Rahmen personenbezogene Daten. Keine Grauzone: Der zitierte Satz ist der Rahmen.
Was die Mathematik sagt
Ein kryptografischer Hash lässt sich nicht algebraisch umkehren – so weit stimmt der bequeme Glaube. Aber Telefonnummern muss niemand umkehren, man muss sie raten. Ein nationaler Nummernplan ist nach heutigen Rechenmaßstäben ein winziger Raum: jede plausible Nummer hashen, mit der Liste abgleichen, fertig. Das ist kein theoretischer Angriff, das ist eine Nachschlagetabelle.
E-Mail-Adressen wehren sich etwas länger – der Raum ist größer und unregelmäßiger –, aber bekannte Adressen sind sofort geprüft: Wer jane@example.com besitzt, hasht sie und testet ihre Anwesenheit in deiner "anonymen" Datei. Die stille Schwachstelle heißt Membership Disclosure: Die Liste verrät jedem, der die Personen ohnehin kennt, wer darin steht.
Warum Salt hier nicht hilft
Die übliche Härtung – Salting, also ein geheimer Wert, der vor dem Hashen beigemischt wird – ist genau das, was der Abgleich bei Werbeplattformen nicht verträgt. Matching funktioniert, weil beide Seiten dieselbe Eingabe auf dieselbe Weise hashen; ein Salt, den nur du kennst, erzeugt Digests, die nur du erzeugen kannst – und nichts passt mehr zusammen. Upload-Hashing ist konstruktionsbedingt ungesalzen und trägt die oben beschriebenen Schwächen damit dauerhaft mit sich. (Die vollständige Frage gesalzen gegen ungesalzen hat einen eigenen Leitfaden.)
Behandle eine gehashte Liste also als das, was sie ist
- Zugriffsrechte wie bei der Rohliste – dieselben Ordnerberechtigungen, dieselben Freigaberegeln.
- Hashen, dann die Arbeitsspur beseitigen: gehashte Spalte kopieren, als Werte einfügen, Rohspalte aus jeder Datei löschen, die das Haus verlässt.
- Die gehashte Datei bewusst teilen – unter denselben Vereinbarungen, die auch die Rohdatei bräuchte, nicht beiläufig, "weil sie ja gehasht ist".
- Roh- und Hash-Dateien getrennt halten – eine Tabelle mit beiden Spalten nebeneinander ist die Nachschlagetabelle, fertig vorbereitet.
Wo Hash Data hineinpasst
Nichts davon spricht gegen Hashing – Plattformen verlangen es, und rohe PII aus Upload-Dateien herauszuhalten ist klar besser als die Alternative. Es spricht dafür, es mit offenen Augen zu tun. Hash Data hasht innerhalb von Google Tabellen: Die Transformation passiert in der Tabelle, die du ohnehin kontrollierst, statt in einem Web-Tool, in das du Kundendaten hineinkopierst.
Quellen
- DSGVO Erwägungsgrund 26 – Nicht anwendbar auf anonyme Daten – gelesen am 02.09.2026
- EDSA-Leitlinien 01/2025 zur Pseudonymisierung – gelesen am 02.09.2026