PCI DSS 3.5.1: PAN is rendered unreadable anywhere it is stored by using any of the following approaches
PCI DSS v4.0.1 control 3.5.1: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 3.5.
Requirement 3: Protect Stored Account Data › Section 3.5
PAN is rendered unreadable anywhere it is stored by using any of the following approaches:
- One-way hashes based on strong cryptography of the entire PAN.
- Truncation (hashing cannot be used to replace the truncated segment of PAN).
- If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.
- Index tokens.
- Strong cryptography with associated key-management processes and procedures.
Summary
Wherever a card number is stored, store it in a form that cannot be read back: hashed, truncated, tokenised, or strongly encrypted.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 3.5.1.a | Examine documentation about the system used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (if applicable) to verify that the PAN is rendered unreadable using any of the methods specified in this requirement. |
| 3.5.1.b | Examine data repositories and audit logs, including payment application logs, to verify the PAN is rendered unreadable using any of the methods specified in this requirement. |
| 3.5.1.c | If hashed and truncated versions of the same PAN are present in the environment, examine implemented controls to verify that the hashed and truncated versions cannot be correlated to reconstruct the original PAN. |
The centre of Requirement 3, and the one that decides how much of the rest applies to you. Four approaches are permitted and they are not equivalent. Truncation and tokenisation remove the data, so there is nothing to decrypt and no keys to manage. Hashing and encryption keep it, which brings 3.6.1 and the whole of section 3.7 with them. Two details catch people: a hash must be keyed (v4 requires a keyed cryptographic hash of the entire PAN, not a bare digest), and where both a hashed and a truncated version of the same PAN exist, additional controls are required because together they can reconstruct it. Disk-level encryption gets its own treatment in 3.5.1.2 and does not satisfy this on its own for most systems.
What to prepare
- The list of every place PAN is stored, from 3.2.1, with the method used at each.
- Evidence of the method: the algorithm and key strength for encryption, the truncation format, or the tokenisation provider.
- Where hashing is used, evidence the hash is keyed and covers the entire PAN.
- Where hashed and truncated versions of the same PAN coexist, the controls preventing correlation.
How to implement it
1. Prefer removing the data to protecting it. Truncation and tokenisation take the storage out of scope for key management entirely; encryption keeps it and brings section 3.7 with it. That is the largest cost decision in Requirement 3.
2. Check what your database actually does. Transparent or full-disk encryption protects against a stolen disk and not against a query, which is why 3.5.1.2 restricts when it is acceptable. Read that before relying on it.
3. Key your hashes. An unkeyed SHA of a PAN is brute-forceable: the search space is small enough that a bare digest is not protection, which is why v4 says keyed.
4. Find the copies. Backups, exports, read replicas, data warehouses and logs each store PAN separately, and each needs its own answer here rather than inheriting production's.
Where this commonly fails
- Full-disk encryption treated as sufficient, when it protects only against physical loss of the media.
- An unkeyed hash, which v4.0.1 no longer accepts.
- A truncated version and a hashed version of the same PAN in different systems, with nothing preventing correlation.
- Production encrypted while a reporting replica or an export holds PAN in the clear.
Related controls
Others in section 3.5:
| Control | What it requires |
|---|---|
| 3.5.1.1 | Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed… |
| 3.5.1.2 | If disk-level or partition-level encryption… |
| 3.5.1.3 | If disk-level or partition-level encryption is used… |
← 3.4.2 · All controls · 3.5.1.1 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.