PCI DSS 3.6.1: Procedures are defined and implemented to protect cryptographic keys used to protect stored
PCI DSS v4.0.1 control 3.6.1: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 3.6.
Requirement 3: Protect Stored Account Data › Section 3.6
Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:
- Access to keys is restricted to the fewest number of custodians necessary.
- Key-encrypting keys are at least as strong as the data-encrypting keys they protect.
- Key-encrypting keys are stored separately from data-encrypting keys.
- Keys are stored securely in the fewest possible locations and forms.
Summary
If you encrypt stored account data, protect the keys: few custodians, key-encrypting keys at least as strong, and stored apart from the data.
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.6.1 | Examine documented key-management policies and procedures to verify that processes to protect cryptographic keys used to protect stored account data against disclosure and misuse are defined to include all elements specified in this requirement. |
The obligation that follows from choosing encryption at 3.5.1 rather than truncation or tokenisation, and the reason that choice costs more. Its elements are specific: access restricted to the fewest custodians necessary, key-encrypting keys at least as strong as the keys they protect, and keys stored in the fewest possible locations. Section 3.7 then governs their whole lifecycle: generation, distribution, rotation, retirement, split knowledge. A key sitting in the same database as the data it protects, or in the application repository, is the usual finding.
What to prepare
- The key management procedures, covering each element of the requirement.
- The list of key custodians and evidence access is limited to them.
- Key strengths for both data-encrypting and key-encrypting keys.
- Where keys are stored, and evidence that is separate from the encrypted data.
How to implement it
1. Use a key management service or an HSM if you can. Custodianship, separation and rotation are properties you inherit rather than build, and the alternative is a set of procedures somebody has to follow perfectly.
2. Never store the key beside the data. A key in the same database, the same backup, or the application repository means one compromise yields both, which is the outcome encryption was meant to prevent.
3. Name the custodians. "The platform team" is not a list of the fewest necessary, and this requirement is about how few people can reach the keys.
4. Check the key-encrypting key. Protecting an AES-256 data key with a weaker wrapping key is a specific named failure and an easy one to make with defaults.
Where this commonly fails
- Keys stored in the same system as the ciphertext, so both are lost together.
- A key in source control or a container image, which spreads it everywhere the image goes.
- Custodian access granted broadly and never reviewed.
- Encryption chosen at 3.5.1 without anyone owning section 3.7 afterwards.
Related controls
Others in section 3.6:
| Control | What it requires |
|---|---|
| 3.6.1.1 | Service providers: A documented description of the cryptographic architecture is maintained… |
| 3.6.1.2 | Secret and private keys used to protect stored account data are stored in one (or more)… |
| 3.6.1.3 | Access to cleartext cryptographic key components is restricted to the fewest number… |
| 3.6.1.4 | Cryptographic keys are stored in the fewest possible locations |
← 3.5.1.3 · All controls · 3.6.1.1 →
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.