What Is Tokenization?

Tokenisation replaces a sensitive value with a surrogate that has no mathematical relationship to the original. The real value is held in a separate, tightly controlled vault, and the token is meaningless to anyone who obtains it without access to that vault.

That independence is the distinction from encryption. Encrypted data can be decrypted by anyone holding the key; a token can only be resolved by the tokenisation service, which is a separate system with its own access control and its own audit trail.

Why payments adopted it first

The commercial driver was scope reduction. Under payment card rules, systems that store or process card data fall within the assessment boundary, and that boundary is expensive. Replacing the card number with a token at the point of capture means downstream systems hold tokens rather than card data and fall out of scope.

The same logic now applies to personal and health identifiers under privacy regimes: if the application database holds tokens rather than identifiers, a compromise of that database exposes considerably less, and the regulatory consequence is different.

Format preservation and its trade-off

Tokens can be generated to match the format of the original value, so existing validation, field widths and database schemas continue to work without modification. That makes retrofitting tokenisation into an existing application far more tractable.

It also means a token looks like real data, which has consequences. Staff may not realise they are handling a surrogate, and a token that preserves recognisable elements — such as the last four digits — carries a small amount of the original information by design.

The vault is the whole system

Everything rests on the tokenisation service. It holds the mapping, so compromising it exposes every value that was ever tokenised, and its availability determines whether any dependent process can function.

That makes it a system requiring the strongest access control, the most thorough logging and genuine availability engineering. Organisations that tokenise into a vault with ordinary application-grade protection have concentrated their risk rather than reduced it.

Comparing it with encryption honestly

Both protect a value; they fail differently. Encrypted data can be decrypted by anyone with the key, so key compromise exposes everything encrypted under it, wherever that ciphertext has spread. A token is useless without the vault, so the same compromise requires reaching a separate, more tightly controlled system.

Encryption preserves no format by default and works offline. Tokenisation preserves format readily and requires the vault to be available for every resolution, which introduces an operational dependency encryption does not have.

The practical division is that tokenisation suits discrete sensitive values appearing across many systems — card numbers, identifiers, health numbers — while encryption suits bulk data and anything needing offline processing.

Confirm the vault has its own disaster recovery plan as well.

Where to start

Identify the systems that hold sensitive identifiers but never need the real value — reporting, analytics, support tooling. Those are the cheapest tokenisation candidates and they usually represent a large share of where the data has spread.

See encryption in practice. GuardsArm runs security risk assessments.