Replacing names with hashed or random IDs is pseudonymisation, not anonymisation. Under GDPR, pseudonymised data is still personal data if the information that could re-link it exists anywhere, so analytics teams should keep protecting it and should not tell anyone it is anonymous.
What the text says
GDPR Article 4 defines pseudonymisation as processing personal data in such a manner that it can no longer be attributed to a specific data subject without additional information, provided that additional information is kept separately and protected by technical and organisational measures. The key point is that re-linking remains possible with the extra information.
That is a useful security measure. It lowers risk if a table leaks. It does not take the table out of scope for privacy law, and this article is not legal advice, so confirm specifics with counsel.
Why a plain hash is weak
Teams often hash an email with a standard function and call it done. Problems:
- Inputs with low entropy, such as emails, phone numbers and national ID formats, can be guessed and hashed to compare. An attacker who gets the table can test candidate values.
- The same input always gives the same output, so records stay linkable across datasets. That is a feature for joins and a risk for re-identification.
- If the hash function and any salt are known or shared widely, protection falls further.
A keyed approach is stronger: a secret key held outside the analytics environment, with access limited to the few services that need to map back. A random surrogate ID, with the mapping table stored separately, is stronger still, because there is nothing to compute.
Anonymisation is a higher bar
Truly anonymous data means individuals cannot be identified by means reasonably likely to be used. Removing the name column rarely gets there. Combinations of age, postcode, job title and dates can single someone out. If you need to publish or share widely, involve a privacy specialist and test re-identification risk rather than assuming.
Decision guide for analysts
- Do you need to link records across datasets? Use a keyed pseudonym.
- Do you need to reverse it later? Keep the mapping in a separate, restricted system.
- Do you only need aggregates? Aggregate early and drop record level data.
- Are you sharing outside the company? Assume the data is personal until a specialist says otherwise.
Operational controls
- Store keys and mapping tables apart from the analytics warehouse, with separate access.
- Rotate keys on a defined schedule and document what rotation does to joins.
- Log access to the mapping system.
- Label datasets honestly in your catalog: raw, pseudonymised or aggregated. Never use anonymous as a label unless it was tested.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you keep records of the controls above, and its asset discovery helps find the systems involved. See https://gold.safeguard.sh/scan for a free scan of the code that builds your datasets.
Quick check
Is a hashed email address anonymous?
No. It can often be re-identified by hashing guessed values, and it remains personal data under GDPR if it can be attributed to a person with additional information.
Where should the re-linking information live?
Separately from the pseudonymised data, protected by technical and organisational measures, as Article 4 describes.
Sources
Last reviewed: 19 October 2026.
