# Hashing Is Not Anonymisation

> A hashed customer list feels safe to share. European regulators – and arithmetic – disagree. What SHA-256 actually protects, what it doesn't, and how to handle hashed PII honestly.

- Source: https://www.8apps.co/blog/hashing-is-not-anonymisation
- Markdown: https://www.8apps.co/blog/hashing-is-not-anonymisation.md
- Published: 2026-09-02
- Author: 8apps Team
- Language: en

---
## 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](/google-workspace/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.

## Sources

- [GDPR Recital 26 – Not applicable to anonymous data](https://gdpr-info.eu/recitals/no-26/) – read 2026-09-02
- [EDPB Guidelines 01/2025 on Pseudonymisation](https://www.edpb.europa.eu/our-work-tools/documents/public-consultations/2025/guidelines-012025-pseudonymisation_en) – read 2026-09-02