PCI DSS 3.7.8: Key management policies and procedures are implemented to include that cryptographic key
PCI DSS v4.0.1 control 3.7.8: 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 that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.
Summary
Every key custodian signs something saying they understand and accept what being a custodian means.
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.8.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define acknowledgments for key custodians in accordance with all elements specified in this requirement. |
| 3.7.8.b | Examine documentation or other evidence showing that key custodians have provided acknowledgments in accordance with all elements specified in this requirement. |
Procedure 3.7.8.b examines the acknowledgements themselves, so this control needs the artefacts, one per custodian, current. It rests on something the section leaves you to settle: who counts as a key custodian. 3.6.1 asks for the fewest possible, which implies a defined list, and this control cannot be evidenced without one. The acknowledgement is also the practical anchor for two other controls: the leaver trigger in 3.7.5 needs to know who held a component, and the dual control in 3.7.6 needs to know who the two people are.
What to prepare
- The custodian list, with the definition of custodian it was built from.
- A signed or electronically recorded acknowledgement per custodian, dated.
- What the acknowledgement says the responsibilities are, since accepting them requires stating them.
- The process that collects a new one when a custodian changes.
How to implement it
1. Define custodian before collecting anything. Anyone who can access a cleartext key or component is the usual line, and drawing it is what makes the list defensible.
2. Put the responsibilities in the acknowledgement. A signature against a document that does not say what is being accepted satisfies the form and not the requirement, which asks that they understand and accept them.
3. Refresh on change of custodian and on change of the responsibilities. Acknowledgements collected once at implementation are the common finding, since custodians move on and the file does not.
4. Keep it with the custodian list. 3.7.5 and 3.7.6 both need that list, and one register serving three controls is one register that stays current.
Where this commonly fails
- No definition of custodian, so the list is whoever came to mind and the acknowledgements are incomplete by construction.
- Acknowledgements from the original custodians and none from their replacements.
- A signature against a policy that never states the custodian responsibilities.
- Cloud key administrators excluded, because holding an IAM permission does not feel like holding a key.
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.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.9 | Service providers: Where a service provider shares cryptographic keys with its customers for transmission… |
← 3.7.7 · All controls · 3.7.9 →
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.