PCI DSS 3.7.6: Where manual cleartext cryptographic key-management operations are performed by personnel
PCI DSS v4.0.1 control 3.7.6: 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
Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented, including managing these operations using split knowledge and dual control.
Summary
If people handle cleartext keys by hand, no one person can do it alone.
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.6.a | Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define using split knowledge and dual control. |
| 3.7.6.b | Interview personnel and/or observe processes to verify that manual cleartext keys are managed with split knowledge and dual control. |
The control that applies only where manual cleartext key operations happen at all, and the strongest argument for arranging that they do not. Two mechanisms, and they are different: split knowledge means no individual knows the whole key, typically by holding components that must be combined; dual control means no individual can perform the operation alone, typically two people each authenticating. Both are required, and meeting one is a common partial failure. If keys are generated and held inside an HSM or key management service as 3.7.1 suggests, cleartext components never exist and this control has nothing to apply to.
What to prepare
- Whether manual cleartext key operations occur at all, stated plainly.
- The procedures for split knowledge and dual control where they do.
- Custodian assignments and evidence each acknowledges their responsibility.
- Records of key ceremonies, showing two parties present.
How to implement it
1. Try to make this control inapplicable. Keys that are generated, stored and used inside a hardware or managed boundary never appear in cleartext, so there is no manual operation to control.
2. Distinguish the two mechanisms in your procedure. Two people watching one person type a whole key is dual control without split knowledge, and it is the commonest half-measure.
3. Record the ceremony. Who was present, what was done, when. It is the only evidence that the procedure was followed rather than written.
4. Plan for absence. A scheme requiring two specific individuals fails when one leaves, and the recovery path is where split knowledge quietly collapses into one person holding everything.
Where this commonly fails
- Dual control implemented and split knowledge assumed, so one person still knows the full key.
- Key components stored together, which defeats the split.
- No ceremony records, leaving the procedure unevidenced.
- A custodian who has left, with their component recovered informally.
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.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.5 · All controls · 3.7.7 →
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.