Not by itself. Hashing or tokenising fields is pseudonymisation, and UK regulator guidance says pseudonymised personal data stays in scope of data protection law. It lowers risk, but a staging database built that way still needs the same care as production. This is general information, not legal advice.
Definitions
Pseudonymisation, as the GDPR defines it, means processing personal data so that it can no longer be attributed to a specific person without additional information, provided that information is kept separately and protected by technical and organisational measures.
Anonymisation is a different outcome: people are not identifiable at all. The UK ICO describes anonymisation as a way to use or share data by making sure people are not identifiable, and states that pseudonymisation is not a way of transforming data so the law no longer applies.
| Technique | Typical result | Treat staging copy as |
|---|---|---|
| Hash of an email | Pseudonymised, guessable if inputs are guessable | Personal data |
| Token with a lookup table kept elsewhere | Pseudonymised | Personal data |
| Fully synthetic records | No link to real people | Not personal data, if truly synthetic |
| Aggregated counts only | Depends on group sizes | Review each case |
Why hashes are weaker than they look
A hash is a fixed function. If an attacker can guess the inputs, they can hash the guesses and compare. Email addresses, phone numbers and national identifiers come from small or structured spaces, so hashes of them are often reversible by guessing. Adding a secret key helps, but then the key is the "additional information" and must be kept apart from the staging data.
Hashed values also stay linkable. The same input gives the same output, so someone holding two datasets can join them. That is useful for tests and equally useful for re-identification.
Steps to decide
- List the fields in the copy and mark which carry direct identifiers, such as names and emails.
- For each one, ask whether staging truly needs the real value. Usually it needs a value with the right shape.
- Replace with generated values for fields tests do not depend on.
- Where relationships matter, use a keyed mapping and store the key outside the staging environment. See the related post on keeping joins working after masking.
- Treat the result as personal data anyway. Apply access control, retention limits and deletion.
- Document the reasoning, so a reviewer can see why each field was handled that way.
The GDPR also asks controllers to apply data minimisation, meaning data adequate, relevant and limited to what is necessary for the purpose, and to keep identifiable data no longer than necessary. Staging purposes rarely justify more than a generated dataset.
Mistakes to avoid
- Calling a hashed column "anonymised" in a ticket or a policy.
- Storing the salt or key in the same repository or database as the output.
- Forgetting free text and attachments, which hashing rules do not touch.
- Assuming a contractor can receive the dataset without a data processing agreement just because names are hashed.
Quick check
Is a salted hash enough?
A salt stops precomputed tables but does not stop guessing of low variety inputs. A secret key does better, yet the result is still pseudonymised data.
Is pseudonymisation worth doing then?
Yes. The GDPR itself lists pseudonymisation among appropriate security measures. It reduces harm if data leaks. It just does not remove your obligations.
Is fully synthetic data outside the rules?
If no record relates to a real person, it is generally not personal data. Generating it from real records without care can leak patterns, so keep the generator independent of production.
Sources
- ICO guidance on pseudonymisation
- GDPR Article 4, definitions
- GDPR Article 5, principles
- GDPR Article 32, security of processing
- ICO anonymisation guidance introduction
Last reviewed: 19 October 2026.
