PCI DSS 3.7.3: Key-management policies and procedures are implemented to include secure storage
PCI DSS v4.0.1 control 3.7.3: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.7.
Requirement 3: Protect Stored Account Data › Section 3.7
Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.
Summary
Write down how keys are stored, and store them that way.
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.7.3.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data to verify that they define secure storage of cryptographic keys. |
| 3.7.3.b | Observe the method for storing keys to verify that keys are stored securely. |
Distinguish this from 3.6.1, which sets the design constraints: fewest possible custodians, a key-encrypting key at least as strong as the key it protects, and stored separately from the data. 3.7.3 is the procedure and the practice for those constraints, and procedure 3.7.3.b observes the method, so the assessor looks at where keys actually live. The usual finding is not that storage is bad in principle. It is that one copy of the key is protected properly and another copy is somewhere ordinary: a configuration file, a repository, a backup taken alongside the encrypted data, or a developer laptop from the last migration.
What to prepare
- An inventory of every location a key or key component exists, including copies.
- What protects each location, and how it satisfies the separation required by 3.6.1.
- The storage to observe, whether that is a key management service, an HSM, or a safe.
- Who can reach each location.
How to implement it
1. Hunt the second copy. The primary store is nearly always correct. Search configuration, source control history, build artefacts, container images, backups and ticket attachments for the same material.
2. Do not back up keys with the data they protect. A backup containing both is a single object that decrypts itself, which defeats the separation the section is built on.
3. Use a key management service or an HSM where you can. It answers storage, access control and much of the logging at once, and it gives you something concrete to observe.
4. Write down the physical arrangements too. Where components live in a safe or in tamper-evident envelopes, the procedure has to describe the safe, the access and the log, because that is what will be observed.
Where this commonly fails
- A second copy in a repository or a configuration file, long after the first copy was moved somewhere proper.
- Keys and encrypted data in the same backup set.
- A key management service used for new systems while a legacy application keeps its key in a properties file.
- Storage that is secure and unlogged, so nobody can say who reached it.
Related controls
Others in section 3.7:
| Control | What it requires |
|---|---|
| 3.7.1 | Key-management policies and procedures are implemented to include generation of strong… |
| 3.7.2 | Key-management policies and procedures are implemented to include secure distribution… |
| 3.7.4 | Key management policies and procedures are implemented for cryptographic key changes for keys… |
| 3.7.5 | Key management policies procedures are implemented to include the retirement, replacement… |
| 3.7.6 | Where manual cleartext cryptographic key-management operations are performed by personnel… |
| 3.7.7 | Key management policies and procedures are implemented to include the prevention… |
| 3.7.8 | Key management policies and procedures are implemented to include that cryptographic key… |
| 3.7.9 | Service providers: Where a service provider shares cryptographic keys with its customers for transmission… |
← 3.7.2 · All controls · 3.7.4 →
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.