PCI DSS 3.5.1.1: Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed
PCI DSS v4.0.1 control 3.5.1.1: the requirement in full, the 4 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
Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.
Summary
If you render PAN unreadable by hashing, the hash must be keyed and cover the whole card number.
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.1.a | Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures. |
| 3.5.1.1.b | Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7. |
| 3.5.1.1.c | Examine data repositories to verify the PAN is rendered unreadable. |
| 3.5.1.1.d | Examine audit logs, including payment application logs, to verify the PAN is rendered unreadable. |
This control exists because an unkeyed hash of a PAN is not unreadable. The card number space is small and structured enough to enumerate, so a plain hash can be reversed by computing hashes until one matches, and salting alone does not fix it once the salt is known. A keyed cryptographic hash defeats that, because reversal requires the key, which is why the requirement also drags in the whole of 3.6 and 3.7: the key protecting the hash needs managing like any other key. Two more details matter. It must cover the entire PAN, so hashing a portion is not this mechanism. And 3.5.1.1.d examines audit logs, including payment application logs, which puts logs squarely in scope for how PAN is rendered rather than treating them as somewhere PAN merely should not be.
What to prepare
- Documentation of the hashing method: vendor, system, algorithm, and that it is keyed.
- The key management processes for the hash key, meeting Requirements 3.6 and 3.7.
- Data repositories, examined to confirm PAN is unreadable.
- Audit and payment application logs, which are examined separately.
How to implement it
1. Use a keyed construction, not a salted one. A keyed hash is the mechanism the requirement names, and salt is not a substitute because it is stored alongside.
2. Treat the hash key as a data-encrypting key. It needs the storage, custodianship, rotation and destruction that Requirements 3.6 and 3.7 describe, which is a larger commitment than hashing usually implies.
3. Hash the whole number. A hash of part of the PAN does not satisfy this and leaves the rest unprotected.
4. Check the logs, not just the database. 3.5.1.1.d makes them explicit, and applications frequently log a PAN in a form the database never stores.
Where this commonly fails
- An unkeyed SHA hash, which looks like protection and is enumerable.
- A keyed hash with the key stored beside the data or in application configuration.
- Hashing applied in the database while logs carry PAN in another form.
- Key management for the hash key never established, since hashing did not feel like encryption.
Related controls
This control refers to 3.5.1.
Others in section 3.5:
| Control | What it requires |
|---|---|
| 3.5.1 | PAN is rendered unreadable anywhere it is stored by using any of the following approaches… |
| 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.5.1 · All controls · 3.5.1.2 →
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.