PCI DSS 3.6.1.1 (service providers): A documented description of the cryptographic architecture is maintained
PCI DSS v4.0.1 control 3.6.1.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
Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:
- Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date.
- Preventing the use of the same cryptographic keys in production and test environments. This bullet is a best practice until its effective date; refer to Applicability Notes below for details.
- Description of the key usage for each key.
- Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, to support meeting Requirement 12.3.4.
Summary
Service providers only: maintain a written description of your cryptographic architecture, including what every key is for and where the devices are.
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.1 | Additional testing procedure for service provider assessments only: Interview responsible personnel and examine documentation to verify that a document exists to describe the cryptographic architecture that includes all elements specified in this requirement. |
Service providers only, and it is a document most entities have never produced. Four elements: all algorithms, protocols and keys protecting stored account data, with key strength and expiry date; preventing the use of the same cryptographic keys in production and test; a description of key usage for each key; and an inventory of HSMs, key management systems and other secure cryptographic devices, including type and location, explicitly to support 12.3.4. That last pointer is the reason to do this well rather than minimally: 12.3.4 is the annual review of cryptographic suites and protocols, and it cannot be performed against an architecture nobody has written down. The production-and-test bullet was published as future-dated and became mandatory on 31 March 2025 with the rest of the v4.x future-dated controls.
What to prepare
- The cryptographic architecture document itself, checked element by element.
- Key inventory with strength, expiry and purpose per key.
- Evidence that production and test keys are distinct.
- The HSM, KMS and SCD inventory with type and location.
How to implement it
1. Write it once and keep it with the key register. The same facts serve 3.6.1.2, 3.7.4 and 12.3.4, so one maintained document answers several controls.
2. Record expiry alongside strength. The cryptoperiod work in 3.7.4 needs the same dates, and having them in one place is what makes rotation plannable.
3. Check production and test key separation explicitly. Environments cloned from production frequently inherit its keys, which is exactly what the bullet prohibits.
4. List the devices with locations. It is a named element and it is what 12.3.4 reviews against.
Where this commonly fails
- No such document at all, since nothing else in the standard asks for one.
- Algorithms listed without key strength or expiry, meeting part of the first element.
- Test environments using production keys, inherited from a clone.
- HSM inventory omitted, leaving 12.3.4 with nothing to review.
Related controls
This control refers to 12.3.4.
Others in section 3.6:
| Control | What it requires |
|---|---|
| 3.6.1 | Procedures are defined and implemented to protect cryptographic keys used to protect stored… |
| 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.6.1 · All controls · 3.6.1.2 →
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.