What Is Data Anonymization?
**Data anonymization is altering data irreversibly so that no one can identify the individual it came from, using any means reasonably likely to be used.** GDPR Recital 26 is explicit about the consequence: the regulation does not apply to anonymous information. It is the only technique that removes data from scope entirely. That makes it attractive, and it makes overclaiming it dangerous. If a regulator concludes your "anonymized" dataset can be re-identified, you were processing personal data without the controls you thought you had removed the need for. ---
What does Recital 26 actually require?
The test is not about intent. It asks whether identification is possible using means reasonably likely to be used, accounting for cost, time, available technology and any other data that could be combined with yours.
Three things follow.
It is not enough that you cannot re-identify. If somebody else could, by combining your dataset with a public one, the data is not anonymous.
It is not a one-time judgement. Technology and available datasets change. Something anonymous in 2019 may be re-identifiable now.
It is a documented assessment, not an assertion. If you rely on anonymization to take a dataset out of scope, you should be able to show the reasoning.
Why do quasi-identifiers matter so much?
Because identity does not live in the name field.
Delete the name from a Salesforce Contact and what remains is a job title, an account, a region, an industry, a created date, an opportunity amount and a close date. In a population of a few thousand, that combination is frequently unique. Anyone holding a second dataset with overlapping fields can rejoin them.
This is why "we removed the PII fields" is not anonymization. The identifying power was distributed across the record.
The canonical demonstration is Latanya Sweeney's analysis of 1990 US census data, which found that 87% of the US population, 216 million of 248 million people, were uniquely identifiable from just three fields: five-digit ZIP code, date of birth and gender. Roughly 53% remained unique on town, date of birth and gender alone. None of those three fields is a name.
Real anonymization techniques address this directly: generalising values into bands, suppressing rare combinations, adding noise, or aggregating to a level where individuals disappear. Each of them destroys some of the detail that made the data worth keeping.
Anonymization or pseudonymization: which do you actually have?
Ask one question. Can anyone reverse it?
If a mapping exists anywhere, in any system, held by anyone, the answer is yes and you have pseudonymized data. It remains personal data, GDPR applies, and you carry the full set of obligations.
If no mapping exists and re-identification through quasi-identifiers is not reasonably possible, you have anonymized data and it is out of scope.
| Question | Anonymization | Pseudonymization |
|---|---|---|
| Reversible | No | Yes, with separate information |
| GDPR applies | No | Yes |
| Erasure requests apply | No | Yes |
| Counts in your RoPA | No | Yes |
| Typical sandbox masking | Rarely | Usually |
Most teams have the right-hand column and describe it using the left-hand word. Correcting that language costs nothing and removes a real exposure.
When is anonymization the right choice?
It fits where you need the shape of the data but not the individuals in it.
Analytics and reporting. Aggregate revenue by region and quarter needs no identities at all.
Long-term retention. Where a regulation requires you to keep a transaction record for seven years but data minimisation says stop holding the person, irreversibly stripping the identifying fields can satisfy both. This is often the most useful move in retention planning and it is routinely overlooked in favour of a binary keep-or-delete choice.
Model training. Training on anonymized data avoids embedding personal data into a model you cannot later erase from.
It fits badly where you need to trace a record back to a person, which covers most operational testing.
What does this mean in Salesforce?
Sandbox masking replaces field values with realistic substitutes. Because the substitution preserves format, distribution and relationships, the sandbox stays useful for testing. Because those properties are preserved, the data usually remains re-identifiable in principle. That is pseudonymization, and it should be documented as such.
Where anonymization genuinely applies in a Salesforce estate is retention. When a record reaches the end of its retention period but the transaction must be kept, irreversibly removing the identifying fields keeps the record and removes the person. Data Retention Manager applies that as a policy across standard and custom objects, with an audit record of each run.
The honest summary: mask your sandboxes and call it pseudonymization; anonymize at end-of-retention and be able to prove it was irreversible.
Key Takeaways
Anonymization is irreversible. Under GDPR Recital 26, data that is genuinely anonymous is not personal data, and the regulation does not apply to it at all.
The test is whether re-identification is reasonably possible by anyone, using any means reasonably likely to be used. It is not whether you personally intend to re-identify.
Quasi-identifiers defeat naive anonymization. Removing a name leaves job title, region, account size and dates, and that combination is often unique in a small population.
Anonymization and data utility trade against each other directly. Anonymize hard enough to be safe and the data often stops being useful for testing or analytics.
Most Salesforce sandbox masking is pseudonymization, not anonymization. Claiming anonymization you cannot defend is a worse position than correctly documenting pseudonymization.
Frequently Asked Questions
See how this works in your Salesforce org
30-minute demo tailored to your specific use case and data model.