ISO 27001 Annex A 8.24 Effective use of cryptography and key management
What it says
Rules for the effective use of cryptography, including cryptographic key management, shall be defined and implemented.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCreate and enforce rules for using cryptography and managing keys effectively.
This control is about setting up and following rules to properly use cryptography, which is a way to protect sensitive information by scrambling it. If done poorly, your private information could be exposed to hackers, leading to serious breaches of privacy and trust.
Free. Save your status, tasks and notes.
Why it matters
Poor cryptography and key management can expose sensitive data to attackers, leading to costly data breaches and loss of customer trust.
How to implement
The IT manager should develop a clear policy on how to use cryptography within the organisation.
This means creating a document that outlines why and when to use encryption, the types of encryption to be used, and how to manage encryption keys securely. Be sure to align this policy with ISO 27002:2022 and consider any legal requirements, such as the Privacy Act 1988.
The IT department should classify all information to determine its sensitivity and decide what level of encryption is needed.
This involves assessing each piece of data and categorising it based on how critical or confidential it is, then choosing the encryption strength accordingly.
IT staff should set up a secure system to generate, store, and manage encryption keys.
This could involve using a key management service, ensuring that keys are not lost or accessed by unauthorised people, and routinely rotating them for security.
Managers should assign clear roles and responsibilities regarding cryptography, ensuring everyone knows who is responsible for managing encryption keys and who is allowed to use encryption tools.
Training sessions can help people understand these roles and the importance of cryptographic security.
When using third-party cryptographic services, procurement teams should ensure contracts include terms about service reliability, liability, and compliance with Australian standards like CPS 234 and ASD Essential Eight.
This means carefully reviewing service agreements to ensure they meet security needs.
Keep it running
Audit key management; use approved current algorithms; protect keys (HSM/KMS); rotate and revoke keys; log and review crypto/key events.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The cryptography policy document. Check whether it details the types, strength, and circumstances for using cryptography and aligns with ISO 27002:2022.
Good evidence
Policy will comprehensively cover current and necessary practices.
- Check 2 of 5What an auditor asks for
Look at
Whether data has been assessed for sensitivity and the appropriate level of encryption assigned. Good documentation will clearly map out data categories and encryption requirements.
- Check 3 of 5What an auditor asks for
Ask for
To see records of key management activities.
Look at
Procedures for key generation, storage, and destruction and whether these are being followed consistently.
Good evidence
System will have detailed logs showing clearly managed processes.
- Check 4 of 5What an auditor asks for
Look at
Role assignments and whether training has been provided. Good practice will be roles that are well-defined and backed by training records.
- Check 5 of 5What an auditor asks for
Ask for
Contracts with third-party cryptographic services.
Look at
Terms related to service levels, liability, and compliance. Good contracts will include clear terms that align with relevant Australian regulations and standards.
Mappings
Closest match in ASD Information Security Manual: ISM-0507, Develop and maintain cryptographic key management processes, which asks for the same thing.
ASD Information Security Manual: 92 mappings
This control is equivalent to ISM-0507.
ISM-0507 requires cryptographic key management processes and supporting procedures to be developed, implemented and maintained across the organisation. ISO/IEC 27001:2022 Annex A 8.24 similarly requires organisations to define and implement rules for the effective use of cryptography, explicitly including cryptographic key management. Both controls cover establishing governance/processes for key lifecycle handling (e.g. generation, distribution, storage, rotation and revocation), with ISO framing it as rules for cryptography use and ISM framing it as mandatory processes/procedures.
This control is broader than ISM-0232.
ISM-0232 requires telephone systems used for sensitive or classified conversations to encrypt all traffic when it traverses external systems to prevent interception. ISO/IEC 27001:2022 Annex A 8.24 requires organisations to define and implement rules for the effective use of cryptography and cryptographic key management, which would include specifying encryption for communications such as voice/telephony over external networks. ISM-0232 is a specific use case (encrypted external telephony traffic), while Annex A 8.24 is broader and covers cryptography governance, selection and key management across many information flows.
This control is broader than ISM-0233.
ISM-0233 requires that cordless telephone handsets and headsets are not used for sensitive or classified conversations unless the communications are encrypted. Annex A 8.24 requires an organisation to define and implement rules for the effective use of cryptography, which includes selecting approved encryption methods and managing keys for encrypted voice solutions to meet ISM-0233. Annex A 8.24 is cryptography-governance focused, while ISM-0233 is a specific confidentiality-in-transit rule.
This control is broader than ISM-0457.
ISM-0457 mandates the use of cryptographic equipment, applications or libraries that have completed a Common Criteria evaluation against an ASD-endorsed Protection Profile for encrypting media with official, sensitive or protected data. Annex A 8.24 requires organisations to define and implement comprehensive cryptography rules, which often includes the selection of assured cryptographic solutions. ISM-0457 specifies a unique assurance-based requirement (Common Criteria + ASD-endorsed Protection Profile) not entirely covered by general governance under Annex A 8.24.
This control is broader than ISM-0459.
ISM-0459 requires implementing full disk encryption, or partial disk encryption where controls ensure data can only be written to the encrypted partition, to protect data at rest on storage media. This is a direct instance of cryptography use: disk/volume encryption is a concrete application of cryptographic controls and depends on appropriate key handling to prevent offline access to data if a device or drive is lost, stolen, or removed. Annex A 8.24 is broader because it requires the organisation to define and implement rules for cryptography and cryptographic key management across all relevant use cases (not only disks), whereas ISM-0459 focuses specifically on encryption-at-rest for disks/partitions and the write-to-encrypted-partition condition.
This control is broader than ISM-0460.
ISM-0460 requires that HACE is used when encrypting media that contains SECRET or TOP SECRET data. Annex A 8.24 requires organisations to define and implement rules for cryptography and cryptographic key management across the organisation. ISM-0460 is a specific mandated cryptographic approach for a particular classification and use case, whereas Annex A 8.24 is broader and covers governance, algorithm selection, and key lifecycle management beyond media encryption.
This control is broader than ISM-0465.
ISM-0465 requires the use of Common Criteria evaluated cryptographic equipment, applications or libraries (against an ASD-endorsed Protection Profile) to protect OFFICIAL: Sensitive or PROTECTED data when traversing insufficiently secure/public networks or outside secure areas. Annex A 8.24 requires the organisation to define and implement rules for the effective use of cryptography and cryptographic key management. ISM-0465 is a specific, assurance-focused instance of cryptography use (evaluated products for certain classifications and scenarios), whereas Annex A 8.24 is broader and does not require ASD/Common Criteria evaluation.
This control is broader than ISM-0467.
ISM-0467 mandates HACE for SECRET and TOP SECRET data in transit over insecure networks. Annex A 8.24 addresses overall cryptography and key management, which includes selecting encryption mechanisms like HACE. ISM-0467 is specific to a classification and context, whereas Annex A 8.24 has a broader cryptographic governance scope.
This control is broader than ISM-0471.
ISM-0471 requires that only AACAs or other high assurance cryptographic algorithms are used by cryptographic equipment, applications and libraries. This is a specific subset of Annex A 8.24, which requires organisations to define and implement rules for effective use of cryptography and cryptographic key management across the organisation. Annex A 8.24 covers broader governance (algorithm selection, key lifecycle, roles, usage rules), while ISM-0471 focuses narrowly on the assurance level of the algorithms permitted.
This control is broader than ISM-0472.
ISM-0472 requires that when Diffie-Hellman (DH) is used for session key agreement, the DH modulus is at least 2048 bits (preferably 3072 bits). Annex A 8.24 requires organisations to define and implement rules for cryptography and cryptographic key management, under which minimum parameter strengths (including DH modulus sizes) would typically be specified. Annex A 8.24 is broader because it covers cryptographic governance and key management across algorithms and use cases, while ISM-0472 is a specific technical parameter requirement for DH.
This control is broader than ISM-0474.
ISM-0474 requires organisations to use ECDH with a minimum 224-bit base point order/key size (preferably NIST P-384) when agreeing encryption session keys. Annex A 8.24 requires the organisation to define and implement rules for cryptography use and cryptographic key management, which would include specifying approved key agreement algorithms and parameter sizes. ISM-0474 is a prescriptive technical requirement for one cryptographic mechanism, while Annex A 8.24 is broader governance covering cryptography and key management across the organisation.
This control is broader than ISM-0475.
ISM-0475 requires organisations to use sufficiently strong ECDSA parameters for digital signatures (at least 224-bit order/key size, preferably P-384). This relates directly to Annex A 8.24, which requires rules for the effective use of cryptography and cryptographic key management across the organisation. ISM-0475 is a specific cryptographic standard for one use case (ECDSA signatures), whereas Annex A 8.24 is broader and covers cryptography policy, algorithm selection, key lifecycle management and governance.
This control is broader than ISM-0476.
ISM-0476 requires that RSA used for digital signatures and key transport uses a modulus of at least 2048 bits (preferably 3072 bits) to maintain cryptographic strength. Annex A 8.24 requires an organisation to define and implement rules for the effective use of cryptography and cryptographic key management, under which minimum RSA key sizes would be set as an approved standard. ISM-0476 is a specific technical parameter within the broader governance and standards expectation of Annex A 8.24.
This control is broader than ISM-0477.
Annex A 8.24 requires cryptographic rules and key management practices to be defined and implemented, including appropriate key use. ISM-0477 specifies a key separation rule for RSA (separate key pairs for signing vs key transport), which is a concrete cryptographic/key management rule that Annex A 8.24 would capture. ISM-0477 is narrowly focused on RSA key usage separation, while Annex A 8.24 covers all cryptographic mechanisms and broader key lifecycle controls.
This control is broader than ISM-0479.
ISM-0479 requires that symmetric cryptographic algorithms are not used in Electronic Codebook (ECB) mode. ISO/IEC 27001:2022 Annex A 8.24 requires organisations to define and implement rules for effective use of cryptography and cryptographic key management, which would typically include approved/forbidden modes of operation such as prohibiting ECB. Annex A 8.24 is broader (covering cryptographic governance and key management), while ISM-0479 is a specific technical rule about one unsafe cipher mode.
This control is broader than ISM-0481.
ISM-0481 requires that only approved high assurance cryptographic protocols (e.g. AACPs) are used by cryptographic equipment, applications and libraries. Annex A 8.24 requires an organisation to define and implement rules for effective cryptography use and cryptographic key management, within which specifying approved/strong protocols is a core rule. ISM-0481 is more prescriptive and protocol-specific, while Annex A 8.24 is broader and also covers key lifecycle governance beyond protocol selection.
This control is broader than ISM-0489.
ISM-0489 requires limiting the duration that an unlocked SSH private key can remain cached and using screen locks to reduce the risk of key misuse from unattended sessions. This relates to ISO/IEC 27001:2022 Annex A 8.24 because constraining SSH-agent key lifetime is a concrete cryptographic key management measure (controlling key exposure and effective key use). Annex A 8.24 is broader and covers governance, lifecycle, storage, rotation, and handling of cryptographic keys beyond SSH-agent caching timeouts.
This control is broader than ISM-0490.
ISM-0490 requires organisations to only use S/MIME version 3.0 or later, preventing weak/obsolete cryptographic message protection in email. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management, under which approved protocol versions and cryptographic standards for email protection would be defined. ISM-0490 is a concrete protocol-version requirement, while Annex A 8.24 is broader and also covers key management, algorithm choices, and cryptographic governance beyond email.
This control is broader than ISM-0496.
ISM-0496 requires the ESP protocol to be used to provide encryption and authentication for IPsec connections. Annex A 8.24 requires an organisation to define and implement rules for the effective use of cryptography and cryptographic key management across the environment. ISM-0496 is a specific technical instantiation of cryptography-in-transit within one protocol suite (IPsec/ESP), whereas Annex A 8.24 is broader and also covers algorithm choices, key lifecycles, and governance beyond IPsec.
This control is broader than ISM-0547.
ISM-0547 requires video conferencing and IP telephony calls to use a secure real-time transport protocol, which applies encryption and integrity protection to media streams. This is a specific cryptographic requirement that falls within the rules for effective use of cryptography required by Annex A 8.24. Annex A 8.24 also covers key management and cryptographic use across all information, whereas ISM-0547 applies only to real-time voice and video.
This control is broader than ISM-0571.
ISM-0571 requires emails to traverse authenticated and encrypted channels via centralised email gateways. ISO/IEC 27001:2022 Annex A 8.24 establishes rules for cryptography and key management, which underpins how email transport encryption (e.g. TLS) and any gateway-based encryption features are configured and managed. Annex A 8.24 does not mandate the use of centralised email gateways, but it strengthens ISM-0571 by ensuring encryption is correctly selected, implemented, and governed.
This control is broader than ISM-0572.
ISM-0572 requires the use of TLS for SMTP connections to provide encryption for email traffic traversing public networks. Annex A 8.24 requires rules for effective use of cryptography and key management to be defined and implemented, which governs how TLS is selected, configured (e.g. protocol/cipher choices) and how certificates/keys are managed. ISM-0572 is a single applied use-case of cryptography, while Annex A 8.24 covers cryptographic governance and key management across the organisation.
This control is broader than ISM-0869.
ISM-0869 involves encrypting storage on mobile devices, a specific application of cryptography. ISO/IEC 27001:2022 Annex A 8.24 prescribes creating organisational rules for cryptographic use, thus ISM-0869's specific requirement enhances adherence to broader cryptographic governance.
This control is broader than ISM-0994.
ISM-0994 requires organisations to use ECDH in preference to classical DH for secure key exchange. Annex A 8.24 requires rules for the effective use of cryptography, including cryptographic key management, to be defined and implemented, which would typically include approved key exchange mechanisms for protocols such as TLS and IPsec. ISM-0994 is a specific algorithm/method selection within the broader cryptography governance and key management expectations of Annex A 8.24.
This control is broader than ISM-0998.
ISM-0998 mandates approved integrity/authentication algorithms for IPsec connections, with a preference for using NONE when AES-GCM provides integrated authentication, to meet cryptographic integrity requirements in transit. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, which would typically include specifying permitted VPN/IPsec algorithms and modes. ISM-0998 is a concrete algorithm-selection rule for a specific protocol, while Annex A 8.24 is a broader governance and implementation control covering cryptography across the organisation.
This control is broader than ISM-0999.
ISM-0999 requires organisations to use DH or ECDH for IPsec key establishment, with a preference for specific strong parameter groups (e.g. 384-bit random ECP, 3072/4096-bit MODP). This maps to ISO/IEC 27001:2022 Annex A 8.24 because that control requires rules for the effective use of cryptography and cryptographic key management, which includes specifying approved key establishment mechanisms and parameter strengths for VPNs such as IPsec. Annex A 8.24 is broader (covering cryptography and key management across the organisation), while ISM-0999 is a specific, technical requirement for IPsec key exchange configuration.
This control is broader than ISM-1000.
ISM-1000 requires the use of PFS for IPsec connections to limit the impact of key compromise across sessions. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, under which requiring PFS for VPNs/IPsec is a concrete key-management/crypto-policy rule. ISM-1000 is a specific implementation detail (PFS on IPsec), whereas Annex A 8.24 covers cryptography and key management across all relevant use cases, algorithms, and lifecycle practices.
This control is broader than ISM-1085.
ISM-1085 requires mobile devices to encrypt sensitive or classified data when communicating over public network infrastructure. Annex A 8.24 establishes organisation-wide rules for the effective use of cryptography and key management, under which requirements such as mandating TLS, VPN encryption, certificate use, and approved ciphers for mobile communications would be defined. ISM-1085 is a specific use-case within the broader cryptography and key management governance of Annex A 8.24.
This control is broader than ISM-1091.
Annex A 8.24 requires rules for cryptographic key management to be defined and implemented, including responding to key compromise. ISM-1091 specifically requires changing keying material when compromised or suspected of compromise, which is a direct key lifecycle requirement that would be included in Annex A 8.24 key management rules. ISM-1091 covers one event-driven key management action, while Annex A 8.24 covers the broader set of key management practices.
This control is broader than ISM-1139.
ISM-1139 requires organisations to only use the latest version of TLS for TLS connections to protect confidentiality and integrity in transit. Annex A 8.24 requires rules for the effective use of cryptography and key management to be defined and implemented, which would include approved protocols and configurations such as modern TLS versions. ISM-1139 is a specific, prescriptive cryptographic configuration requirement, while Annex A 8.24 is broader and also covers cryptographic policy, algorithm selection, and key lifecycle management beyond TLS.
This control is broader than ISM-1233.
ISM-1233 mandates the use of IKE version 2 for IPsec key exchanges. Annex A 8.24 requires organisations to implement cryptography and cryptographic key management rules, which encompass selecting secure protocols such as IKEv2 for key establishment. ISM-1233 is a specific technical implementation under the broader guidance of Annex A 8.24.
This control is broader than ISM-1277.
ISM-1277 requires encryption of data in transit specifically between web servers and database servers. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management across the organisation, which directly underpins implementing and sustaining TLS/mTLS (including certificate lifecycle) for web-to-database communications. ISM-1277 is one concrete application of cryptography-in-transit, whereas Annex A 8.24 also covers broader cryptographic use cases and key management beyond this single link.
This control is broader than ISM-1324.
ISM-1324 requires that X.509 certificates are generated using an evaluated certificate authority (CA) product or a hardware security module (HSM). Annex A 8.24 requires the organisation to define and implement rules for effective cryptography use and cryptographic key management, which includes how keys and certificate issuance should be managed and protected. ISM-1324 is a specific, higher-assurance implementation constraint within the broader cryptography/key-management governance expected by Annex A 8.24.
This control is broader than ISM-1327.
ISM-1327 requires encryption protections for X.509 certificates and private keys and controls over their use, particularly for human users. Annex A 8.24 requires defining and implementing rules for effective cryptography use and cryptographic key management, which includes how private keys are generated, stored (e.g., HSM/TPM), backed up, rotated and revoked. ISM-1327 is narrower as it applies cryptography and key-protection expectations specifically to X.509 certificate material rather than all cryptographic keying material.
This control is broader than ISM-1332.
ISM-1332 requires a specific cryptographic protection for wireless communications by mandating WPA3-Enterprise 192-bit mode. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management across the organisation, which would include selecting and managing cryptography for wireless protections. ISM-1332 is a specific prescriptive requirement for one channel (wireless traffic), whereas Annex A 8.24 is broader and covers governance, selection, and key lifecycle management across many use-cases.
This control is broader than ISM-1369.
ISM-1369 requires AES-GCM to be used for encryption of TLS connections, a specific approved cipher mode requirement. It is a concrete instance of the rules for the effective use of cryptography that Annex A 8.24 requires to be defined and implemented, since those rules should specify the approved algorithms and modes for protocols such as TLS. Annex A 8.24 is much broader, covering all cryptographic use and key management, whereas ISM-1369 addresses only the TLS encryption algorithm.
This control is broader than ISM-1370.
ISM-1370 requires TLS connections to permit only server-initiated secure renegotiation, reducing exposure to renegotiation-related weaknesses. Annex A 8.24 requires rules for effective use of cryptography and key management, which would typically include specifying acceptable TLS protocol behaviours and secure configuration standards. ISM-1370 is a specific technical cryptographic configuration requirement, while Annex A 8.24 is broader and policy/standard-driven across cryptography and key management beyond TLS renegotiation.
This control is broader than ISM-1372.
ISM-1372 requires TLS connections to use ephemeral DH or ECDH for key establishment to provide forward secrecy. This maps to Annex A 8.24 because selecting and enforcing appropriate cryptographic mechanisms and managing their use (including protocol and key-exchange choices) is part of effective cryptography governance. Annex A 8.24 is broader and policy/programmatic, while ISM-1372 is a specific technical requirement for TLS key exchange.
This control is broader than ISM-1373.
ISM-1373 requires that TLS connections are configured so Anonymous Diffie-Hellman (ADH) cipher suites are not used. Annex A 8.24 requires the organisation to define and implement rules for the effective use of cryptography and key management, which would include approved TLS configurations and prohibitions on weak/unauthenticated key exchange. ISM-1373 is a specific technical prohibition within TLS, whereas Annex A 8.24 is a broader cryptography governance and control requirement.
This control is broader than ISM-1374.
ISM-1374 requires that SHA-2-based certificates are used for TLS connections to protect data in transit from eavesdropping. ISO/IEC 27001:2022 Annex A 8.24 requires the organisation to define and implement rules for cryptography and cryptographic key management, which includes selecting approved algorithms and managing certificate/key lifecycles. ISM-1374 is a specific, prescriptive cryptographic requirement (SHA-2 for TLS certificates) within the broader cryptography governance and key management expectations of Annex A 8.24.
This control is broader than ISM-1375.
ISM-1375 requires organisations to use SHA-2 for the HMAC and PRF in TLS connections to ensure strong cryptographic protection for secure communications. This relates directly to Annex A 8.24, which requires rules for the effective use of cryptography and cryptographic key management across the organisation. ISM-1375 is a specific cryptographic standard/parameter requirement within TLS, whereas Annex A 8.24 is broader and also covers governance and key management beyond TLS hashing choices.
This control is broader than ISM-1446.
ISM-1446 mandates the use of elliptic curves from NIST SP 800-186 for encryption, focusing on selecting specific cryptographic parameters. Annex A 8.24 broadly requires defining and implementing cryptography and key management rules, which can encompass these specific requirements. Therefore, ISM-1446 is a narrower implementation detail within the cryptographic governance of Annex A 8.24.
This control is broader than ISM-1449.
Annex A 8.24 requires rules for cryptography and key management, including secure handling and protection of cryptographic keys. ISM-1449 sets a specific rule that SSH private keys must be protected with a password or key encryption key, directly aligning to key protection requirements under Annex A 8.24. ISM-1449 is limited to one key type and control, while Annex A 8.24 covers the full organisational cryptography and key management framework.
This control is broader than ISM-1453.
ISM-1453 requires Perfect Forward Secrecy (PFS) to be used for TLS connections so past sessions remain protected even if a server private key is later compromised. Annex A 8.24 requires organisations to define and implement rules for effective use of cryptography and cryptographic key management, which includes selecting appropriate TLS configurations and key exchange methods. ISM-1453 is a specific technical cryptographic requirement (PFS for TLS), whereas Annex A 8.24 is broader and covers cryptography governance and key management across many use cases.
This control is broader than ISM-1454.
ISM-1454 requires encrypting RADIUS communications using RADIUS over TLS or RADIUS over IPsec to protect authentication/authorisation traffic in transit. This is a specific application of ISO/IEC 27001:2022 Annex A 8.24, which requires organisations to define and implement rules for effective use of cryptography and associated key management. Annex A 8.24 covers cryptography use across many contexts (data at rest/in transit, algorithms, key lifecycle), whereas ISM-1454 is limited to one protocol pathway and transport protection approach.
This control is broader than ISM-1629.
ISM-1629 requires that when Diffie-Hellman (DH) is used to agree encryption session keys, the modulus and associated parameters are selected in accordance with NIST SP 800-56A Rev. 3. Annex A 8.24 requires an organisation to define and implement rules for effective cryptography use and cryptographic key management, which would include setting approved DH parameter standards. Annex A 8.24 is broader and policy/governance-focused across all cryptography and key management, while ISM-1629 is a specific technical parameter-selection requirement for DH.
This control is broader than ISM-1712.
ISM-1712 requires organisations to disable 802.11r Fast Transition unless authenticator-to-authenticator communications are secured using an ASD-Approved Cryptographic Protocol. Annex A 8.24 requires the organisation to define and implement rules for effective use of cryptography and cryptographic key management. ISM-1712 is a specific wireless/roaming implementation of cryptographic protection expectations that Annex A 8.24 addresses more broadly across the organisation.
This control is broader than ISM-1759.
ISM-1759 requires that when Diffie-Hellman is used to agree encryption session keys, a modulus of at least 3072 bits is used. This relates directly to Annex A 8.24 because it is a concrete cryptographic-rule requirement that would sit within an organisation's broader cryptography and key management rules. Annex A 8.24 is wider in scope (covering selection, use and lifecycle management of cryptography and keys), whereas ISM-1759 is a specific parameter constraint for one key agreement method.
This control is broader than ISM-1761.
ISM-1761 requires that when ECDH is used to agree encryption session keys, organisations use specific NIST curves (P-256, P-384 or P-521), preferably P-384. Annex A 8.24 requires organisations to define and implement rules for the effective use of cryptography, including cryptographic key management. ISM-1761 is a specific, prescriptive cryptographic standard (algorithm parameter/curve selection for key agreement) that would typically be one of the rules implemented under the broader cryptography and key management governance required by Annex A 8.24.
This control is broader than ISM-1762.
ISM-1762 requires that when ECDH is used to agree encryption session keys, organisations should use NIST P-384 (preferred) or P-521 curves. Annex A 8.24 mandates organisations to define and implement rules for effective cryptography use and cryptographic key management. Selecting approved elliptic curves for key agreement is a specific aspect within the broader cryptography governance of Annex A 8.24. Therefore, ISM-1762 is a specific technical parameter choice within Annex A 8.24's expectations.
This control is broader than ISM-1763.
ISM-1763 requires that when an organisation uses ECDSA for digital signatures it uses approved NIST curves (preferably P-384). This relates directly to Annex A 8.24, which requires organisations to define and implement rules for effective cryptography use and cryptographic key management, under which approved algorithm/parameter standards (like P-384 for ECDSA) are typically specified. Annex A 8.24 is broader because it covers cryptography and key management generally, not just curve selection for ECDSA signatures.
This control is broader than ISM-1764.
Annex A 8.24 requires organisations to set and enforce rules for cryptography use and key management. ISM-1764 provides a specific standard for ECDSA digital signatures by requiring stronger curves (preferably NIST P-384), which is one type of cryptographic rule that can be mandated under Annex A 8.24. ISM-1764 does not address the broader key governance and management processes that Annex A 8.24 expects.
This control is broader than ISM-1765.
ISM-1765 requires that when RSA is used for digital signatures and for transporting encryption session keys, organisations use an RSA modulus of at least 3072 bits. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, which would typically include approved algorithms and minimum key sizes. ISM-1765 is a specific, prescriptive cryptographic parameter requirement, while Annex A 8.24 is broader and covers governance and lifecycle management beyond RSA key length.
This control is broader than ISM-1766.
ISM-1766 requires organisations to use SHA-2 hashing with an output size of at least 224 bits (preferably SHA-384 or SHA-512) to ensure secure hashing. This relates directly to ISO/IEC 27001:2022 Annex A 8.24, which requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, within which approved hash algorithms and minimum strengths would normally be specified. Annex A 8.24 is broader because it covers cryptography governance across many use cases (e.g., encryption, signatures, key management), while ISM-1766 is a specific technical requirement about SHA-2 hash strength.
This control is broader than ISM-1767.
ISM-1767 requires that when SHA-2 is used for hashing, organisations use an output size of at least 256 bits (preferably SHA-384 or SHA-512). ISO/IEC 27001:2022 Annex A 8.24 requires rules for the effective use of cryptography and cryptographic key management to be defined and implemented, which would include selecting approved hash algorithms and parameters such as SHA-2 output length. ISM-1767 is a specific cryptographic parameter requirement, whereas Annex A 8.24 is broader and covers cryptography governance and key management beyond hashing.
This control is broader than ISM-1768.
ISM-1768 requires that when SHA-2 is used for hashing, the organisation selects an output size of at least 384 bits (preferably SHA-384 or SHA-512). This relates directly to Annex A 8.24 because defining cryptographic rules and key management includes specifying approved algorithms and parameter choices (such as hash output size) for organisational use. Annex A 8.24 is broader, covering cryptography governance, selection, and key management beyond hashing specifics, whereas ISM-1768 is a precise technical requirement for SHA-2 hashing strength.
This control is broader than ISM-1769.
Annex A 8.24 requires defined and implemented rules for cryptography and cryptographic key management across the organisation. ISM-1769 provides a specific rule for encryption strength by mandating acceptable AES key lengths (preferably AES-256), which fits within the cryptography rules required by Annex A 8.24. ISM-1769 does not address wider key management governance and processes that Annex A 8.24 expects.
This control is broader than ISM-1770.
ISM-1770 requires that when AES is used for encryption, organisations select strong variants (AES-192 or preferably AES-256). This relates directly to Annex A 8.24, which requires defined rules for the effective use of cryptography and cryptographic key management, under which selecting approved algorithms and key sizes (including AES-256) would be specified. Annex A 8.24 is broader because it covers cryptography governance and key management across multiple algorithms and use cases, not just AES strength selection.
This control is broader than ISM-1771.
ISM-1771 requires AES to be used for encrypting IPsec connections, preferably using ENCR_AES_GCM_16. Annex A 8.24 requires an organisation to define and implement rules for effective use of cryptography and cryptographic key management, under which selecting approved algorithms and modes for VPN/IPsec is a typical requirement. ISM-1771 is a specific, technology-prescriptive instantiation of the broader cryptography governance and key management expectations in Annex A 8.24.
This control is broader than ISM-1772.
ISM-1772 mandates the use of approved, strong PRFs for IPsec connections (PRF_HMAC_SHA2_256/384/512) to ensure robust cryptographic operation during key derivation and related integrity protections. Annex A 8.24 requires the organisation to define and implement rules for the effective use of cryptography and cryptographic key management, under which selecting strong algorithms/parameters for protocols like IPsec is a common requirement. ISM-1772 is a specific algorithm-parameter rule for one protocol, whereas Annex A 8.24 spans cryptographic policy, algorithm selection, and key management across the organisation.
This control is broader than ISM-1802.
ISM-1802 requires organisations to use ASD-approved High Assurance Cryptographic Equipment (HACE) and operate it in accordance with the applicable Australian Communications Security Instructions (ACSI). This relates directly to Annex A 8.24 because operating HACE necessarily involves defining and implementing cryptographic rules and strong key management practices. Annex A 8.24 is broader as it applies to all organisational cryptography and key management, whereas ISM-1802 is a specific high-assurance, ASD-approved equipment requirement with mandated operational instructions.
This control is broader than ISM-1945.
ISM-1945 requires the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag to be removed from certificate templates so that requesters cannot specify arbitrary subjects in issued certificates. This hardens certificate issuance, which forms part of the cryptographic key management (including the issuing of public key certificates) that Annex A 8.24 requires rules for. Annex A 8.24 covers cryptography and key management as a whole, while ISM-1945 is a single certificate template configuration requirement.
This control is broader than ISM-1957.
Annex A 8.24 requires organisations to implement effective key management rules, including protection of private keys. ISM-1957 mandates protecting Microsoft AD CS CA private keys using a hardware security module, which is a specific key protection mechanism supporting Annex A 8.24's key management requirement. Annex A 8.24 is broader and technology-agnostic, extending beyond CA keys to all cryptographic keys and related management activities.
This control is broader than ISM-1984.
ISM-1984 requires a specific cryptographic use case: encrypt event log traffic while it is in transit to a centralised logging facility. This is a subset of ISO/IEC 27001:2022 Annex A 8.24, which requires the organisation to define and implement rules for cryptography and cryptographic key management across applicable scenarios, including data-in-transit protections. Annex A 8.24 is broader because it covers governance aspects such as algorithm choices, key lifecycle, roles and exceptions beyond the single scenario in ISM-1984.
This control is broader than ISM-1990.
ISM-1990 requires that when implementing ML-DSA and ML-KEM, organisations should also follow the pre-requisite FIPS publications referenced by FIPS 204 and FIPS 203 to ensure correct and secure use of these algorithms. This relates directly to Annex A 8.24, which requires organisations to define and implement rules for cryptography and cryptographic key management, including selecting and using appropriate standards and guidance. Annex A 8.24 is broader (covering all cryptographic use and key management), while ISM-1990 is a specific standards-adherence requirement focused on particular post-quantum algorithms and their prerequisite guidance.
This control is broader than ISM-1991.
ISM-1991 requires organisations that use ML-DSA for digital signatures to select specific approved parameter sets (ML-DSA-65 or ML-DSA-87, preferably ML-DSA-87). This is a concrete instance of Annex A 8.24, which requires organisations to define and implement rules for the effective use of cryptography and cryptographic key management, including selecting approved algorithms/parameters for given use cases (such as digital signatures). Annex A 8.24 is broader because it covers all cryptographic applications and associated key lifecycle management, whereas ISM-1991 is a specific algorithm/parameter selection rule for one cryptographic use case.
This control is broader than ISM-1992.
ISM-1992 requires that when ML-DSA is used for digital signatures, organisations use the hedged variant wherever possible to reduce cryptographic risk. This maps to Annex A 8.24 because it is a specific rule for the effective use of cryptography (choice of safer signature mode) within a broader cryptography and key-management policy framework. Annex A 8.24 covers many additional topics (e.g. algorithm selection principles, key lifecycle management, governance), while ISM-1992 is narrowly focused on one post-quantum signature scheme configuration.
This control is broader than ISM-1993.
ISM-1993 requires that pre-hashed ML-DSA-65/87 variants are only used when the performance of the default ML-DSA variants is unacceptable. This relates to Annex A 8.24 because it is a specific rule governing the effective use of cryptography (algorithm/variant selection) within an organisation's cryptographic standards and key management regime. Annex A 8.24 is broader, covering cryptography governance and key management across many algorithms and use cases, whereas ISM-1993 is narrowly focused on when an alternate ML-DSA signing mode is permitted.
This control is broader than ISM-1994.
ISM-1994 requires organisations to use specific minimum-strength hash functions (SHA-384 for ML-DSA-65 pre-hash and SHA-512 for ML-DSA-87 pre-hash) when using pre-hashed ML-DSA digital signature variants. This relates directly to Annex A 8.24 because it is a concrete rule for the effective use of cryptography (algorithm/parameter selection) within cryptographic controls. Annex A 8.24 is broader, covering cryptographic policy, correct use of cryptographic techniques, and key management beyond this single hashing requirement.
This control is broader than ISM-1995.
Annex A 8.24 requires organisations to define and implement rules for effective cryptography use and cryptographic key management. ISM-1995 specifies an approved post-quantum key encapsulation mechanism (ML-KEM-768/1024) for encapsulating session keys, which is one concrete cryptographic rule an organisation may mandate under Annex A 8.24. ISM-1995 is algorithm-specific, while Annex A 8.24 also covers broader key lifecycle requirements (generation, storage, rotation, revocation, recovery and governance).
This control is broader than ISM-1996.
ISM-1996 requires that when using a post-quantum/traditional hybrid encryption scheme, at least one of the component algorithms is an AACA (quantum-safe assurance). Annex A 8.24 requires organisations to define and implement rules for cryptography use and cryptographic key management, under which algorithm selection/approval and hybrid scheme rules would be governed. Annex A 8.24 is broader because it covers cryptography and key management generally (e.g. key lifecycle, roles, key protection), while ISM-1996 is a specific constraint on algorithm approval within hybrid encryption.
This control is broader than ISM-2010.
ISM-2010 requires that Active Directory service accounts with SPNs use strong encryption (specifically AES) for Kerberos/service authentication. This relates to Annex A 8.24 because it is a concrete application of cryptography rules and key/algorithm use for protecting authentication exchanges. Annex A 8.24 is broader, covering organisation-wide cryptographic policy and key management beyond AD SPNs, whereas ISM-2010 is a specific technical requirement for AD service accounts.
This control is broader than ISM-2017.
ISM-2017 requires organisations to encrypt DNS traffic where supported, typically via cryptographic protections at the transport or application layer. Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management, which underpins the selection, configuration and governance of encrypted DNS mechanisms. Annex A 8.24 is broader because it applies to all cryptographic use cases, whereas ISM-2017 applies cryptography specifically to DNS traffic.
This control is broader than ISM-2050.
ISM-2050 requires software to validate digital signatures using certificate trust chains and revocation checking (CRL/OCSP). This is a specific cryptographic assurance mechanism that fits within Annex A 8.24's broader requirement to define and implement effective use of cryptography and cryptographic key management. Annex A 8.24 covers wider governance and lifecycle topics (algorithms, key generation, storage, rotation and revocation processes), while ISM-2050 focuses on runtime signature certificate validation.
This control is broader than ISM-2073.
ISM-2073 requires an organisation to develop, implement and maintain a post-quantum cryptography (PQC) transition plan to manage quantum-driven cryptographic obsolescence. ISO/IEC 27001:2022 Annex A 8.24 supports this by requiring defined and implemented rules for cryptography and cryptographic key management, which are foundational inputs to planning and executing a PQC migration (e.g., algorithm and key-length standards, certificate/key lifecycle, and crypto governance). Annex A 8.24 is not PQC-specific and does not require a transition roadmap or quantum risk-driven prioritisation, which are central to ISM-2073.
This control is broader than ISM-2082.
ISM-2082 requires using a cryptographic bill of materials (CBOM) for imported third-party components during software development to verify support for standardised ASD‑Approved Cryptographic Algorithms. ISO/IEC 27001:2022 Annex A 8.24 requires the organisation to define and implement rules for effective cryptography use and cryptographic key management, which would include algorithm standards and acceptable implementations. ISM-2082 is a specific supply-chain/development verification mechanism that can be used to satisfy part of Annex A 8.24, but Annex A 8.24 also covers broader cryptographic governance and key lifecycle controls beyond CBOM use.
This control is broader than ISM-2108.
ISM-2108 requires mobile applications to encrypt all sensitive or classified data sent over public networks using ASD-approved cryptography. ISO/IEC 27001:2022 Annex A 8.24 requires the organisation to define and implement rules for cryptography use and cryptographic key management, which would govern choices such as approved algorithms and key handling for mobile app communications. ISM-2108 is a specific application of cryptography requirements (mobile apps, data-in-transit over public networks, ASD-approved), whereas Annex A 8.24 is broader and policy/management-system oriented across the organisation.
This control is broader than ISM-2163.
ISM-2163 mandates specific cryptographic selections for MACsec confidentiality mode (GCM-AES-128/256 and XPN variants), effectively defining an approved cipher-suite requirement for link encryption. ISO/IEC 27001:2022 Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, under which approved algorithms and key-handling for MACsec would be governed. Annex A 8.24 covers broader cryptographic policy and key lifecycle management, whereas ISM-2163 focuses on one concrete cryptographic control choice for a particular technology.
This control is broader than ISM-2164.
ISM-2164 requires a MACsec connectivity association to expire and re-key in less than 24 hours, which is a specific key/association lifetime rule. ISO/IEC 27001:2022 Annex A 8.24 mandates rules for effective cryptography use and cryptographic key management, where defining rotation or re-key intervals is typical. Annex A 8.24 applies across cryptographic technologies and keys generally, while ISM-2164 is specific to MACsec connectivity association lifetimes.
This control is broader than ISM-2166.
ISM-2166 requires regular MACsec secure association rekeying (under four hours), directly limiting cryptographic key lifetime for MACsec session keys. Annex A 8.24 requires defining and implementing cryptography and key management rules, which commonly include maximum key/session lifetimes and rekeying processes for cryptographic protections. ISM-2166 is an implementation-level requirement for MACsec specifically, whereas Annex A 8.24 covers key management across all cryptographic uses in the organisation.
This control partially overlaps ISM-0142.
Annex A 8.24 requires rules for cryptography use and key management, including handling events that may impact key/material confidentiality and integrity. ISM-0142 overlaps by mandating prompt reporting of compromise or suspected compromise of cryptographic equipment or associated keying material, which is a key-management incident handling requirement. ISM-0142 is focused on escalation/reporting, whereas Annex A 8.24 is broader and should also cover preventive controls, lifecycle management and governance of cryptographic use.
This control partially overlaps ISM-0455.
Annex A 8.24 requires rules for cryptographic use and cryptographic key management, including availability considerations for keys and encrypted information. ISM-0455 overlaps by requiring a means of data recovery when encryption keys are unavailable, which is a key management and operational resiliency consideration that should be addressed in Annex A 8.24 key management rules. ISM-0455 focuses specifically on recovery mechanisms, while Annex A 8.24 also covers broader topics such as algorithm selection, key protection, rotation and revocation.
This control partially overlaps ISM-0469.
ISM-0469 requires the use of ASD-Approved Cryptographic Protocols (or high assurance cryptographic protocols) to protect data communicated over network infrastructure. This overlaps with Annex A 8.24 because implementing cryptography effectively in practice for communications typically involves governance of algorithm/protocol choices and key management to ensure confidentiality and integrity. Annex A 8.24 is broader and includes cryptography for other purposes (e.g., data-at-rest, digital signatures) and explicit key lifecycle management, while ISM-0469 is specifically focused on data-in-transit protocol use.
This control partially overlaps ISM-0702.
Annex A 8.24 requires defined and implemented rules for cryptography and cryptographic key management across their lifecycle, including secure destruction/zeroisation where applicable. ISM-0702 overlaps by requiring use of cryptographic zeroise/sanitise functions for keys on SECRET/TOP SECRET mobile devices during emergency sanitisation. ISM-0702 is a specialised scenario for mobile device emergency procedures, while Annex A 8.24 applies to all systems and broader key lifecycle rules.
This control partially overlaps ISM-1080.
ISM-1080 requires that when encrypting media (data at rest), organisations use an ASD-Approved Cryptographic Algorithm (AACA) or other high assurance cryptographic algorithm. This overlaps with ISO/IEC 27001:2022 Annex A 8.24, which requires rules for effective use of cryptography and cryptographic key management to be defined and implemented, providing the governance and key-handling practices needed to implement approved encryption correctly. Annex A 8.24 is broader (covers cryptography use generally, including key management and potentially data in transit), while ISM-1080 is more specific about approved algorithms for encryption of stored media.
This control partially overlaps ISM-1917.
Annex A 8.24 requires organisations to define and implement rules for the effective use of cryptography and for cryptographic key management. ISM-1917 overlaps by requiring procurement and development to ensure future support for specific post-quantum and strong algorithms (e.g., ML-DSA-87, ML-KEM-1024, SHA-384/512, AES-256), which is part of defining cryptographic standards under Annex A 8.24. ISM-1917 focuses on capability uplift and roadmap/timelines, whereas Annex A 8.24 also requires operational key management rules and processes beyond algorithm support.
This control partially overlaps ISM-2109.
ISM-2109 requires pre-boot authentication or managed network-based key release as part of unlocking encrypted system volumes. Annex A 8.24 involves rules for cryptographic key management, crucial for managing full-disk encryption keys and protectors. The mapping is justified as ISM-2109 is a specific implementation aspect of the broader cryptography management covered by Annex A 8.24.
This control supports ISM-0554.
ISM-0554 requires video call authentication to use encrypted, non-replayable two-way authentication, which relies on strong cryptographic mechanisms to protect the handshake and prevent replay. ISO/IEC 27001:2022 Annex A 8.24 establishes rules for effective cryptography and cryptographic key management that underpin how such authentication encryption and integrity protections are implemented. Annex A 8.24 is about cryptographic governance and key handling, whereas ISM-0554 is about applying cryptography to a specific mutual authentication scenario for video calls.
This control supports ISM-0675.
ISM-0675 requires exported data from SECRET and TOP SECRET systems to be digitally signed by a trustworthy source, which relies on correct cryptographic implementation and key handling. Annex A 8.24 establishes rules for effective cryptography use and cryptographic key management, which underpins the trustworthiness, protection, issuance and verification of signing keys and certificates used for export signing. Without the cryptography and key management practices in Annex A 8.24, signatures required by ISM-0675 can be undermined through weak algorithms, compromised keys or poor certificate management.
This control supports ISM-1059.
ISM-1059 requires encryption for all data on media, implying the need for effective cryptographic key management. Annex A 8.24 establishes guidelines for cryptography and key management, critical for ensuring strong and reliable encryption practices. Without Annex A 8.24, the encryption required by ISM-1059 may not be consistently or effectively implemented.
This control supports ISM-1796.
ISM-1796 requires digitally signing executable content using a certificate with a verifiable chain of trust, which inherently relies on sound cryptographic key handling. ISO/IEC 27001:2022 Annex A 8.24 requires rules for effective use of cryptography and cryptographic key management to be defined and implemented. ISM-1796 is dependent on Annex A 8.24 because code-signing certificates and private keys must be generated, protected, rotated, and revoked appropriately for the signing and trust-chain verification to remain credible.
This control supports ISM-1928.
ISM-1928 requires backups of AD DS/AD CS/AD FS/Entra Connect servers to be encrypted using ASD-approved cryptography and stored securely with tightly restricted access. ISO/IEC 27001:2022 Annex A 8.24 establishes the organisational rules for effective cryptography and cryptographic key management that are needed to implement ISM-1928's encryption requirement correctly. ISM-1928 is a specific application for particular backup types and access conditions, while Annex A 8.24 is a broader governance control for cryptography across the organisation.
ASD Essentials for enterprise IT: 2 mappings
- IT.PRO-13.2Store keys, secrets and tokens in approved, access-controlled repositories with MFAPartially overlaps
This control partially overlaps IT.PRO-13.2.
IT.PRO-13.2 requires authentication keys, secrets and tokens to be stored in approved secure repositories protected by access controls, including MFA. Secure storage of keys is part of the cryptographic key management required by Annex A 8.24, so the two share common ground for cryptographic authentication keys. Annex A 8.24 also sets rules for the effective use of cryptography across the wider key life cycle, while IT.PRO-13.2 also extends to secrets and tokens that are not cryptographic keys.
- IT.PRO-10.1Back up data, applications and settings on schedule to encrypted, resilient storageSupports
This control supports IT.PRO-10.1.
IT.PRO-10.1 requires backups of important data, applications and settings to be held on secure, resilient storage protected by encryption together with immutable, offline, logically isolated or equivalent controls. Encrypting backups depends on the cryptography rules and key management required by Annex A 8.24, since encrypted backups can only be restored if their keys are managed securely and remain available during an incident. Annex A 8.24 covers the use of cryptography across the organisation, while IT.PRO-10.1 relies on it for one element of backup protection.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.
Get help with this control
ISO 27001 training
Mindset Cyber runs PECB-accredited ISO/IEC 27001 training that maps directly to the controls in this library.
Need this as a written policy?
PolicyMint drafts the ISO 27001 documentation this control expects, customised to your business and checked by three independent verifiers before you see it. Not a boilerplate template you have to fight into shape. First document free.
Draft your ISO 27001 documentation