The organization is to define and apply rules for using cryptography effectively, key management included. Purpose: apply cryptography correctly and to good effect so information stays confidential, genuine or unaltered in line with business and security requirements and the legal, regulatory and contractual rules on cryptography. Guidance: consider a topic-specific cryptography policy setting general principles, needed to gain the benefits and avoid misuse; the protection level and classification of information, which determine the type, strength and quality of algorithms; encryption of information on mobile endpoints and storage media and in transit to them; the approach to key management, including generating and protecting keys and recovering encrypted information when keys are lost, compromised or damaged; roles for implementing the rules and for key management including generation; approved or mandatory standards, algorithms, cipher strengths, solutions and usage practices; and the effect of encryption on controls that inspect content, such as malware detection or content filtering. Take into account national regulations and restrictions on cryptography in different countries and cross-border flows of encrypted information (5.31), and make agreements with external cryptographic service providers such as certification authorities cover liability, service reliability and response times (5.22). Keys need secure handling across their whole life, from creation, storage, archiving, retrieval and distribution to retirement and destruction, based on agreed standards and procedures for: generating keys for different systems and applications; issuing and obtaining public key certificates; distributing keys to intended parties and activating them on receipt; storing keys and granting authorized access; changing or updating keys, with rules on when and how; handling compromised keys; revoking or deactivating keys, for instance on compromise or when a user leaves, archiving them in that case; recovering lost or corrupted keys; making backup or archive copies of keys; destruction of keys; logging and auditing key management; setting activation and deactivation dates so keys are used only within their permitted period; and handling legal demands for access to keys, such as producing decrypted evidence in court. All keys need protection from modification and loss, and secret and private keys also from unauthorized use and disclosure; equipment that generates, stores or archives keys is physically protected, and the authenticity of public keys often matters too. Other information: public key authenticity is usually handled through certificate authorities and certificates, or manually for small numbers of keys; cryptography supports confidentiality (encryption), integrity and authenticity (digital signatures, message authentication codes, file integrity checks), non-repudiation and authentication of users and entities; ISO/IEC 11770 covers key management.
This control maps to 187 controls across 42 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.
ISO 27002:2022 8.24 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of ISO 27002:2022 your existing evidence covers. Hold NIST SP 800-53 Rev 5 and 79 of 93 ISO 27002:2022 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. 180 were rejected on the NIST SP 800-53 Rev 5 pair alone.
The graph holds this control, the 187 it maps to, and the evidence behind each claim, over MCP and REST.