The Compliance Trifecta
If your organisation operates in the European Union and handles information systems of any significance, you are likely subject to at least two of three regulatory instruments: ISO 27001:2022 (voluntary but increasingly expected by clients and regulators), NIS2 (Directive EU 2022/2555, transposition deadline October 17, 2024), and DORA (Regulation EU 2022/2554, applicable since January 17, 2025).
The instinct in many organisations is to treat each as a separate compliance project — separate risk assessments, separate policy sets, separate audit cycles, separate teams. This is the most expensive possible approach. It generates what DPO Consulting has described as "documentation fatigue for teams and an explosion of audit costs."
The alternative is a unified control framework: one set of controls, one risk register, one evidence library, mapped to satisfy all three regulatory obligations simultaneously. ISO 27001:2022 provides the management system foundation. The question is not whether it covers enough — it does, for the majority of requirements. The question is where the specific gaps lie, and how to close them without rebuilding what already works.
This article provides the control-by-control mapping, identifies every gap, and lays out a practical integration strategy.
The Three Frameworks at a Glance
Before mapping controls, it helps to understand the structural differences between what we are aligning.
ISO 27001:2022 is a management system standard. It specifies 93 controls across four themes — Organisational (37), People (8), Physical (14), and Technological (34) — and a management system framework (Clauses 4–10) that governs how those controls are implemented, monitored, and improved. It is risk-based and non-prescriptive: organisations choose which controls to implement based on their own risk assessment.
NIS2 is a directive. It establishes 10 minimum security measures (Article 21(2)(a–j)) that all essential and important entities must implement, along with incident reporting obligations (Article 23) and management body accountability requirements (Article 20). The European Commission estimates that over 160,000 entities across 18 sectors now fall within scope — a tenfold increase from the original NIS Directive.
DORA is a regulation — directly applicable, no transposition required. It is organised around five pillars: ICT Risk Management (Articles 5–16), Incident Management (Articles 17–23), Digital Operational Resilience Testing (Articles 24–27), ICT Third-Party Risk Management (Articles 28–44), and Information Sharing (Article 45). DORA is prescriptive where ISO 27001 is flexible. It tells financial entities exactly what to do, when to test, how to report, and what contracts must contain.
Where ISO 27001 Already Covers NIS2
The overlap is substantial. Advisera's published mapping analysis concludes that ISO 27001 addresses 25 of 26 NIS2 cybersecurity requirements. DataGuard and Cyberday converge on an estimate that full ISO 27001:2022 compliance delivers approximately 80% coverage of NIS2 obligations.
The following table maps each of NIS2's 10 minimum security measures (Article 21(2)) to their corresponding ISO 27001:2022 controls.
| NIS2 Article 21(2) Measure | ISO 27001:2022 Controls | Coverage |
|---|---|---|
| (a) Risk analysis and information system security | Clauses 6.1.2, 6.1.3; A.5.1, A.5.2, A.5.7 | Full |
| (b) Incident handling | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.6.8 | Partial — no prescribed reporting timelines |
| (c) Business continuity, backup, disaster recovery, crisis management | A.5.29, A.5.30, A.8.13, A.8.14 | Partial — crisis management not covered |
| (d) Supply chain security | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23, A.8.30 | Partial — NIS2 extends to non-ICT suppliers |
| (e) Security in acquisition, development, maintenance; vulnerability handling | A.8.8, A.8.9, A.8.20, A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 | Full |
| (f) Assessing effectiveness of risk management measures | Clauses 9.1, 9.2, 9.3; A.5.35, A.5.36 | Full |
| (g) Basic cyber hygiene and cybersecurity training | A.6.3, Clause 7.2, A.8.5, A.8.7 | Full |
| (h) Cryptography and encryption | A.8.24 | Full |
| (i) Human resources security, access control, asset management | A.5.9, A.5.15–A.5.18, A.6.1–A.6.5, A.8.2, A.8.3, A.8.5 | Full |
| (j) Multi-factor authentication, secured communications | A.5.14, A.5.16, A.5.17, A.8.5, A.8.20, A.8.21 | Full |
Seven of the ten measures are fully covered by existing ISO 27001 controls. Three require supplementary measures — and these are precisely the areas where organisations trip up during NIS2 compliance assessments.
Where ISO 27001 Already Covers DORA
DORA's five pillars map extensively to ISO 27001, particularly in the first two pillars.
| DORA Pillar | Key Articles | ISO 27001:2022 Controls | Coverage |
|---|---|---|---|
| 1. ICT Risk Management | Arts. 5–16 | Clauses 6.1.2, 6.1.3; A.5.1, A.5.7, A.5.29, A.5.30, A.8.8, A.8.9, A.8.13–A.8.16 | Substantial — gaps in governance specificity |
| 2. Incident Management | Arts. 17–23 | A.5.24–A.5.28, A.6.8, A.8.15, A.8.16 | Partial — no reporting timelines or classification taxonomy |
| 3. Resilience Testing | Arts. 24–27 | A.5.35, A.8.29, Clauses 9.1, 9.2 | Major gap — no TLPT equivalent |
| 4. Third-Party Risk | Arts. 28–44 | A.5.19–A.5.23, A.8.30 | Major gap — prescriptive contracts, CTPP oversight |
| 5. Information Sharing | Art. 45 | A.5.5, A.5.6, A.5.7 | Partial — A.5.7 covers consumption, not structured sharing |
The qualitative consensus from compliance practitioners (GRC Solutions, Toreon, CEEYU, DPO Consulting) is that ISO 27001 provides the structural foundation for DORA compliance across risk management, business continuity, and incident management. The material gaps are concentrated in Pillars 3 and 4 — and these are precisely the areas where DORA is most prescriptive.
The Gaps — Where ISO 27001 Falls Short
Understanding the gaps is more valuable than understanding the overlaps. These are the requirements that will generate non-conformances if addressed only through an ISO 27001 lens.
Gap 1: Incident Reporting Timelines
ISO 27001 requires an incident management process (A.5.24–A.5.28) but prescribes no reporting timelines to competent authorities. Both NIS2 and DORA impose strict deadlines.
| Obligation | NIS2 (Art. 23) | DORA (Art. 19) |
|---|---|---|
| Early warning / initial notification | 24 hours | 4 hours after classification (max 24h from detection) |
| Detailed notification | 72 hours | 72 hours |
| Final report | 1 month | 1 month |
The critical distinction for DORA: the 4-hour clock starts from incident classification, but the 24-hour outer limit starts from detection. This requires organisations to have rapid triage capability — not just detection, but classification processes that can operate within hours.
Organisations subject to both NIS2 and DORA must meet the stricter timeline. In practice, this means building for DORA's 4-hour requirement.
Remediation: Build a tiered incident notification workflow into your ISMS incident management procedure. Define classification criteria upfront, pre-draft notification templates, and establish 24/7 escalation paths to the individuals authorised to submit regulatory notifications.
Gap 2: Management Body Personal Liability
NIS2 Article 20 and DORA Article 5 both impose direct personal accountability on management body members. This has no equivalent in ISO 27001.
NIS2 Article 20 requires that management bodies approve cybersecurity risk management measures, undergo mandatory cybersecurity training, and bear individual personal liability for oversight failures. Competent authorities can temporarily prohibit individuals from exercising managerial functions until compliance is achieved.
DORA Article 5 requires that the management body define, approve, oversee, and be responsible for the ICT risk management framework. Members must "actively keep up to date" with ICT risk knowledge through specific regular training.
ISO 27001 Clause 5.1 requires leadership commitment to the ISMS, but this is collective organisational responsibility. It creates no individual personal liability, no named-director training requirements, and no basis for personal sanctions.
Remediation: Establish a documented board-level cybersecurity governance programme with per-director training records, formal approval logs for risk management measures, and evidence of periodic management body review of ICT risk posture.
Gap 3: DORA's Threat-Led Penetration Testing (TLPT)
DORA Article 26 requires significant financial entities to conduct full red-team penetration testing of live production systems at minimum every three years, following the TIBER-EU framework. The testing must cover critical and important business functions. Significant credit institutions must use external testers. Purple teaming — structured collaboration between the red team and the internal blue team — is mandated.
ISO 27001 A.8.29 covers security testing in development and acceptance environments but specifies no method, no frequency, no live-system requirement, and no external tester mandate. The gap between ISO 27001's flexible testing approach and DORA's prescriptive TLPT regime is substantial.
Remediation: For financial entities subject to TLPT requirements, engage qualified external red-team providers and build a formal resilience testing programme that satisfies both DORA Article 26 and the EBA's Regulatory Technical Standards on TLPT (JC 2024-29).
Gap 4: Prescriptive Third-Party Contractual Requirements
ISO 27001's supplier controls (A.5.19–A.5.23) address supplier risk management through a risk-based lens. DORA Article 30 prescribes the exact content of ICT service contracts for critical and important functions — including ESA audit rights through the contract, mandatory exit plan testing, sub-contractor transparency, and provider-side incident reporting obligations.
Commission Delegated Regulation (EU) 2024/1773 specifies the detailed contractual provisions that must be included. This level of prescriptiveness has no equivalent in ISO 27001.
Additionally, DORA Article 28 requires financial entities to maintain a formal register of all ICT third-party arrangements, reported annually to competent authorities. Before contracting for critical functions, entities must notify competent authorities. Exit strategies must be documented and tested.
On November 18, 2025, the European Supervisory Authorities designated 19 Critical Third-Party Providers (CTPPs) under DORA, including major cloud providers. These CTPPs are now subject to direct ESA oversight — a regulatory mechanism that has no parallel in any voluntary standard.
Remediation: Review all ICT service contracts against DORA Article 30 requirements. Establish a formal ICT provider register. Build tested exit strategies for critical function providers. Ensure contracts include ESA audit rights, incident notification obligations, and sub-contractor disclosure requirements.
Gap 5: Crisis Management
Advisera's mapping analysis identifies crisis management as the single NIS2 requirement (within Article 21(2)(c)) that ISO 27001 does not cover at all. ISO 27001 addresses business continuity at the ICT level through A.5.29 and A.5.30 — backup, recovery, and continuity readiness. It does not address crisis communications, crisis command structures, or coordination with governmental crisis response mechanisms as envisaged under NIS2.
Remediation: Supplement ISO 27001's business continuity controls with crisis management procedures aligned to ISO 22301 or equivalent. Ensure crisis management plans include communication protocols, governmental liaison procedures, and documented command structures.
Gap 6: DORA's Incident Classification Taxonomy
DORA Article 18 establishes a sector-specific incident classification taxonomy with six mandatory criteria: client/counterpart impact, duration, geographic spread, data losses, service criticality, and economic impact. The ESAs published materiality thresholds via Commission Delegated Regulation (EU) 2024/1347, with an economic impact threshold of EUR 100,000.
ISO 27001's incident management controls (A.5.24–A.5.28) contain no sector-specific classification criteria, no financial thresholds, and no mandatory regulatory taxonomy.
Remediation: Adopt DORA's classification taxonomy within your ISMS incident management procedure. Map it against the RTS materiality thresholds so that incident handlers can classify events against regulatory criteria in real time.
Controls That Satisfy All Three Simultaneously
The efficiency case for a unified framework becomes clearest when examining specific controls that map to multiple regulatory obligations at once. These are the highest-value controls in an integrated compliance programme.
A.5.24 — Incident Management Planning: Satisfies NIS2 Article 21(2)(b) incident handling requirements and DORA Article 17 ICT-related incident management process. The internal process foundation serves both regulations — only the reporting timelines and classification taxonomy need to be layered on top.
A.5.19–A.5.23 — Supplier and Supply Chain Security: This five-control cluster maps directly to NIS2 Article 21(2)(d) supply chain security and partially to DORA Articles 28–30 third-party risk management. It also covers GDPR Article 28 processor agreements, creating a four-regulation intersection point.
A.5.30 — ICT Readiness for Business Continuity: New in ISO 27001:2022, this control was specifically designed to align with NIS2 and DORA-type requirements. It satisfies NIS2 Article 21(2)(c) business continuity and directly supports DORA Articles 11–12 ICT continuity policy and plans. Its addition in the 2022 revision partially closed a gap that existed in the 2013 edition.
A.8.9 — Configuration Management: Also new in 2022, this control maps to NIS2 Article 21(2)(e) security in network and information systems and DORA Article 9 protect and prevent requirements. Both regulations require documented configuration baselines and change management.
A.8.24 — Use of Cryptography: The cleanest single-control mapping in the entire framework. This one control fully satisfies NIS2 Article 21(2)(h) — policies and procedures regarding cryptography and encryption — while simultaneously addressing DORA Article 9 encryption requirements.
A.6.3 — Information Security Awareness, Education and Training: Maps to NIS2 Article 21(2)(g) cyber hygiene and training, and to DORA Articles 13–14 learning and communication requirements. However, it does not fully satisfy NIS2 Article 20(2)'s management body training mandate, which requires per-director, individually documented and assessed training.
Building the Integrated Control Framework
The practical implementation follows a clear sequence.
Step 1: Start with ISO 27001:2022 as the Management System
ISO 27001 provides the only certified management system framework among the three instruments. Its Plan-Do-Check-Act cycle, mandatory internal audit programme, and management review process create the governance structure within which NIS2 and DORA controls can be implemented, monitored, and improved.
ENISA's own NIS2 Technical Implementation Guidance (published June 2025) includes an official mapping table from NIS2 requirements to ISO 27001 controls — effectively endorsing ISO 27001 as the reference framework for NIS2 implementation.
Step 2: Map Controls to Regulatory Requirements
For each ISO 27001 Annex A control, document which NIS2 Article 21(2) measure(s) and which DORA pillar requirement(s) it satisfies. This creates a single control register with multi-regulation traceability. When evidence is collected for an ISO 27001 surveillance audit, that same evidence is automatically available for NIS2 and DORA compliance demonstrations.
Step 3: Close the Gaps with Targeted Supplementary Controls
Based on the gap analysis above, the supplementary controls needed are concentrated in six areas: incident reporting workflows with regulatory timelines, management body governance and training programmes, TLPT programme (financial entities), prescriptive third-party contractual provisions, crisis management procedures, and DORA-specific incident classification taxonomy.
These represent approximately 20% additional effort beyond a mature ISO 27001 implementation — significant, but far less than building three separate compliance programmes from scratch.
Step 4: Unify Evidence Collection
A single evidence library tagged against all three frameworks eliminates the most common source of compliance cost: producing the same evidence in different formats for different auditors. Incident records, risk assessments, supplier reviews, and policy documents are created once, stored once, and mapped to all applicable regulatory requirements.
Step 5: Align Audit Cycles
Where possible, align ISO 27001 surveillance audits with NIS2 and DORA compliance assessments. Advisera has published guidance on performing internal audits simultaneously for all three frameworks. A unified internal audit programme that covers ISO 27001 clauses, NIS2 Article 21 measures, and DORA pillar requirements in a single cycle reduces audit burden and surfaces cross-framework gaps that siloed audits miss.
The Role of Framework Mapping Technology
Manual framework mapping — maintaining spreadsheets that correlate ISO 27001 controls to NIS2 measures and DORA articles — works for initial alignment. It does not scale when regulations update, controls change, or the organisation's scope expands.
The challenge compounds in operational technology environments, where organisations must additionally map against sector-specific frameworks such as IEC 62443, NIST SP 800-82, and the NIS2 implementing acts for critical infrastructure sectors. A manufacturing company subject to NIS2 may need to correlate controls across ISO 27001, NIS2, IEC 62443, and DORA (if it provides services to financial sector entities) — four frameworks with overlapping but non-identical control sets.
This is precisely the problem that framework mapping tools are designed to solve. Orizon's FrameworkMapper, available at otmap.orizon.sh, uses AI-assisted correlation to map controls across frameworks including ISO 27001, IEC 62443, NIST CSF, and EU regulatory requirements. It generates confidence-scored mappings with structured rationales, identifying where controls satisfy multiple obligations and where gaps require attention — reducing what is typically weeks of manual analysis to hours of verified, auditable output.
The principle applies regardless of which tool an organisation uses: framework correlation should be systematic, auditable, and maintainable over time. The regulatory landscape is not static — ENISA has already published implementing guidance with mapping tables, and the ESAs continue to issue Regulatory Technical Standards that refine DORA's requirements. A mapping that exists only in a spreadsheet snapshot will drift out of alignment within months.
What Comes Next
The regulatory convergence trend is accelerating. The Cyber Resilience Act (Regulation EU 2024/2847) entered force on December 10, 2024, with reporting obligations beginning September 11, 2026 and full obligations applying from December 11, 2027. The AI Act's high-risk system requirements take effect August 2, 2026. Each new instrument creates additional control mapping requirements.
Organisations that build unified control frameworks now — anchored to ISO 27001:2022 with systematic mapping to NIS2 and DORA — are building infrastructure that can absorb these additional regulatory requirements without starting from scratch. Organisations that treat each regulation as a separate project are accumulating compliance debt that compounds with every new instrument.
The framework exists. The mappings are documented. The gaps are known. The remaining question is execution.
Sources
EU Legal Texts
- NIS2 Directive (EU 2022/2555) — Article 21, Article 23, Article 20, Article 34 — eur-lex.europa.eu
- DORA Regulation (EU 2022/2554) — Articles 5, 17–19, 24–27, 28–30, 35, 45 — eur-lex.europa.eu
- Commission Delegated Regulation (EU) 2024/1347 — DORA RTS on incident classification — esma.europa.eu
- Commission Delegated Regulation (EU) 2024/1773 — DORA RTS on contractual provisions — eur-lex.europa.eu
- EBA Final Report JC 2024-29 — DORA RTS on TLPT — eba.europa.eu
Framework Mapping Sources
- ENISA, NIS2 Technical Implementation Guidance (June 2025) — includes official ISO 27001 to NIS2 mapping table — enisa.europa.eu
- Advisera, NIS 2 vs. ISO 27001 Mapping — advisera.com
- DataGuard, NIS2 ISO 27001 Mapping — dataguard.com
- CEEYU, Is ISO 27001 Enough for NIS2? — ceeyu.io
- CEEYU, Is ISO 27001 Enough for DORA? — ceeyu.io
- nis2compliant.org, Implementing NIS2 Cybersecurity Measures — Mapping with ISO 27001
- Seeburger, EU-NIS2 Verification Through Mapping to ISO 27001 Controls — blog.seeburger.com
DORA-Specific Sources
- Toreon, Integrating EU DORA with ISO 27001 — toreon.com
- GRC Solutions, How DORA Fits with ISO 27001, NIS2 and GDPR — grcsolutions.io
- CREST, Threat-Led Penetration Testing (TLPT) Under DORA — crest-approved.org
- EBA, ESAs Designate Critical ICT Third-Party Providers Under DORA (November 2025) — eba.europa.eu
Integrated Compliance Guidance
- DPO Consulting, ISO 27001, NIS2 and DORA: Building Sustainable Cyber Compliance in 2026 — dpo-consulting.com
- Clarysec, Beyond the Firewall: ISO 27001, NIS2, DORA Management System — blog.clarysec.com
- SureCloud, DORA vs NIS-2 vs ISO 27001: A Framework Comparison Guide — surecloud.com
- Cyberday, Comparing EU Cybersecurity Frameworks — cyberday.ai
ISO 27001:2022 Control References
- DataGuard, ISO 27001 Annex A Controls: Overview of All Measures — dataguard.com
- High Table, ISO 27001 Annex A Controls: The Complete 2022 Reference List — hightable.io
- ISMS.online, ISO 27001:2022 Annex A Explained — isms.online