Annex A 8.24 is the ISO 27001:2022 control that governs how an organisation uses cryptography. It requires a documented, risk-based policy and a managed lifecycle for keys and certificates. Assessors test it through evidence of operation, not by reading policy text alone.
What Annex A 8.24 Means in Practice
Annex A 8.24 is the ISO 27001:2022 control for cryptographic use, not a generic “use encryption” statement. It requires an organisation to define when cryptography is used, who owns it, and how the supporting material is governed across its lifecycle.
The practical point is that cryptography is treated as a managed control, not a one-time design choice. That includes algorithms, approved use cases, key handling, certificate handling, and the evidence needed to show the control is operating as intended.
Why Cryptography Needs a Managed Policy
Cryptography can protect confidentiality, integrity, authenticity, and non-repudiation, but only when the policy around it is specific enough to be operational. A documented, risk-based policy helps an organisation decide where cryptography is required, what strengths are acceptable, and when exceptions are permitted.
This matters because weak or inconsistent cryptographic choices create hidden exposure. A control can look strong on paper while still failing in practice if teams choose different algorithms, allow local workarounds, or never review whether the cryptographic design still matches the threat model.
For organisations comparing ISO guidance with adjacent control families, the control sits naturally alongside broader implementation guidance in ISO/IEC 27002:2022 Information Security Controls and the control intent expressed in ISO/IEC 27001:2022 Information Security Management.
Keys, Certificates, and the Cryptographic Lifecycle
The control becomes concrete in lifecycle management. Keys and certificates must be generated, distributed, stored, rotated, revoked, renewed, and destroyed in a way that preserves their trust value over time. This is where many implementations fail, because the cryptography itself is sound while the lifecycle process is not.
Key lifecycle decisions are especially important because compromise, expiry, or reuse can turn a protective control into an operational dependency. For that reason, key management guidance is a useful companion reference, especially where the organisation needs a stronger lifecycle model than policy text alone provides, as described in NIST SP 800-57 Key Management.
Assessment evidence usually focuses on operational artefacts, such as configuration standards, approved key lengths, rotation procedures, certificate inventories, renewal workflows, and logs showing that the lifecycle is actually being executed.
How Assessors Read the Control
Auditors and assessors usually look for evidence that the organisation can explain its cryptographic choices and prove they are managed consistently. They are testing for governance, ownership, and repeatability, not just technical awareness.
The strongest evidence is operational. A policy that names approved cryptographic use, a lifecycle process for keys and certificates, and records showing those processes were followed will carry more weight than a high-level statement that “encryption is used where appropriate.”
That operating-model view aligns well with the key-management recommendations in NIST SP 800-57 Key Management, which is often the most practical reference when an organisation needs to turn cryptographic policy into day-to-day control behaviour.
Risk and Threat Considerations
Cryptography fails most often through lifecycle weakness, not mathematical weakness. Stolen keys, expired certificates, uncontrolled exceptions, and weak storage practices can expose data or break trust even when the selected algorithm is sound.
Failure mechanism: Attackers or insiders abuse exposed keys, long-lived certificates, poor rotation, or inconsistent implementation to decrypt data, impersonate systems, or undermine trust relationships.
Impact: The result can be confidentiality loss, integrity failure, authentication bypass, service disruption, or a broad compromise of systems that depend on the same cryptographic trust chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | This is the exact Annex A control being defined and assessed. |
| Recommendation — Document cryptographic requirements, ownership, and lifecycle evidence for keys and certificates. | ||
| NIST SP 800-57 | Key Management | Key lifecycle, cryptoperiods, and rotation directly shape cryptography governance here. |
| Recommendation — Align key generation, rotation, storage, and destruction to a managed lifecycle. | ||
Practitioner Guidance
Why practitioners should care: Annex A 8.24 is strongest when cryptography is managed as an operational control with ownership, standards, and evidence, not treated as a design assumption. If the organisation cannot show how keys and certificates are controlled across their lifecycle, the control is only partially effective.
Practitioner takeaway: Treat the cryptographic policy, lifecycle process, and operational evidence as one control family, because assessors will judge them together.
Related resources from NHI Mgmt Group
- Why does the TLS handshake use both public key and symmetric key cryptography?
- How should MSSPs use AI SOC analysts to scale 24/7 alert investigations without overloading their team?
- How should organisations decide whether to build an in-house SOC or use MDR for 24/7 monitoring?
- What are the best ways for MSSPs to use automation for 24/7 security coverage?
