ISO/IEC 27001:2022:

Overview

ISO/IEC 27001:2022 is the internationally recognized standard for Information Security Management System (ISMS) certification. The 2022 revision restructured Annex A into 93 controls across four themes and consolidated the 2013 edition’s separate cryptography and key management controls into a single control, 8.24, Use of Cryptography.

In practical terms, 8.24 requires a documented, risk-based cryptography policy defining approved algorithms and minimum key strengths, alongside a managed lifecycle for cryptographic keys, generation, distribution, storage, rotation, and destruction, that auditors verify through operational evidence rather than policy statements alone. For software and IT service companies, that scope routinely includes cryptography embedded in the product itself, not only the internal IT environment.

Why it matters

Certification is voluntary, but it has become a de facto commercial prerequisite for IT and software vendors specifically: customer security questionnaires, RFPs, and supplier risk assessments increasingly require current ISO 27001 certification as a condition of doing business, making a lapsed certificate a direct threat to revenue rather than just a compliance finding.

Because 27001 is a management-system standard rather than a prescriptive technical one, auditors testing 8.24 expect to see ownership, traceability, and evidence: a certificate and key inventory, a Statement of Applicability that justifies the control’s scope, and internal audit findings, tested annually at surveillance audits and in full at the three-year recertification.

How this maps to cryptography 

ISO/IEC 27001 addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:

Audit readiness

Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:

• Documented Cryptography Policy:  Is there a topic-specific policy defining approved algorithms, minimum key lengths, and the conditions under which encryption is mandatory, covering both internal systems and shipped products?
• Key Lifecycle Evidence:  Can the organization demonstrate generation, secure storage, rotation, and destruction procedures for cryptographic keys, not just a policy statement?
• Statement of Applicability Traceability:  Does the SoA correctly justify the inclusion of 8.24 and link it to the underlying risk assessment?
• Legal and Jurisdictional Compliance:  Has the organization considered jurisdictional restrictions on cryptography, including export controls and data residency, as 8.24 requires?
• Certificate and Key Inventory Currency:  Is there an up-to-date inventory of certificates and cryptographic keys with named owners and expiry dates, including those embedded in software releases?
• Internal Audit and Management Review:  Has internal audit tested the 8.24 controls, with findings reviewed by management within the ISMS cycle?

TAKE THIS TO MANAGEMENT

ISO 27001:2022 folded cryptography and key management into a single control, 8.24, and auditors now test whether we actually operate a key lifecycle, not whether we’ve checked an “encryption enabled” box. For a software company, certification lapses cost us the vendor assurance credential that increasingly gates customer contracts and RFPs before a deal ever reaches negotiation.

The gap we see most often at recertification is the Statement of Applicability: organizations write a cryptography policy but can’t produce the certificate and key inventory an auditor asks to see next, especially for keys embedded inside the product itself rather than just the corporate IT environment. The three-year recertification cycle sounds distant, but surveillance audits happen every year, so this evidence needs to be current now, not staged before the next visit.