What Is Pseudonymization?
**Pseudonymization is processing personal data so that it can no longer be attributed to a specific person without additional information, where that additional information is held separately and protected.** That is GDPR Article 4(5), near enough verbatim. The practical consequence is the part people miss: pseudonymized data is still personal data, and GDPR still applies to it in full. This matters most in non-production environments, where teams replace names and email addresses in a sandbox, conclude the data is now anonymous, and treat the environment as out of scope. It is not. ---
What does GDPR Article 4(5) actually say?
Three conditions have to hold:
- The data can no longer be attributed to a specific person without additional information.
- That additional information is kept separately.
- It is subject to technical and organisational measures that stop it being recombined.
The third condition is the one that fails in practice. A mapping table that lives in the same org, readable by the same admin profile, is not separated in any meaningful sense. Re-identification is a query away.
How is pseudonymization different from anonymization?
Anonymization is irreversible. Recital 26 states that GDPR does not apply to anonymous information, which means data that has been anonymized falls outside the regulation entirely. Nobody can re-identify the person, including you.
Pseudonymization is reversible by design. You keep the ability to re-identify, because you usually need it: to honour an erasure request, to reconcile records, to debug a support case.
That difference is the whole regulatory distinction:
| Concept | Reversible? | Still personal data? |
|---|---|---|
| Pseudonymization | Yes, with separately held information | Yes, GDPR applies in full |
| Anonymization | No | No, outside GDPR scope |
| Masking | Depends on technique | Depends |
Masking is not a legal term. It is a practical one that covers both approaches, which is why "we masked it" answers no compliance question on its own. The question is always whether re-identification remains possible.
Why is true anonymization so hard?
Because relational data re-identifies itself.
Strip the name from a Contact and the record still carries a job title, an account, a region, a close date and an amount. In a small enough population, that combination is unique. Quasi-identifiers do the work the name used to do.
How much identifying power sits in ordinary fields is easy to underestimate. Sweeney's analysis of 1990 US census data found 87% of the US population uniquely identifiable from ZIP code, date of birth and gender alone.
Genuine anonymization usually requires generalising or suppressing those fields too, which is exactly what makes the data useless for the testing you built the sandbox for. That trade-off is why most non-production data ends up pseudonymized rather than anonymized, and why claiming otherwise is risky.
What does pseudonymization get you if the data stays in scope?
It is still worth doing, for three concrete reasons.
Article 32 counts it as a security measure. GDPR names pseudonymization explicitly as an appropriate technical measure for securing processing. Implementing it is evidence of compliance, not a workaround for it.
It shrinks breach impact. A breach of a pseudonymized sandbox exposes substitutes, not real people. That changes the severity assessment and can change whether notification is required.
It reduces internal exposure. Developers, contractors and offshore teams get realistic data to work with and no real customer identities.
What it does not get you is an exemption. You still need a lawful basis, you still honour erasure requests against the environment, and you still count it in your Record of Processing Activities.
What does this mean in Salesforce?
A full-copy sandbox is a byte-for-byte copy of production, including every real name, email address and financial figure. Refreshing it copies the personal data again.
Field-level masking replaces those values with realistic substitutes. Done properly it preserves format and distribution, so testing still works, while removing the real identities. Done consistently across related objects, it preserves referential integrity, so a masked Contact and the Cases referencing it stay coherent.
That is pseudonymization. It substantially reduces risk and it does not remove the sandbox from GDPR scope. Treat the environment as in scope, keep it in your RoPA, and make sure erasure requests reach it.
Sandbox DataMasker is the Cloud Compliance product for this, running as Apex inside your own org so no data leaves Salesforce during the process.
Key Takeaways
GDPR Article 4(5) defines pseudonymization as processing personal data so it can no longer be attributed to a specific person without additional information, which must be kept separately and subject to safeguards.
Pseudonymized data is still personal data. GDPR applies to it in full, including access, erasure and breach notification obligations.
Anonymized data is different. Recital 26 puts truly anonymous data outside GDPR entirely, but true anonymization is hard to achieve in a relational database without destroying the data's usefulness.
The separation is the control. If the mapping table sits in the same system, under the same access rules, as the pseudonymized data, you have not achieved the separation the Article requires.
Most Salesforce sandbox masking is pseudonymization, not anonymization. That is a legitimate risk-reduction measure, but it does not take the sandbox out of GDPR scope.
Frequently Asked Questions
See how this works in your Salesforce org
30-minute demo tailored to your specific use case and data model.