A marketplace must stop storing raw phone numbers in its analytical estate. Analysts still need to join orders to support tickets by the same customer, and the company must be able to delete an individual's data on request. Which approach fits?
Show the full answer Hide the answer
The deciding property
Two requirements have to hold at once: the same input must produce the same token so joins work, and the mapping must be reversible or destroyable so an erasure request can be satisfied. Only a vault-backed deterministic scheme gives both.
Deleting the vault entry for one person renders every token for them meaningless everywhere it was copied, without touching the analytical tables. That single property is why vaults exist: erasure becomes an operation on one small system rather than a search of every dataset.
What it costs
The vault is now a high-availability dependency for any process that needs the real value, and it is the most sensitive system in the estate. Detokenisation must be audited and rate-limited, because unlimited detokenisation rights make the whole scheme decorative. Budget for the vault being a single point of failure for the customer-facing flows that need the raw number.
What would flip the decision
| If this changes | Choose | Because |
|---|---|---|
| No join across systems is needed | Random tokens or redaction | The cheapest option that meets the requirement wins |
| The raw value must be recoverable by an application in the request path | Format-preserving encryption | A key operation beats a vault round trip per row |
| The estate must prove a value was never stored | Irreversible transformation plus a separate consent record | A vault means the value is still held somewhere |
When not to tokenise at all
If no downstream process needs the value and no join needs the identity, drop the column. A tokenised field that nobody uses is a vault dependency and an audit surface bought for nothing.
Why the other options fail
- Salted hash of the phone number. With one shared salt it is deterministic and joinable, and it is also trivially reversible for a small domain: the space of valid phone numbers is around 10^10, which is minutes of brute force on commodity hardware. Regulators have repeatedly treated hashed identifiers of small domains as personal data, so the obligation does not go away. With a per-record salt it is irreversible and the joins break.
- Format-preserving encryption with a shared key. Deterministic and joinable, and a good fit when a system must recover the value locally. It fails the erasure requirement: deleting one person means rotating a key that protects everyone, or keeping a per-subject key, which is a vault with extra steps.
- Random tokenisation with no mapping stored. Maximum privacy and no joins, because the same phone number tokenises differently each time. It meets the first half of the brief and destroys the analytical use case that motivated the work.