Seven systematic gaps in ISO/IEC 27002:2022

Methodology of the gap analysis

The gap analysis proceeds in three stages. First, all requirements of the five primary comparison frameworks — C5:2026, NIST, DORA, the CRA and NIS2 with its Implementing Regulation — are compared against the ISO 27002:2022 catalogue. Second, those requirements are extracted that ISO 27002 does not contain, or contains only in very abstract form. Third, each extracted requirement is examined for whether it provides hard protective effect under Mythos conditions — that is, whether it satisfies one of the criteria in Chapter 3.2: cryptographic impossibility, structural reduction of the blast radius, aggregation resistance, or a hard time barrier.

Requirements that merely restate controls already present in ISO 27002 are not counted as gaps. Nor are requirements that, while more detailed in another framework, are themselves degraded under Mythos conditions. The following analysis is confined to substantive differences from the ISO text that are simultaneously Mythos-robust.

The gaps group into seven thematic clusters, ordered by operational proximity to the Mythos core threat.

Cluster 1: post-quantum strategy and crypto agility

ISO 27002 reference: A.8.24 (use of cryptography) requires a documented, risk-based approach to cryptographic mechanisms but remains at an abstract level. No explicit requirement for post-quantum preparation, a cryptographic inventory or crypto agility.

Requirement in other frameworks: C5:2026 CRY-01.01AC requires, in binding form, a documented post-quantum strategy with four elements: a cryptographic inventory with priority levels, ongoing observation of the state of the art, use of hybrid cryptography models, and defined triggers, resources, transition plans and success criteria for the PQC migration. CRY-01.03AC requires at least annual review. CRY-02 (Cryptographic Change Management) anchors crypto agility operationally.

Mythos robustness: The gap is Mythos-robust for two reasons. First, the store-now-decrypt-later threat model is concrete and effective today. Exfiltrated data can be stored for years until quantum computing is operationalized. Second, crypto agility is a structural precondition for reacting to suddenly devalued algorithms without entering weeks of re-engineering cycles. A qualification applies: the core of this gap — the quantum threat — does not result from Mythos but exists independently of it; through the risk perspective, ISO already implicitly requires appropriate methods. A third aspect is Mythos-specific: PQC methods are comparatively new and less battle-tested than RSA or ECDH, so AI-supported cryptanalysis could weaken immature schemes faster. That further raises the requirement for crypto agility — for example several trust anchors with different algorithms and the ability to deactivate individual ones at short notice.

Key management facets. An analysis by the Cloud Security Alliance on PQC key management (Cloud Key Management Working Group, draft, August 2026) concretizes four aspects that a pure algorithm migration overlooks. First, the trust-now-forge-later variant of the harvesting attack: not only encrypted data but also signatures valid today — certificates, code signatures, long-lived signed documents — can be harvested and later retroactively forged or repudiated using a cryptographically relevant quantum computer; long-lived signatures therefore belong in the inventory and the migration scope. Second, the downgrade risk of hybrid protocols: an attacker can force a hybrid negotiation (for example hybrid TLS) back onto the classical component; what is required is enforced quantum-safe negotiation, rejection of purely classical sessions, and logged downgrade detection. Third, the migration order within the key hierarchy: the root must be migrated to PQC first (master or key encryption key, root CA), then the derived keys — PQC only at lower levels with a classical root leaves the trust anchor vulnerable, particularly for archived data with long protection requirements. Fourth, quantum-safe timestamps: a classical timestamping authority (TSA) weakens the non-repudiation chain irrespective of the signature algorithm; signature and TSA certificates must be migrated to PQC, with periodic timestamp renewal for long-term archives.

Cluster 2: supply chain transparency and SBOM obligation

ISO 27002 reference: A.5.19 to A.5.23 address the supply chain at policy and contract level. No requirement for technical transparency about the software components in use, no SBOM obligation and no binding build provenance requirement.

Requirement in other frameworks: C5:2026 DEV-13 (Transparency about Software Components). Under EU CRA Annex I Part II, producing an SBOM is one of the essential requirements for vulnerability handling; satisfying the applicable requirements is in turn a precondition of conformity, on the basis of which CE marking takes place. This is binding only for manufacturers of products with digital elements placed on the EU market; for other organizations the SBOM remains a risk-based decision. DORA Art. 28 requires detailed transparency for ICT third-party providers. NIS2 IR No. 5 (supply chain security) requires documented dependencies. The SLSA framework defines build provenance levels.

Mythos robustness: An SBOM enables structural detection that does not rest on attacker friction. The attack becomes recognizable as soon as the compromised component is published in EUVD, CVE or OSV. The reduction in detection latency is structural, not temporal.

Cluster 3: containers, confidential computing and multi-tenancy

With its March 2026 revision, C5:2026 introduced three structurally new control domains that ISO 27002 does not contain and that are explicitly tailored to modern cloud workload architectures.

Container security

ISO 27002 reference: No container-specific controls. General environment and configuration controls (A.8.9, A.8.19, A.8.31) are applicable but do not address the specific container attack surfaces.

Requirement: C5:2026 OPS-34 (Container Management – Policies and Procedures) and OPS-35 (Implementation), together with PSS-11 (Images for Virtual Machines and Containers), require documented image sources, signed images, runtime protection and network segmentation at container level. NIST SP 800-190 as the reference.

Mythos robustness: Container signing creates a cryptographic and structural barrier against compromised base images from public registries.

Confidential computing

ISO 27002 reference: No requirements for trusted execution environments or remote attestation.

Requirement: C5:2026 OPS-32 (Confidential Computing – Policies and Procedures) and OPS-33 (Remote Attestation). NIST trusted computing concepts as the reference.

Mythos robustness: Confidential computing is currently the hardest barrier against attackers with infrastructure access, because it protects the confidentiality of data in processing — not only in transit and at rest.

Multi-tenancy isolation

ISO 27002 reference: No specific multi-tenancy controls. Generic separation controls (A.8.22, A.8.31) are not sufficient.

Requirement: C5:2026 OPS-30 (Separation of Datasets – Policies and Procedures) and OPS-31 (Implementation) explicitly require the separation of customer data in multi-tenant environments with demonstrable implementation. PSS-10 (Software Defined Networking) supplements the network side.

Mythos robustness: Structural limitation of the blast radius: an attacker who gains a foothold in one tenant is demonstrably prevented from accessing other tenants.

Cluster 4: binding notification deadlines and root cause analysis

ISO 27002 reference: A.5.5 (contact with authorities) and A.5.25 (assessment of events) address notification channels without concrete deadlines. A.5.27 (learning from incidents) does not require root cause analysis.

Requirement in other frameworks: NIS2 Directive Art. 23(4) requires an early warning within 24 hours, a full notification within 72 hours for significant incidents, and a final report after one month. DORA Art. 19 requires major incident reports to supervisory authorities with detailed content requirements. DORA Art. 17 makes root cause analysis a mandatory phase in the incident management life cycle. The Cyber Resilience Act (CRA) additionally obliges those placing products with digital elements on the market to report actively exploited vulnerabilities (including a 24-hour early warning to ENISA or the competent CSIRT). NIS2 IR No. 3.6 requires post-incident reviews including root cause determination.

Mythos robustness: Time-based notification deadlines are Mythos-robust because they mirror, on the regulatory side, the time compression that benefits Mythos attackers: an organization that must report within 24 hours needs corresponding automation on the detection and triage side. Root cause analysis creates the empirical basis for detection improvement. The deadlines do not, however, apply equally to every organization — what matters is the role (for example placing products on the market under the CRA) and the classification under NIS2; for organizations not covered, the gap is correspondingly smaller. Through the compliance obligations of an ISMS (consideration of the expectations of interested parties, including legal requirements), the applicable deadlines feed into the security objectives in any case.

Cluster 5: continuous checking in addition to periodic audits

ISO 27002 reference: A.5.35 (independent review) describes periodic audits. A.5.36 (compliance with policies) and A.8.8 (vulnerability management) are classified as friction-only in Chapter 6.

Requirement in other frameworks: C5:2026 OPS-25.01AS requires daily vulnerability scans as an additional sharpening. COM-03 and COM-04 require continuous ISMS effectiveness checking. NIS2 IR No. 2.2 (monitoring of compliance) requires an effective reporting system. DORA Art. 24–26 requires a digital operational resilience testing programme; Art. 26–27 requires threat-led penetration testing (TLPT) for critical functions.

Mythos robustness: Continuous checking offsets time compression on the defensive side. Detection latency falls from months and quarters to hours and days. TLPT with Mythos-specific scenarios is the best-known regulatory regime to address the empirical level explicitly: it tests whether the controls work, not whether they are documented.

Cluster 6: phishing-resistant identity and zero trust architecture

ISO 27002 reference: A.5.17 and A.8.5 require authentication appropriate to the protection requirement, without naming concrete methods or assurance levels. A.5.16 requires identity management without an explicit workload identity requirement.

Requirement in other frameworks: NIST SP 800-63B defines three authentication assurance levels; AAL2 and AAL3 are relevant for Mythos environments. FIDO Alliance standards (WebAuthn, passkeys). NIST SP 800-207 Zero Trust Architecture defines workload identity as a structural principle. NIST NCCoE work on agent identity. SPIFFE/SPIRE as the de facto standard.

Mythos robustness: Phishing-resistant MFA is the direct answer to AI-quality phishing: even if a user lands on a perfectly crafted phishing page, the attacker cannot obtain a usable authentication credential, because FIDO2 performs origin binding. Workload identity is structural: it replaces shared secrets with hardware-anchored, short-lived identities.

Cluster 7: automation obligation and resilience testing

ISO 27002 reference: No express automation obligation. A.5.30 (ICT readiness for business continuity) and A.8.16 (monitoring) mention no concrete test scenarios for parallel incidents.

Requirement in other frameworks: NIS2 IR No. 3.2.2 requires automated monitoring to the extent feasible. NIS2 IR No. 3.5.5 requires testing of the response procedures. DORA Art. 24–26 requires a comprehensive digital operational resilience testing programme. DORA Art. 26–27 requires TLPT with scenarios that reflect real threats. In the Glasswing defensive post, Anthropic explicitly recommends tabletop exercises for three to five parallel incidents.

Note on the strength of the NIS2 IR wording: The Implementing Regulation frames the automation obligation as a "should" provision ("to the extent feasible", "subject to operational capacity") and not as an absolute obligation. For Mythos-exposed organizations, feasibility should be construed restrictively, since manual response times fail structurally against agentic attackers.

Mythos robustness: The automation obligation is the only realistic answer to the asymmetry between an agentic attacker and a human defensive chain. Parallel incident testing directly addresses the fragmentation strategy.

Summary: the gap delta of ISO 27002

Together, the seven clusters describe the systematic delta between ISO/IEC 27002:2022 and the regulatory requirements of the past three years. This delta was not designed into ISO 27002 as a deficiency — it reflects the framework-by-framework specialization of the standards landscape.

Under Mythos conditions, this delta becomes an operationally relevant problem. An organization relying on the pure ISO 27002 baseline does not have the concrete requirements that C5:2026, NIST, DORA, the CRA and NIS2 with its Implementing Regulation impose in response to the current threat landscape. Closing the delta is not a compliance exercise but the core task of operational Mythos hardening.

The seven clusters can be condensed into two movements: a structural modernization of the security architecture (cluster 1 cryptography, 3 cloud infrastructure, 6 identity) and a temporal shortening of the defensive loops (cluster 2 supply chain, 4 notification obligations, 5 continuous checking, 7 automation). Chapter 9 brings these movements together into the prioritized catalogue of Mythos Hardening Controls.

Derivation from the gap clusters

Twelve of the thirteen MHC can be traced primarily to the seven gap clusters from Chapter 8; MHC-08 arises primarily from the control degradation analysis and is additionally supported by external framework requirements:

• Cluster 1 (cryptography and post-quantum): MHC-01.
• Cluster 2 (supply chain transparency): MHC-02; MHC-13 adds agentic supply chain components (MCP servers, IDE extensions, agentic skills).
• Cluster 3 (containers, confidential computing, multi-tenancy): MHC-06 and MHC-07.
• Cluster 4 (notification obligations and root cause): MHC-11 (response side); notification deadline compliance is not listed as a separate MHC, because it must be implemented in any case as a direct legal obligation under NIS2 and DORA.
• Cluster 5 (continuous checking): MHC-10 and MHC-12.
• Cluster 6 (phishing-resistant identity and zero trust): MHC-03, MHC-04 and MHC-13 (identity life cycle of AI agents).
• Cluster 7 (automation and resilience testing): MHC-05, MHC-09 and MHC-11.

MHC-08 (immutable backups) results not primarily from the external framework gap analysis but from the in-depth assessment of A.8.13, A.5.29, A.5.30 and the adjacent resilience controls in Chapters 4 and 5: ISO requires backup and recoverability but neither immutability nor separate access paths for the backup infrastructure — and it is precisely these two properties that determine effectiveness under Mythos conditions. MHC-05 is the operational basis of the automation obligation (cluster 7) and at the same time the answer to the aggregation blindness of classic detection.