Why the distinction matters#
In customer conversations the two words get used interchangeably, and that causes real confusion: one names what a system does, the other names what a dataset is. A security engineer asks about tokenization; a data protection officer asks about pseudonymization. They are looking at the same architecture through different vocabularies.
The connective tissue is the "additional information" clause. Pseudonymized data is data whose re-identification key exists but is held separately, under protection. In Salus, that additional information is exactly the token mapping — and its separation is architectural, not procedural: the vault lives inside the customer-controlled environment while the external provider receives tokens only, with no access path to the mapping.
The three concepts, side by side#
| Concept | Meaning | Salus context |
|---|---|---|
| Tokenization | Replaces values with generated tokens | The mechanism used before provider egress |
| Pseudonymization | Requires separate additional information for attribution | May describe the resulting dataset, depending on the legal and operational context |
| Anonymization | Makes re-identification no longer reasonably possible | Not the objective of reversible restoration — see Anonymization |
What Salus does and does not claim#
Salus provides the technical controls a pseudonymization posture depends on: detection before egress, typed reversible tokens, a separately secured mapping under customer-controlled keys, audited restoration, and policy over who can restore what. What Salus does not do is declare your processing pseudonymized — that classification depends on the complete context of the deployment: token scope, access controls, what other data the recipient holds, and the legal analysis of the processing operation.