Encryption turns data into ciphertext that anyone with the key can reverse. Tokenization replaces a value, such as a card number, with a token that is not mathematically derived from it, and keeps the original in a protected vault. The PCI Council's tokenization guidance says tokenization can reduce PCI DSS scope, but only when done correctly.
How they differ
With encryption, the ciphertext and the key together are the data. Anyone holding both can recover it, and key management applies wherever the data lives.
With tokenization, the system stores a token in your databases, logs and reports. The real card number lives in a card data vault. The PCI Security Standards Council supplement notes that scope reduction depends on confirming the primary account number (PAN) is not retrievable from any system component removed from scope, and that tokens must not be mathematically derived from the PAN.
The catch: reversible tokens
The same guidance says that where a token is generated by a reversible encryption method, with the token derived from the PAN using an algorithm and key, the token is an encrypted PAN and may be subject to PCI DSS. Calling something a token does not change its scope.
It also says that if the PAN is retrievable by the merchant, the merchant environment will be in scope.
Where each fits
- Protect files, backups, databases from theft of storage. Better fit: Encryption.
- Keep real card numbers out of most systems. Better fit: Tokenization.
- Pass data between systems that must read the real value. Better fit: Encryption, with key controls.
- Analytics on stand-in values. Better fit: Tokenization.
What you still have to do
- Segment the vault. The supplement says out-of-scope networks and systems must not have access to the vault and must be segmented from it.
- Manage keys that protect PAN in the vault.
- If a provider runs the vault, agree responsibilities in writing. The supplement stresses properly scoping the division of responsibility.
- Do a risk analysis for both in-scope and out-of-scope components.
The best protection is not storing it
OWASP's cryptographic storage guidance makes the same point: the main principle is to avoid storing sensitive data at all, which is especially relevant for credit card details.
Questions to ask a tokenization provider
If a provider runs the vault, the PCI guidance is clear that the division of responsibility must be properly scoped. Useful questions: Where is the vault and who can reach it? Are tokens random or derived from the card number by a key? What happens to your tokens if you leave the provider? Which of your systems can still see a card number, even briefly, before it is swapped? Which segmentation controls separate the vault from out-of-scope networks? What evidence will you receive for your own assessment? The answers decide what stays in scope, so get them in writing and share them with your assessor early.
Quick check
Does tokenization take me out of PCI DSS entirely?
Not automatically. It can reduce scope, but systems that handle PAN or the vault stay in scope, and you must validate the scope with your assessor.
Is format preserving encryption a token?
If the output is derived from the PAN with a key, the PCI guidance treats it as encrypted PAN, not a scope-removing token.
This post is general information, not assessment advice.
Sources
- PCI SSC Information Supplement: PCI DSS Tokenization Guidelines
- OWASP Cryptographic Storage Cheat Sheet
Last reviewed: 19 October 2026.
