Secret and private keys that protect stored account data must at all times exist in one or more of these forms: (1) wrapped by a key-encrypting key whose strength equals or exceeds that of the data-encrypting key, held apart from it; (2) inside a secure cryptographic device (SCD), for example an HSM or a point-of-interaction device with PTS approval; (3) split into at least two full-length components or shares using a method the industry accepts. Applicability: public keys need not be held in these forms; keys held in a KMS that uses SCDs are acceptable; merely splitting a key into two halves does not comply, and any key component or share has to be generated either by an approved random number generator inside an SCD OR in line with ISO 19592 or an equivalent standard for secret key share generation. Objective under the customized approach: secret and private keys are kept in a secure form that stops unauthorized retrieval or access.
This control maps to 26 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.
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.
PCI DSS 4.0 3.6.1.2 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.
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.
The graph holds this control, the 26 it maps to, and the evidence behind each claim, over MCP and REST.