PCI DSS 3.7.5: Key management policies procedures are implemented to include the retirement, replacement
PCI DSS v4.0.1 control 3.7.5: 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 procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:
- The key has reached the end of its defined cryptoperiod.
- The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.
- The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations.
Summary
Retire, replace or destroy a key when its life ends, when someone who knew it leaves, or when it may have been compromised, and never encrypt with a retired key again.
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.5.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define retirement, replacement, or destruction of keys in accordance with all elements specified in this requirement. |
| 3.7.5.b | Interview personnel to verify that processes are implemented in accordance with all elements specified in this requirement. |
Three triggers and a fourth obligation that is easy to read past. "Retired or replaced keys are not used for encryption operations" is a separate requirement in its own sentence, and it captures a real distinction: a retired key often has to stay available to decrypt data already encrypted under it, while being barred from any new encryption. Retiring a key is therefore not the same as destroying it, and the two are separate outcomes the control allows. The second trigger is worth reading closely: the integrity of a key is weakened when personnel with knowledge of a cleartext key component leave the company or the role, which is the same shape as 2.3.2 for wireless keys and depends on knowing who those people were.
What to prepare
- The procedure, covering all three triggers and both outcomes, retirement and destruction.
- The register of who holds or has held each cleartext component, which the second trigger needs.
- Evidence of a key actually retired or destroyed, and what happened to the data under it.
- The control that stops a retired key being used for encryption, and how it is enforced.
How to implement it
1. Separate decrypt-only from destroyed. Mark retired keys decrypt-only in the key store where the platform supports it, so the last sentence of the requirement is enforced rather than promised.
2. Connect the leaver trigger to the custodian register. It only fires if you know who had knowledge of a component, which is the same register 3.7.8 needs for acknowledgements.
3. Define suspicion in advance. A component envelope found open, a custodian dismissed, a key appearing in a ticket. Deciding this before it happens keeps it from being argued about afterwards.
4. Re-encrypt on a plan, not on the incident. Knowing how long re-encryption takes is what makes the compromise trigger actionable rather than theoretical.
Where this commonly fails
- A retired key still configured as the active encryption key somewhere, which fails the final sentence.
- The leaver trigger unimplementable because nobody recorded which custodians held which component.
- Retirement and destruction treated as the same thing, so keys needed for decryption are destroyed and data is lost.
- A procedure covering the cryptoperiod trigger only, ignoring compromise and personnel change.
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.3 | Key-management policies and procedures are implemented to include secure storage… |
| 3.7.4 | Key management policies and procedures are implemented for cryptographic key changes for keys… |
| 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.4 · All controls · 3.7.6 →
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.