Regulatory mapping · MRIS 2.0 · Implementation Guides · MRIS.bd
Hardening against AI attacks and regulation: NIS2, DORA, CRA and the EU AI Act
Which Mythos Hardening Controls touch requirements of NIS2 and its Implementing Regulation, DORA, the Cyber Resilience Act and the EU AI Act, and how twelve core topics of information security are anchored in ISO 27002, C5:2026, NIST CSF, DORA, the CRA and NIS2.
Hardening as a legal obligation
The regulatory embedding should be made transparent. Mythos hardening is, to a considerable extent, a legal obligation rather than merely best practice — depending, however, on sector and addressee group. For CRA-obligated software manufacturers, DORA-regulated financial institutions and NIS2 IR addressees (certain digital providers, see Chapter 3.3), it applies directly; for other NIS2 entities, the respective national transposition governs.
Adoption creates no compliance obligation, because the MHC have no normative basis in the ISO 27001 sense. It documents the deliberate engagement with the Mythos threat landscape and gives internal and external auditors a traceable basis. For organizations subject to regulation that already requires an MHC content, adoption coincides with an existing obligation. That applies only within the respective scope, however: MHC-12 corresponds to the TLPT requirements for those DORA-regulated financial entities identified for TLPT under Art. 26(8) — not for all DORA addressees. MHC-11 operationalizes the NIS2 and Implementing Regulation requirements on detection, response and recovery; a SOAR system or automated tier 1 containment is not prescribed there across the board.
Regulatory references per MHC
References from the Implementation Guides (section “standards touched”, without any claim of fulfilment). MHC without a reference to NIS2, DORA, the CRA or the AI Act are not listed; their basis lies in BSI C5:2026, NIST or OWASP, for example.
| MHC | NIS2 / NIS2 IR | DORA | CRA | EU AI Act |
|---|---|---|---|---|
| MHC-02 SBOM and Build Provenance | NIS2 IR No. 5 | DORA Art. 28 | CRA Annex I (SBOM obligation for manufacturers of products with digital elements | – |
| MHC-03 Phishing-Resistant MFA | NIS2 IR No. 11.6 and No. 11.7, for privileged accounts additionally No. 11.3.2(a) | – | – | – |
| MHC-05 Behavior-Based Detection | NIS2 IR No. 3.2 | DORA Art. 10 | – | – |
| MHC-08 Immutable Backups | NIS2 IR No. 4.1 | DORA Art. 12 | – | – |
| MHC-09 AI-Assisted Security Testing | – | – | CRA Annex I | – |
| MHC-10 Continuous Control Monitoring | NIS2 IR No. 2.2 | DORA Art. 6(5) | – | – |
| MHC-11 SOAR and Tier-1 Automation | NIS2 IR No. 3.5 | DORA Art. 17 | – | – |
| MHC-12 Threat-Led Penetration Testing | NIS2 IR No. 3.5.5 | DORA Art. 26/27 with the TLPT RTS | – | – |
| MHC-13 AI Agent Governance | – | – | – | Art. 3, 6, 12, 13, 14, 15, 19, 25, 26, 50 (via MRIS.bd, see below) |
| MHC-14 Independent Verification of Supplier Evidence | – | DORA Art. 30(3) | – | – |
The NIS2 IR numbers come from Implementing Regulation (EU) 2024/2690, which applies only to certain digital providers. For other NIS2 entities, the national transposition is decisive.
EU AI Act: AI agents in IT-Grundschutz
The module family MRIS.bd maps individual requirements informatively to provisions of Regulation (EU) 2024/1689 (AI Act) as amended by Regulation (EU) 2026/1744. The mapping is not a requirement; the AI Act itself is decisive.
| MRIS.bd | Requirement | MHC | AI Act (role) – applies to |
|---|---|---|---|
| MRIS.bd.1.A6 | Regulated Use of AI Agents | MHC-13 | Art. 3(3) i. V. m.(11) (provider); Art. 3(4) (deployer); Art. 6, Art. 50 (both) – all AI systems. Role and classification give rise to legal obligations that are not requirements of this module family, for example the technical documentation of a high-risk AI system by the provider (Art. 11 in conjunction with Annex IV); implemented via ORP.5. Art. 25(1) (deployer) – high-risk AI system Art. 26(2) (deployer) – high-risk AI system |
| MRIS.bd.2.4.A2 | Logging the Actions of the AI Agent | MHC-13 | Art. 12(1) (provider) – high-risk AI system Art. 19(1) (provider); Art. 26(6) (deployer) – high-risk AI system. Retention for at least six months |
| MRIS.bd.2.4.A3 | Ensuring Human Oversight of the AI Agent | MHC-13 | Art. 14(4)(e) (provider); Art. 26(2) (deployer) – high-risk AI system Art. 14(4)(d) (provider); Art. 26(2) (deployer) – high-risk AI system |
| MRIS.bd.2.4.A5 | Reviewing the Agent Controls Before Production Release | MHC-13 | Art. 15(5) (provider) – high-risk AI system. Whoever develops an AI system and puts it into service under its own name for own use is a provider (Art. 3(3) in conjunction with (11)). Art. 26(1) in conjunction with Art. 13 (deployer) – high-risk AI system Art. 15(5) (provider) – high-risk AI system |
Framework mapping for twelve core topics
The following table summarizes, for twelve central subject areas of information security, how the primary frameworks address each. It is an orientation aid, not a complete mapping.
| Subject area | ISO 27002 | C5:2026 | NIST CSF | DORA | CRA | NIS2 IR |
|---|---|---|---|---|---|---|
| Asset management | A.5.9, A.5.12 | AM-02, AM-03, AM-04, AM-09 | ID.AM | Art. 8 | Annex I | No. 12 |
| Identity and access | A.5.15, A.5.16, A.8.2 | IAM-01, IAM-06, IAM-08 | PR.AA | Art. 9 | Annex I | No. 11 |
| Cryptography | A.8.24 | CRY-01 to CRY-19 | PR.DS | Art. 9(4)(e) | Annex I II | No. 9 |
| Logging and monitoring | A.8.15, A.8.16 | OPS-10 to OPS-17 | DE.CM | Art. 10 | - | No. 3.2 |
| Incident response | A.5.24, A.5.26 | SIM-01 to SIM-06 | RS. | Art. 17, 19 | - | No. 3.1 to 3.6 |
| Business continuity | A.5.29, A.5.30, A.8.13 | BCM-01 to BCM-04, OPS-06 to OPS-09 | RC. | Art. 11, 12 | - | No. 4 |
| Supply chain | A.5.19 to A.5.23 | SSO-01 to SSO-08, DEV-13 | GV.SC | Art. 28-30 | Annex I II | No. 5 |
| Development | A.8.25 to A.8.29 | DEV-01 to DEV-15 | PR.IR | Art. 8(3) | Annex I II | No. 6 |
| Physical security | A.7.1 to A.7.14 | PS-01 to PS-08 | PR.IR | Art. 9(4) | - | No. 13 |
| Risk management | A.5.1 to A.5.8 | OIS-07, OIS-08, OIS-09 | GV.RM, ID.RA | Art. 6, 7 | - | No. 2 |
| Compliance | A.5.31 to A.5.36 | COM-01 to COM-04 | GV.OC | Art. 6(5) | Art. 13, 14 | No. 2.2, 2.3 |
| Cloud use | A.5.23 | GC-01 to GC-06, OPS-30 to OPS-35 | GV.SC-07 | Art. 28 | - | No. 5 |
Empty cells (-) mean that the framework states no specific requirement of its own for the subject area concerned. The NIST CSF column names the respective categories from CSF 2.0; concrete implementation is via SP 800-53.
Note on the scope of the NIS2 IR: The numbers cited in the "NIS2 IR" column are taken from Implementing Regulation (EU) 2024/2690, which under its Article 1 applies exclusively to certain digital providers (see Chapter 3.3). For other NIS2 addressees, the notification deadlines from NIS2 Directive Art. 23(4) in conjunction with the respective national transposition govern.
Source: MRIS for ISO/IEC 27001, edition 2.0 (PDF), CC BY-SA 4.0. MRIS Implementation Guide (ISO/IEC 27001), edition 2.0 (PDF), CC BY-SA 4.0. MRIS.bd 2.0 (YAML), CC BY-SA 4.0. Chapter references in the text refer to the respective PDF edition.