If you must store a primary account number, PCI DSS 3.5.1 requires it to be rendered unreadable wherever stored, using one of four approaches: a one-way hash of the entire PAN, truncation, index tokens, or strong cryptography with key management. The first question is whether you need to store it at all. This is not legal advice.
Start with 3.2.1
3.2.1 says storage of account data is kept to a minimum. The simplest control is not holding the number. If a payment provider can hold it and give you a token, your stored data shrinks. Sensitive authentication data such as CVV is separate: 3.3.1 bans keeping it after authorization even if encrypted.
The four approaches
| Approach | What it means | Trade-off |
|---|---|---|
| One-way hash | Hash of the entire PAN using strong cryptography. 3.5.1.1 says it must be a keyed cryptographic hash with key management | You cannot recover the number, useful for matching |
| Truncation | Store only part of the number. Hashing cannot replace the removed part | Cannot rebuild the PAN, but see correlation below |
| Index token | A reference that stands in for the PAN | Depends on how the token vault is protected |
| Strong cryptography | Encrypt with documented key management | Number is recoverable, so keys become the target |
The text warns that if hashed and truncated versions of the same PAN, or different truncation formats, exist in one environment, extra controls must stop them being correlated to reconstruct the original. The applicability note calls rebuilding it from both "relatively trivial."
Where the rule reaches
The note says 3.5.1 applies to primary storage such as databases and flat files, and to non-primary storage such as backups, audit logs and exception or troubleshooting logs. So check logs and temporary files too.
Display is different
3.4.1 covers display: PAN is masked when displayed, with the BIN and last four digits as the maximum shown, so only people with a legitimate business need see more. The note says not to confuse this with 3.5.1 for stored data.
Steps
- Map every place PAN lands, including logs and exports.
- Remove what you do not need.
- Choose an approach per store and document it.
- Put keys in a managed system, with rotation and access control.
- Mask on screen and in support tools.
- Test with a search for PAN-like strings in data and logs.
Quick check
Is a plain hash enough?
3.5.1.1 says hashes must be keyed cryptographic hashes of the entire PAN, with key management.
Is disk encryption enough?
Usually not on its own. 3.5.1.2 allows disk-level or partition-level encryption on removable media, and for non-removable media PAN must also be rendered unreadable by another mechanism that meets 3.5.1, such as truncation or data-level encryption.
On Safeguard: dependency scanning helps check the cryptography libraries you ship for known vulnerabilities. It does not choose a storage design for you. Try the free scan at gold.safeguard.sh/scan.
Sources
Wording is from v4.0. Confirm in the current version.
Last reviewed: 19 October 2026.
