NIS2, DORA & ISO 27001: Navigating the 2026 Compliance Landscape

NIS2 enforcement began in October 2024. DORA became applicable to EU financial entities in January 2025. ISO 27001:2022 transition deadlines expire in October 2025. For many organizations, these three frameworks are converging simultaneously — and the compliance teams responsible for them are stretched thin. Understanding what each framework actually requires, where they overlap, and how to prioritize effort is the difference between a coordinated compliance programme and an expensive, duplicated scramble.

This guide provides a practical breakdown of each framework's requirements, who is in scope, the specific obligations that are most commonly missed, and how to build a single control environment that satisfies all three without tripling your compliance workload.

NIS2 Deep Dive: What Article 21 Actually Requires

Article 21 of NIS2 specifies the minimum security measures that Essential and Important entities must implement. These are not aspirational guidelines — they are mandatory obligations against which national authorities will audit. The ten required measures are:

1. Policies on risk analysis and information system security. A documented, regularly reviewed risk management policy that identifies assets, threats, and acceptable risk levels.
2. Incident handling. Documented procedures for detecting, classifying, responding to, and recovering from cybersecurity incidents — including a 24-hour early warning to the national authority for significant incidents.
3. Business continuity, backup management, and disaster recovery. Tested plans for maintaining essential services during and after a significant cyber incident, including backup procedures verified through regular recovery testing.
4. Supply chain security. Security requirements for relationships with direct suppliers and service providers, including contractual security obligations and regular supplier security assessments.
5. Security in network and information systems acquisition, development, and maintenance. Secure development practices, vulnerability management, and patch management across the full system lifecycle.
6. Policies and procedures to assess the effectiveness of security measures. Defined metrics, regular audits, and testing programmes — including penetration testing where appropriate — to verify that security measures are functioning as intended.
7. Basic cyber hygiene practices and cybersecurity training. Mandatory security awareness training for all staff; role-specific training for security personnel; basic cyber hygiene standards (MFA, patching, access control).
8. Policies and procedures regarding the use of cryptography and encryption. Documented standards for cryptographic algorithm selection, key management, and encryption of sensitive data in transit and at rest.
9. Human resources security, access control policies, and asset management. Background checks where appropriate; access control based on least-privilege; joiners/movers/leavers process; documented asset inventory.
10. The use of multi-factor authentication or continuous authentication solutions, and secured emergency communication systems. MFA is explicitly mandated — it is not optional under NIS2 for any Essential or Important entity.

DORA's ICT Risk Requirements for Financial Entities

DORA's five pillars each come with detailed Regulatory Technical Standards (RTS) published by the European Supervisory Authorities. The pillars operate as a coherent framework, not a checklist — weakness in one creates cascading failures in the others.

1. ICT Risk Management Framework. A documented, board-approved ICT risk management framework that identifies, classifies, and manages ICT risks. Unlike NIS2, DORA explicitly requires the management body to approve the framework and take personal responsibility for its adequacy.
2. ICT-Related Incident Management and Reporting. A three-tier reporting obligation: initial notification within 4 hours of classifying an incident as major; intermediate report within 72 hours; final report within one month. "Major incident" classification criteria are defined in RTS — financial entities must have classification procedures in place before an incident occurs.
3. Digital Operational Resilience Testing. Annual basic ICT testing for all entities; threat-led penetration testing (TLPT) every three years for significant entities. TLPT must be conducted by qualified external testers following the TIBER-EU framework.
4. ICT Third-Party Risk Management. A complete registry of all ICT third-party providers with an assessment of concentration risk. Contractual requirements are prescribed — contracts with critical ICT providers must include specific clauses covering audit rights, data portability, exit strategy, and security standards.
5. Information and Intelligence Sharing. Financial entities are encouraged (and in some member states may be required) to participate in threat intelligence sharing arrangements — providing an early warning network for emerging threats.

ISO 27001:2022 — What Changed and What It Means

The 2022 revision of ISO 27001 is the most significant update since the 2013 version. Organizations with 2013 certifications must complete their transition by October 2025 — after which 2013 certifications will no longer be recognized.

Prioritising When You Are Subject to Multiple Frameworks

Organizations subject to two or all three frameworks do not need to build three separate compliance programmes. The frameworks share significant control overlap — particularly around risk management, access control, incident response, and supply chain security. A single control environment, mapped to each framework's requirements, satisfies all three at roughly 60-70% of the cost of three independent programmes.

Five Compliance Mistakes That Trigger Enforcement

These are the patterns that national authorities have publicly identified in enforcement guidance and early audit findings through 2025.

1. Assuming NIS2 scope has not changed from the original NIS Directive. NIS2 expanded scope dramatically — it covers medium-sized enterprises (50+ employees, €10M+ turnover) in 18 sectors, not just large critical infrastructure operators. Organizations that were out of scope under NIS1 should re-assess their status under NIS2 before an authority does it for them.
2. Missing the 24-hour notification window. NIS2 requires an early warning to the national competent authority within 24 hours of becoming aware of a significant incident. Many organizations have incident response plans that detect, contain, and then report — but the NIS2 early warning obligation requires notification before full analysis is complete. IR plans must explicitly include the early warning step as a parallel activity, not a sequential one.
3. Treating ISO 27001 certification as a compliance substitute. ISO 27001 is a valuable governance framework, but it is not a legal compliance mechanism. It does not satisfy NIS2 obligations by itself (though it helps demonstrate some requirements). DORA's ICT risk management obligations go beyond ISO 27001's scope in financial-sector-specific areas. Do not use certification as a shield — use it as a foundation.
4. Underestimating DORA's management liability provisions. DORA makes senior management personally accountable for ICT risk management framework adequacy — and allows supervisory authorities to impose personal fines of up to €5 million on responsible individuals. This is not a technicality; management must actively engage with and approve ICT risk decisions, not delegate them entirely to the IT department.
5. Building separate compliance programmes for each framework. Organizations that run parallel NIS2, DORA, and ISO 27001 programmes without a shared control environment waste resources and create inconsistencies that auditors find during reviews. A unified control framework with framework-specific mapping documentation is both more efficient and more defensible.