PCI DSS 4.0
Req 3: Protect Stored Account Data

PCI DSS 4.0 3.7.4: 3.7.4 Key changes at end of cryptoperiod

Key-management policies and procedures must be in place to change each key when its cryptoperiod ends, as set by the relevant application vendor or key owner and informed by industry best practice and guidelines, including: (1) a defined cryptoperiod for every key type in use; and (2) a process for changing keys when that cryptoperiod ends. Guidance defines a cryptoperiod as the span during which a key may be used for its purpose, often expressed as active time and/or volume of ciphertext produced, and cites algorithm strength, key length, compromise risk and data sensitivity as factors, referring to Revision 5 of NIST SP 800-57 Part 1. Objective under the customized approach: keys are not used after their defined cryptoperiod.

Maintained by Gerard BlokdykControl text last updated

What else in your programme already covers this

This control maps to 16 controls across 14 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

C5 (Germany) · 2 controls

  • C5-CRY-01 Policy for the use of encryption procedures and key management
  • C5-CRY-04 Secure key management

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 2 controls

AWS Well-Architected Security Pillar · 1 control

Azure Security Benchmark · 1 control

CMMC 2.0 · 1 control

FedRAMP High · 1 control

  • SC-12 Cryptographic Key Establishment and Management

FedRAMP Moderate · 1 control

  • SC-12 Cryptographic Key Establishment and Management

ISO 27001:2022 · 1 control

  • 8.24 Use of cryptography

ISO 27002:2022 · 1 control

  • 8.24 Use of cryptography

ISO 27701:2019 · 1 control

  • 6.7.1 Cryptographic controls

NIS2 Directive · 1 control

  • Art.21.2.h Policies and procedures on the use of cryptography and, where appropriate, encryption

NIST SP 800-171 Rev 3 · 1 control

  • 03.13.10 Cryptographic Key Establishment and Management

NIST SP 800-53 Rev 5 · 1 control

  • NIST800-SC-12 SC-12 Cryptographic Key Establishment and Management

PCI 3DS Core Security Standard · 1 control

  • P2-6.1.5 P2-6.1.5 Keys managed securely through their whole lifecycle

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in Req 3: Protect Stored Account Data

You are reading one control. How much of PCI DSS 4.0 have you already done?

PCI DSS 4.0 3.7.4 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of PCI DSS 4.0 your existing evidence covers. Hold ISO 27001:2022 and 139 of 280 PCI DSS 4.0 controls already carry evidence.

If you hold ISO 27001:202249.6% covered · 141 gapsIf you hold FedRAMP Moderate49.3% covered · 142 gapsIf you hold NIST SP 800-53 Rev 547.5% covered · 147 gapsIf you hold ISO 27002:202243.2% covered · 159 gapsIf you hold CIS Controls v838.2% covered · 173 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.136.4% covered · 178 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 415 were rejected on the ISO 27001:2022 pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 16 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll PCI DSS 4.0 controls