The comfortable belief
Hash the emails, hash the phones, and the list is "anonymised" – safe to email around, safe to hand to an agency, out of scope for privacy rules. That belief is doing a lot of work in a lot of marketing teams, and it is wrong on both the regulatory and the mathematical front.
What the regulators actually say
The GDPR settles this in Recital 26: "Personal data which have undergone pseudonymisation, which could be attributed to a natural person by the use of additional information should be considered to be information on an identifiable natural person." The European Data Protection Board's Guidelines 01/2025 on Pseudonymisation, adopted in January 2025, build on exactly that starting point.
Hashing is pseudonymisation – a transformation that can be undone by someone holding the right additional information. Hashed customer data is still personal data in that framework. Not a grey area; the quoted sentence is the framework.
What the arithmetic says
A cryptographic hash cannot be reversed algebraically – that much of the comfortable belief is true. But phone numbers do not need reversing; they need guessing. A national numbering plan is a small space by modern compute standards: hash every plausible number, compare against the list, done. This is not a theoretical attack; it is a lookup table.
Emails resist a little more – the space is larger and lumpier – but known addresses check instantly: anyone holding jane@example.com can hash it and test her presence in your "anonymous" file. Membership disclosure is the quiet failure: the list leaks who is in it to anyone who already knows the people.
Why you cannot just add salt
The standard hardening – salting, adding a secret value before hashing – is exactly what ad-platform matching cannot tolerate. Matching works because both sides hash the same input the same way; a salt only you know produces digests only you can produce, and nothing matches. Upload hashing is unsalted by design, which means it carries exactly the weaknesses above, permanently. (The full salted-vs-unsalted question is its own guide.)
So handle a hashed list like what it is
- Access-control it like the raw list – same folder permissions, same sharing rules.
- Hash, then destroy the working trail: copy the hashed column, paste as values, delete the raw column from any file that travels.
- Share the hashed file deliberately, under the same agreements the raw file would need – not casually because "it's hashed".
- Keep raw and hashed files apart – a spreadsheet holding both columns side by side is the lookup table, pre-built.
Where Hash Data fits
None of this argues against hashing – platforms require it, and keeping raw PII out of upload files is strictly better than the alternative. It argues for doing it with eyes open. Hash Data does the hashing inside Google Sheets, so the transformation happens in the sheet you already control rather than in a web tool you paste customer data into.
→ Hash Data on the Google Workspace Marketplace
Sources
- GDPR Recital 26 – Not applicable to anonymous data – read 2026-09-02
- EDPB Guidelines 01/2025 on Pseudonymisation – read 2026-09-02