ISO 27001 Cryptography Policy: The Complete 2026 Guide

An ISO 27001 cryptography policy is the document that satisfies Annex A 8.24, and it is one of the few security documents whose weaknesses surface years after the certificate is issued rather than during the audit. Most versions I read are two pages long, say “strong encryption is used where appropriate,” and name no algorithm, no key length, no key owner and no review date. That passes a hurried stage 2 and fails the first time a key is lost, a legacy database turns up unencrypted, or someone asks whether your TLS stack is still acceptable in 2030.

This guide sets out what an ISO 27001 cryptography policy has to contain, what control 8.24 actually asks for, what the 2022 edition changed, the key lifecycle an auditor will trace, and the algorithm decisions that will date your policy faster than anything else in your ISMS.

What an ISO 27001 cryptography policy must cover under Annex A 8.24

ISO/IEC 27001:2022 carries 93 Annex A controls in four themes — 37 organizational, 8 people, 14 physical and 34 technological. Control 8.24, Use of cryptography, is a technological control, and its requirement is short: rules for the effective use of cryptography, including cryptographic key management, have to be defined and implemented. Two words in that sentence do the work. Defined is why you need a document. Implemented is why the document alone will not get you through stage 2.

ISO/IEC 27002:2022 expands the control into implementation guidance, and that guidance is effectively the table of contents for an ISO 27001 cryptography policy. Stripped to its decisions, here is what an ISO 27001 cryptography policy has to settle and what an auditor will ask to see.

What 8.24 expects you to decide	What to write in the policy	Evidence an auditor asks for
Risk and classification basis	Which classification levels require encryption at rest, in transit, and on endpoints	The classification scheme, plus a sample of systems matched to it
Approved algorithms and minimum strengths	A named list (cipher, mode, minimum key length) with an owner and a review date	Configuration evidence from two or three systems on the list
Roles and responsibilities	Who approves algorithms, who generates keys, who holds custody, who authorises recovery	Named roles, not job families; delegation recorded
Key management across the lifecycle	Generation through destruction, including compromise and loss	A key inventory and records for at least one full rotation
Impact on content inspection	Where encrypted traffic is decrypted for malware and data-leakage inspection, and under whose authority	The proxy or inspection design, plus the privacy justification
Legal and regulatory restrictions	Use, import and export restrictions, and limits on moving encrypted data across borders	Documented legal advice, dated
Third-party cryptographic services	Liability and service-continuity terms with KMS, HSM and certificate providers	The contract clauses, referenced from the policy

The content-inspection line is the one most policies skip, and it is the one that produces real arguments later. Encryption you cannot inspect also hides malware and exfiltration from the controls you implemented under A.8.7 and A.8.12. The standard expects the ISO 27001 cryptography policy to say where that trade-off is resolved, not to pretend it does not exist.

Why ISO 27001:2022 merged two cryptography controls into one

In the 2013 edition, cryptography had its own Annex A clause with two controls. The 2022 edition collapsed both into a single technological control.

ISO 27001:2013	ISO 27001:2022	What changed in practice
A.10.1.1 Policy on the use of cryptographic controls	A.8.24 Use of cryptography	One Statement of Applicability line where legacy SoAs had two
A.10.1.2 Key management	A.8.24 Use of cryptography	Key management is no longer a separate control; it passes or fails with the rules

That merge has a consequence people miss. If you still maintain a cryptography policy and a separate key management policy — which is perfectly allowed — both now hang off a single control reference, so both get tested together and neither may contradict the other. I have seen a policy pair where the encryption document mandated AES-256 and the key document still described 3DES key blocks inherited from a payments project. Under the 2013 split that was two findings in two places. Under 8.24 it is one control that does not work.

If you are rebuilding the control set, read the merge alongside the rest of the restructure in our guide to the ISO 27001 Annex A controls, and record the decision in your Statement of Applicability, which clause 6.1.3 makes mandatory.

The key management lifecycle your ISO 27001 cryptography policy has to name

Key management is where an ISO 27001 cryptography policy is won or lost. 27002’s guidance walks the full life of a key, and the stages below are the ones an auditor will trace against a real key. NIST’s SP 800-57 Part 1 Revision 5 (May 2020) is the free reference that gives each stage usable detail, including cryptoperiods — how long a given key may stay in service.

Lifecycle stage	What the policy states	Most common gap
Generation	Approved source of randomness and the system or HSM that generates each key type	Keys generated on a laptop and uploaded
Distribution and issuing	The protected channel, and who may request a key	Keys emailed or pasted into a ticket
Storage	Where keys live, and that they are held apart from the data they protect	Key material in the same repository as the ciphertext
Use	Permitted purposes per key, and separation of signing from encryption keys	One key reused across environments
Rotation and change	Cryptoperiod per key type and the trigger for an unscheduled change	A stated rotation period nobody has ever executed
Backup and escrow	What is backed up, where, and who can authorise restoration	No escrow, so encrypted data dies with one administrator
Recovery	The route to recover information when a key is lost, and who approves it	Recovery exists technically but has no authorisation step
Compromise and revocation	Who declares a compromise, the revocation path, and re-encryption obligations	No named decision-maker, so nothing happens out of hours
Archival and destruction	Retention of keys needed to read archived records, and verified destruction	Keys destroyed while the records they decrypt are still retained
Logging and monitoring	Which key events are logged and reviewed	Key events logged but never read

One practical test tells you whether the lifecycle is real: ask for the key inventory. If the ISO 27001 cryptography policy describes ten lifecycle stages and nobody can produce a list of keys with owners, types and rotation dates, the policy is describing a process the organisation does not run. That single question closes out most of this control.

Algorithms, key lengths, and the 2030 problem

Here is the uncomfortable part of writing an ISO 27001 cryptography policy: ISO/IEC 27001 names no algorithm and no key length anywhere. That is deliberate — a management system standard that hard-coded AES-256 would be obsolete within a revision cycle. The consequence is that the most perishable content in your ISMS sits in a document ISO gives you no help writing.

The reference point most organisations now use is NIST. Three post-quantum standards were published on 13 August 2024: FIPS 203 (ML-KEM, for key establishment), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA, both for digital signatures). Alongside them, NIST IR 8547, Transition to Post-Quantum Cryptography Standards, sets out how the classical algorithms are expected to be retired.

Algorithm family	Security strength	Proposed transition
RSA, finite-field and elliptic-curve Diffie-Hellman (key establishment)	112 bits	Deprecated after 2030, disallowed after 2035
RSA, finite-field and elliptic-curve Diffie-Hellman (key establishment)	128 bits or more	Disallowed after 2035
ECDSA, EdDSA, RSA (digital signatures)	112 bits	Deprecated after 2030, disallowed after 2035
ECDSA, EdDSA, RSA (digital signatures)	128 bits or more	Disallowed after 2035
AES (block cipher)	128 / 192 / 256 bits	No transition date; maps to post-quantum security categories 1, 3 and 5

Two cautions. First, IR 8547 was published in November 2024 as an initial public draft and has not been finalised, so treat 2030 and 2035 as NIST’s stated intent rather than settled rules — and note that NIST’s earlier plan in SP 800-57 had been to disallow 112-bit public-key schemes from 1 January 2031. Second, none of this is an ISO 27001 requirement. No certification body will fail you in 2031 for using RSA-2048. What they will test is whether the ISO 27001 cryptography policy has a review mechanism that would notice.

That is the useful way to write this section: name your approved algorithms today, state the external sources you track, give the list an owner and a review frequency, and keep an inventory of where cryptography is used. The post-quantum migration is an inventory problem long before it is a mathematics problem, and the organisations that will struggle are the ones that cannot answer “where do we use RSA?” at all.

Is an ISO 27001 cryptography policy a mandatory document?

Strictly, no — an ISO 27001 cryptography policy is not on the mandatory list. Those documents come from the main clauses — scope, policy, risk assessment and treatment methodology, Statement of Applicability, risk treatment plan, security objectives and the required records — and a cryptography policy is not among them. Our ISO 27001 mandatory documents checklist sets out the full list.

In practice the distinction rarely helps anyone. A.8.24 applies unless you can justify excluding it in the SoA, and almost nobody can: if you terminate TLS, encrypt a laptop, or hold a password hash, cryptography is in use. Once the control is applicable, “rules shall be defined” means documented rules, and an auditor will ask to read them. What you do have is freedom of format — the rules can sit inside a wider set of topic-specific policies rather than in a standalone document, which is often the better choice for a small ISMS. Our library of ISO 27001 policy templates shows both shapes.

Where an ISO 27001 cryptography policy collides with other controls

An ISO 27001 cryptography policy is not a self-contained document, and its conflicts with neighbouring controls are predictable:

• A.8.7 and A.8.12 — malware protection and data-leakage prevention both rely on inspecting content that your encryption hides. Decide where traffic is decrypted and document the authorisation.
• A.5.12 and A.5.13 — classification and labelling drive algorithm strength. If the policy says encryption follows classification, the scheme has to exist first; see our guide to data classification for ISO 27001.
• A.5.33 and A.8.13 — protection of records and information backup. Keys needed to read retained records must outlive the rotation schedule, and key backups must not sit beside the ciphertext.
• A.5.31 — legal, statutory, regulatory and contractual requirements. Restrictions on the use, import or export of cryptography are real in several jurisdictions, and 27002 expects the policy to account for the cross-border movement of encrypted information. Documented legal advice is the evidence.
• GDPR Article 32(1)(a) — encryption is named as an example of an appropriate technical measure, and Article 34(3)(a) is the reason it matters commercially: measures that render personal data unintelligible can remove the obligation to notify data subjects of a breach. That defence rests on the key management described in your policy actually having been in force. We cover the transfer-specific version of this argument in encryption as a supplementary measure in a TIA.

Five findings auditors raise against an ISO 27001 cryptography policy

1. No algorithms named. “Industry-standard encryption” is not a rule. It cannot be implemented, so it cannot be audited.
2. No key inventory. The lifecycle is documented and untracked, so rotation and destruction claims cannot be tested.
3. Keys stored with the data. Common in cloud builds where the default key store sits in the same account and the separation was never designed.
4. No compromise path. The policy says compromised keys are revoked promptly but names no decision-maker and no out-of-hours route.
5. Defined but not implemented. The policy mandates encryption at rest for confidential data; a sample of storage turns up a legacy bucket or an old database that predates the rule. This is the finding the word “implemented” exists to catch.

Note what is not on that list: using an algorithm NIST intends to deprecate in 2030. That is a planning gap to record, not a nonconformity today.

Frequently asked questions

Do we need a separate key management policy as well?

No. Since the 2022 edition merged A.10.1.1 and A.10.1.2 into A.8.24, a single ISO 27001 cryptography policy covering rules and key management is sufficient and is usually easier to keep consistent. Two documents are still acceptable if both are referenced from the same SoA entry and they agree with each other.

Does ISO 27001 require AES-256?

No. ISO/IEC 27001 specifies no algorithm or key length. You select them on the basis of your risk assessment and information classification, name them in the policy, and justify the choice. AES-256 is a common and defensible selection, not a requirement.

Can we exclude A.8.24 from the Statement of Applicability?

You can, but you have to justify it under clause 6.1.3, and the justification has to survive contact with reality. Any use of TLS, full-disk encryption, signed code or hashed credentials makes cryptography applicable. Exclusion is realistic only for a scope with no electronic information processing at all.

How often should the policy be reviewed?

ISO 27001 sets no frequency for topic-specific policies; it requires review at planned intervals and after significant change. For an ISO 27001 cryptography policy, tie the trigger to external events as well as the calendar — a new NIST publication, a deprecated cipher suite, a new jurisdiction — because the algorithm list ages faster than the rest of the ISMS.

Do the 2030 and 2035 dates affect our certificate?

Not directly. They come from NIST IR 8547, a US draft publication, and they bind federal systems and their suppliers rather than ISO certification. They matter to your ISMS because clause 6.1.2 expects you to identify risks you know about, and a documented post-quantum migration plan is a cheap way to show that you did.

If you would rather start from a drafted control set than a blank page, the ISO 27001 Toolkit includes 165 templates covering the cryptography and key management rules described here alongside the Statement of Applicability, risk assessment and the rest of the mandatory documentation, for $99 as a one-time purchase.