If your ISO/IEC 27001:2022 ISMS has a well-maintained control 8.24, a current cryptography policy, and an annual review cycle, you have a framework that can absorb the PQC transition. What you probably do not have is a cryptography policy that names ML-KEM, ML-DSA, SLH-DSA, or FN-DSA, a risk register entry for harvest-now-decrypt-later, or a supplier questionnaire that asks about post-quantum migration timelines. Those gaps are not presentation issues. Under the "current state of the art" obligation that runs through ISO/IEC 27001 implementation, they are audit evidence gaps. This article maps precisely which Annex A controls need updating and what those updates require.

The 2022 revision: what changed and why it matters for this mapping

ISO/IEC 27001:2022, published on 25 October 2022, restructured the Annex A controls from 114 controls across 14 clauses in the 2013 version to 93 controls across four themes: organisational controls (37), people controls (8), physical controls (14), and technological controls (34). Organisations certified to ISO/IEC 27001:2013 had a transition deadline of 31 October 2025 to migrate to the 2022 standard. [VERIFIED: ISO/IEC 27001:2022, https://www.iso.org/standard/82875.html.] Organisations that transitioned to the 2022 standard within the last twelve to eighteen months and that have not yet revisited their 8.24 control documentation in light of the August 2024 NIST FIPS publications are in the position this article addresses.

The Annex A controls are derived from ISO/IEC 27002:2022. Annex A is normative; ISO/IEC 27002 is the guidance document that describes purpose, implementation guidance, and supporting information for each control. For PQC mapping purposes, ISO/IEC 27002 provides the interpretive layer. The five attribute taxonomy in ISO/IEC 27002 (control type, information security property, cybersecurity concept, operational capability, and security domain) allows you to filter the control set by information security property. Filtering on confidentiality and integrity surfaces the controls most directly relevant to cryptographic protection, which is the working set for this mapping. [VERIFIED: ISO/IEC 27002:2022, Section 4.2.]

Before applying this mapping, start with the gap identification methodology in our companion analysis at PQC compliance readiness gap analysis. The mapping tells you what to update; the gap analysis tells you how far back you are starting from.

Annex A 8.24: the primary PQC control

Control 8.24 ("Use of cryptography") is the primary mapping. ISO/IEC 27002:2022 states the purpose: "to ensure proper and effective use of cryptography to protect the confidentiality, authenticity and/or integrity of information according to business and information security requirements." The implementation guidance specifies that the organisation must define which cryptographic algorithms are acceptable, required key lengths and lifetimes, key management procedures, and requirements for selecting and using cryptographic products. [VERIFIED: ISO/IEC 27002:2022, Control 8.24.]

An ISMS implementing 8.24 in 2026 must address four specific items in its cryptography policy and associated procedures. First: the deprecation status of current asymmetric algorithms. NIST IR 8547 (November 2024) formally initiates deprecation of RSA, ECDH, ECDSA, DSA, and finite-field Diffie-Hellman. New deployments are targeted for deprecation by 2030; full legacy retirement by 2035. [VERIFIED: NIST IR 8547, https://doi.org/10.6028/NIST.IR.8547.] Second: the replacement algorithms. ML-KEM (FIPS 203) for key encapsulation; ML-DSA (FIPS 204) for digital signatures; SLH-DSA (FIPS 205) as the stateless hash-based signature alternative; FN-DSA (FIPS 206) as the compact lattice-based signature option. Third: hybrid deployment as the transition mechanism for high-risk flows. X25519+ML-KEM-768 for TLS key exchange; hybrid ML-DSA with ECDSA for signature schemes where classical fallback is required during the transition period. Fourth: a Cryptographic Bill of Materials (CBOM) as the audit evidence that all in-scope systems have been inventoried against the updated algorithm policy.

Parameter selection is not a detail to leave for implementation. An 8.24 policy that refers generically to "ML-KEM" without specifying the parameter set is not a policy an architect can implement. The distinctions matter: ML-KEM-768 (FIPS 203, parameter set II) is the general-purpose recommendation for most enterprise TLS and application key exchange, with a public key of 1,184 bytes and ciphertext of 1,088 bytes. ML-KEM-1024 (parameter set III), with a public key of 1,568 bytes and ciphertext of 1,568 bytes, is specified in NSA CNSA 2.0 (CNSSP 15) for national security systems and high-sensitivity environments. ML-DSA-65 (FIPS 204, parameter set II) is the general-purpose signature recommendation, producing signatures of 3,309 bytes versus 64 bytes for ECDSA P-256 (raw IEEE P1363 format; DER-encoded ASN.1 form is 70-72 bytes in TLS/X.509). That size increase is a capacity planning input for certificate chain depth, JWT payload budgets, and code signing manifests. [VERIFIED: NIST FIPS 203 Table 2; NIST FIPS 204 Table 1; NSA CNSA 2.0 CNSSP 15, September 2022.]

The Mosca inequality provides the analytical basis for review cycle urgency. If x (data protection requirement lifetime) plus y (migration timeline) exceeds z (time before a CRQC), the risk is present now. An ISMS with a five-year cryptographic review cycle, last reviewed in 2023 and next scheduled for 2028, may not surface the RSA/ECDH deprecation issue until after the NIST IR 8547 2030 new-deployment deadline has passed for at least some of its systems. The review cycle for 8.24 must be reset to reflect the accelerated deprecation timeline. [VERIFIED: Mosca, IEEE Security and Privacy, 2018, https://doi.org/10.1109/MSP.2018.3761723.]

Secondary controls where PQC impact flows

Eight Annex A controls beyond 8.24 have PQC-relevant dimensions. The scope is narrower than a full ISMS overhaul, but broader than a single control update.

Control 8.20 ("Networks security") requires controls to protect information in networks and supporting processing facilities. The PQC impact is wherever network security relies on asymmetric key exchange or signature verification: TLS 1.3 handshakes, IPsec IKEv2 key agreement (IETF RFC 9370 provides the multiple key exchange mechanism for IKEv2), BGP route origin authentication via RPKI, and SSH session establishment. The 8.20 control owner should coordinate with the 8.24 owner so that network protocol migration falls within the CBOM scope. [VERIFIED: ISO/IEC 27002:2022, Control 8.20; IETF RFC 9370, https://www.rfc-editor.org/rfc/rfc9370; IETF draft-ietf-tls-hybrid-design for hybrid TLS key exchange.]

Control 8.21 ("Security of network services") covers security of contracted network services including cloud-hosted services. A network service provider with no published PQC roadmap and no support for hybrid TLS key exchange is a supply chain risk under 8.21. The question to add to network service provider assessments: when will your service support ML-KEM-768 in TLS connections and, for IPsec, RFC 9370 multiple key exchange?

Control 8.9 ("Configuration management") is implicated because PQC migration requires systematic configuration changes across servers, load balancers, VPN gateways, HSMs, and PKI infrastructure. Configuration management procedures should include a PQC configuration baseline: the approved cipher suite lists, key encapsulation algorithms, and signature verification parameters that constitute compliant configuration. Deviations from the baseline should trigger a change management review.

Control 5.30 ("ICT readiness for business continuity") addresses a gap that is often missed. Where backup systems, disaster recovery copies, or offline archives use asymmetric encryption for data at rest, those archives may carry HNDL risk. Business continuity plans should assess the cryptographic posture of backup and archive copies, not just primary systems. Backup encryption is typically treated as solved once implemented and not reviewed against changing threat conditions. That assumption does not survive the HNDL threat model.

Control 8.12 ("Data leakage prevention") and control 8.11 ("Data masking") are indirectly affected. Both address protection of sensitive data. If the underlying encryption for data in transit or at rest uses RSA or ECDH key exchange, the HNDL threat means data classified as protected under these controls may not remain protected through its required confidentiality lifetime. The risk register should carry a note for data scopes covered by 8.12 and 8.11 where cryptographic protection lifetime does not cover the data's required confidentiality period.

Supplier controls: 5.19, 5.20, and 5.22

Controls 5.19 ("Information security in supplier relationships") and 5.20 ("Addressing information security within supplier agreements") cover the supply chain dimension. For PQC, these controls require that supplier security assessments and contracts address the post-quantum transition. Two specific additions: a PQC readiness question to supplier security questionnaires ("Does your organisation have a published PQC migration roadmap? When will your cryptographic interfaces support ML-KEM and ML-DSA?"), and a contractual requirement that critical suppliers using cryptographic interfaces will notify the organisation of planned migration timelines and any changes to hybrid capability. [VERIFIED: ISO/IEC 27002:2022, Controls 5.19 and 5.20; NIST NCCoE SP 1800-38B supply chain recommendations.]

Control 5.22 ("Monitoring, review and change management of supplier services") creates an ongoing monitoring obligation. For PQC, the standing checkpoint in annual supplier reviews is: has the supplier updated their cryptographic interfaces since the last review? Have they published a migration timeline? A supplier that has not progressed in twelve months should move up the supply chain risk register.

The control mapping table

Evidence requirements for your next ISO 27001 audit

For an ISO/IEC 27001:2022 certification or surveillance audit after August 2024, an auditor assessing control 8.24 should ask whether the organisation's cryptography policy references post-quantum cryptographic standards. An ISMS that has not updated its 8.24 documented information to reflect FIPS 203/204/205/206 and NIST IR 8547 is operating with a policy whose technical basis is materially behind the current state of the art. [INFERRED from standard ISO 27001 audit practice applied to the August 2024 standards baseline change. Certification bodies are not yet uniformly applying PQC as an explicit 8.24 audit criterion as of mid-2026. ASSUMED: verify with your certification body or IAF/UKAS guidance. Organisations that update 8.24 documentation proactively are ahead of the audit requirement, not catching up to it.]

The documented information items that require updating for 8.24 PQC compliance:

Cryptography policy: add approved PQC algorithm list distinguishing parameter sets (ML-KEM-768 general purpose; ML-KEM-1024 for high-sensitivity environments; ML-DSA-65 for general signature applications; SLH-DSA-SHA2-128s as stateless hash-based alternative for long-lived signatures). Key management procedure: add key encapsulation migration steps and hybrid key exchange authorisation. CBOM or equivalent asset register: all asymmetric key uses inventoried by algorithm, key size, system, and data classification with confidentiality lifetime. Supplier questionnaire: PQC readiness question added for all tier-one critical suppliers. Risk register: HNDL entry for data with confidentiality lifetime extending beyond the 2033 to 2035 expert-consensus Q-Day range, with documented treatment decision.

ETSI TS 119 312, NIST SP 800-53, and the regulatory overlay

For EU-regulated organisations subject to eIDAS, NIS2, or EU sector requirements, ETSI TS 119 312 V1.4.1 (Electronic Signatures and Trust Infrastructures: Cryptographic Suites) is the primary EU technical reference for algorithm selection in qualified trust services under eIDAS. It functions as the EU implementation guidance layer that sits above the ISMS framework: ISO/IEC 27001 provides the management system structure; ETSI TS 119 312 provides the EU algorithm selection requirements. ETSI TR 103 619 on quantum-safe cryptography provides the standards body's technical framing for the transition. [VERIFIED: ETSI TS 119 312 V1.4.1, August 2022; ETSI TR 103 619, 2022.]

For US-regulated organisations and their supply chains, the NIST SP 800-53 Rev 5 control family SC applies: SC-8 (Transmission Confidentiality and Integrity), SC-12 (Cryptographic Key Establishment and Management), and SC-28 (Protection of Information at Rest) are the functional equivalents of ISO 27001 Annex A 8.24. The PQC mapping is identical: FIPS 203/204/205/206 as the approved algorithms, NIST IR 8547 as the deprecation baseline. NIST SP 800-175B Rev 1 (Guideline for Using Cryptographic Standards in the Federal Government) provides the pre-PQC baseline for federal environments and should be read alongside NIST IR 8547 and the individual FIPS documents until an updated revision is published. [VERIFIED: NIST SP 800-53 Rev 5, https://doi.org/10.6028/NIST.SP.800-53r5; NIST SP 800-175B Rev 1, https://doi.org/10.6028/NIST.SP.800-175Br1.]

Practical first steps

For a security architect beginning this work in 2026, four actions in priority order. First: update the 8.24 cryptography policy to reference FIPS 203/204/205/206 by parameter set and NIST IR 8547 deprecation timeline. This is a documentation change with no operational dependency and can be completed in days. Second: initiate a CBOM for all systems in ISMS scope. The CBOM is the foundational evidence item for 8.24 and simultaneously informs 8.20, 5.19/5.20, and 5.30. Third: add the PQC readiness question to the next supplier review cycle. This requires no new tooling, only an update to the existing questionnaire template. Fourth: create the risk register HNDL entry for data with confidentiality lifetime beyond 2033, with a documented treatment decision linked to the migration plan.

The CBOM is the single artefact that serves the most controls simultaneously. A well-executed CBOM, structured per NIST NCCoE SP 1800-38B, provides the audit evidence for 8.24 algorithm inventory, informs the network protocol scope for 8.20, defines the supplier interface scope for 5.19/5.20, and identifies the backup and archive encryption posture for 5.30. The investment in producing it returns multiple times across the control set.

For the companion operational checklist across the full PQC readiness scope, see the PQC readiness checklist for CISOs in 2026.