NIS2 and DORA: Key Differences and Overlaps

At the end of 2024 and beginning of 2025, the European market saw two major cybersecurity and digital resilience frameworks enter into force in a very short period: NIS2 in October 2024 and DORA in January 2025. For many organizations, especially in the financial and technology sectors, the immediate question was the same: does one apply to us, the other, or both? What happens when they coincide?

The confusion is understandable. Both frameworks share terminology, general objectives and some similar technical requirements. But they have different legal natures, different scopes and a logic of interaction that has important practical consequences for organizations that must comply with one or both.

Different origins and legal natures

The first difference, and the most relevant for understanding everything else, is one of legal nature.

NIS2 is a European directive. Directives are not directly applicable in Member States: they require transposition into national law. Each Member State transposes the directive through its own legislation, allowing some margin of adaptation in thresholds, penalties and supervisory mechanisms. This means the concrete NIS2 requirements applying to a company are established by national transposition legislation, not by the directive text directly. Understanding what NIS2 is and how it applies in practice provides the necessary starting context before analyzing a specific company’s position.

DORA is a European regulation. Regulations are directly applicable in all Member States from their entry into force date, without transposition. This gives DORA greater legal uniformity across the EU: requirements are the same in Spain, Germany, France and the Netherlands without significant national variations.

This distinction has a practical consequence: DORA is more predictable in its specific requirements than NIS2, because it does not depend on how each Member State transposed the directive.

Scope: who falls under each framework

Scope is where NIS2 and DORA diverge most clearly.

NIS2 has a broad sectoral scope. It covers highly critical sectors (energy, transport, banking, financial market infrastructures, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration and space) and important sectors (postal services, waste management, chemicals, food, critical product manufacturing, digital providers and research). The key for determining whether a company is within scope is the sector it operates in and its size.

DORA has a sector-specific scope: the financial sector. It applies to credit institutions, investment firms, payment and electronic money institutions, crypto-asset service providers under MiCA, alternative investment fund managers, occupational pension funds, insurers, credit rating agencies, statutory auditors and, significantly, third-party ICT service providers deemed critical for financial entities. This last category is the most contentious because it includes technology companies that are not financial entities themselves but provide services to them.

The lex specialis principle: what happens when both frameworks apply

Article 4 of NIS2 explicitly establishes that when Member States apply the directive to entities already subject to equivalent sectoral regulation, they must take into account the provisions of that sectoral regulation to avoid duplication. In practice, this means financial entities subject to DORA are not required to additionally comply with NIS2 risk management and incident requirements separately, because DORA is considered the specific framework (lex specialis) for that sector.

However, the exemption is not total in all respects. NIS2 remains relevant for financial entities in aspects that DORA does not cover completely, such as certain national supervision obligations or notification to national CSIRTs in specific scenarios. The exact interaction between the two frameworks is being developed further through the European Supervisory Authorities (ESAs) and national supervisors.

The most complex scenario is that of ICT providers serving the financial sector: they may be classified as important or essential entities under NIS2 as digital service providers, and simultaneously fall under direct DORA supervision if designated as critical providers by the ESAs. In that case, both frameworks run in parallel.

Key differences in requirements

Although NIS2 and DORA share general objectives, their specific requirements differ in several important ways.

Resilience testing. DORA establishes a digital operational resilience testing program with two levels: basic annual tests for all entities (including vulnerability assessments and gap analyses), and advanced threat-led penetration tests (TLPT, Threat-Led Penetration Testing) for the most significant entities every three years. NIS2 requires security controls but does not specify a testing regime as detailed or prescriptive.

Third-party ICT management. DORA dedicates an entire chapter to third-party ICT risk management, with very specific requirements on vendor contracts (mandatory minimum clauses, vendor audits, exit plans). It also creates a direct supervisory regime by the ESAs for critical ICT providers, meaning a cloud or financial software company can receive inspection visits from European regulators even though it is not itself a financial entity. NIS2 also requires supply chain management, but with less detail and without direct oversight of the provider by European financial authorities.

Incident notification. Both frameworks require rapid notification of significant incidents, but recipients and content details differ. DORA requires notification to the competent financial supervisory authority (ECB, EBA, EIOPA or ESMA depending on entity type), with classification of major/relevant incidents. NIS2 requires notification to the national CSIRT. For a financial entity affected by a significant incident, the first recipient is the financial supervisory authority under DORA, but there may also be a concurrent NIS2 obligation to notify the national CSIRT.

Governance and management accountability. Both frameworks establish senior management accountability, but DORA is more specific: it requires the management body to formally approve the ICT resilience strategy, be responsible for its implementation and receive regular training on ICT risks. NIS2 establishes similar management accountability but leaves more margin to each organization to define how that governance is structured.

Overlaps: what both frameworks share

The overlaps are substantial and, well managed, allow building a single program that produces evidence valid for both frameworks.

ICT risk management. Both NIS2 and DORA require a formal, documented process for identifying, assessing and treating cybersecurity risks. Methodology differs in detail, but the asset inventory, threat and vulnerability assessment, and risk treatment decision register are common elements that are built once. A 5×5 risk assessment matrix provides a methodological foundation applicable to both frameworks.

Business continuity and disaster recovery. Continuity and recovery plans are an explicit requirement in both frameworks, focusing on cyberattack scenarios. The difference lies in the detail of continuity testing: DORA requires plans to be regularly tested with documented criteria, NIS2 requires they exist but with less prescription on testing frequency and methodology.

Staff training and awareness. Both frameworks require staff cybersecurity training as a minimum measure. A NIS2, ISO 27001 and GDPR training checklist covers elements that also apply under DORA, meaning a well-designed training program can satisfy the requirements of all three frameworks simultaneously.

Incident management. Although notification recipients differ, the operational capacity for incident management (detection, classification, containment, recovery and post-incident documentation) is a shared requirement that is implemented once.

Critical ICT providers: the category falling under both frameworks

The most complex case in the NIS2-DORA intersection is technology companies providing services to the financial sector.

Under NIS2, a cloud computing service provider, data center provider or managed security service provider may be classified as important or essential entity if they exceed size thresholds and fall into the digital infrastructure or B2B ICT services categories of the directive.

Under DORA, that same provider may be designated by the ESAs as a “critical third-party ICT provider” (CTPP) if a significant number of European financial entities depend on their services for critical or important functions. CTPP designation under DORA means subjection to a direct supervision program by European authorities, including inspection visits and information requests.

For those providers, both frameworks run in parallel. The ESAs have published their first lists of CTPPs and are developing supervision programs. Companies in that position must structure their compliance program so that evidence is valid before both supervisory authorities.

How to build a program covering both NIS2 and DORA

The governing principle is the same as for any regulatory overlap: build the common controls once with sufficient specificity to satisfy both frameworks, and identify the differential requirements of each to add them incrementally.

The common controls built once are: management-approved security policy, critical asset and system inventory, risk assessment with documented methodology, incident management process with the notification timelines of both frameworks already integrated, continuity plan with cyberattack scenarios, and staff training program.

The DORA-specific requirements added on top are: the resilience testing program with TLPT where applicable, specific ICT vendor contract documentation per DORA minimum clauses, ICT critical provider exit plans, and third-party information registers in the ESA-required format.

How PrivaLex helps

The question generated by the NIS2-DORA intersection is not purely technical: it is legal, operational and strategic at the same time. The decision to classify a company as an important entity under NIS2, or to treat it as out of scope because it is covered by DORA, can radically change the volume of work and the cost of the compliance program. And treating DORA as the only applicable framework when NIS2 is still relevant in certain respects can create gaps that surface in an inspection months later.

PrivaLex works with financial entities, ICT providers and companies operating in sectors covered by NIS2 through a structured four-phase process:

Phase 1. Scope analysis. We determine precisely whether the organization falls within the scope of NIS2, DORA, both, or neither. In group structures, the analysis covers each entity separately: it is possible for a subsidiary to be an essential entity under NIS2 while another falls only under DORA. For organizations operating in the Spanish market, we incorporate the updated transposition status and national criteria on NIS2 in Spain.

Phase 2. Differential gap analysis. We conduct a separate gap analysis for each applicable framework, using the regulatory requirements directly rather than generic checklists. The output is an inventory of existing controls, partially implemented controls and absent controls, with traceability to the specific articles of NIS2 or DORA that require them. When both frameworks apply, we explicitly identify which controls cover both simultaneously and which are exclusive to one, to avoid duplicating work.

Phase 3. Program design and implementation. We build the program starting from the common layer, then adding the DORA-specific requirements that have no NIS2 equivalent (resilience testing program, third-party registers, minimum ICT contractual clauses, critical provider exit plans) and the NIS2 requirements that DORA does not cover for entities in dual scope.

Phase 4. Evidence documentation and supervision preparation. The work does not end when controls are implemented: it ends when those controls are documented in a way that a supervisory authority can verify them. We prepare the complete documentary set (security policy, risk assessment reports, incident registers, ICT contracts with DORA clauses, resilience testing report) and support the organization through its first inspection if one takes place.

We regularly work with mid-sized financial entities completing their DORA program who need to verify their NIS2 position, with cloud or SaaS providers serving banking or insurance clients who need to understand whether they fall into scope as CTPPs, and with fintech companies operating at the intersection of both frameworks who need a program that does not duplicate work or generate contradictory evidence before different supervisors.

Conclusion

NIS2 and DORA are neither interchangeable nor redundant. They have different scopes, different legal natures and requirements that diverge in key areas such as resilience testing and ICT provider oversight. Where they overlap, the efficiency lies in building common controls once. Where they diverge, the specific requirements of each framework need to be added incrementally on top of that foundation. Confusing the two frameworks or assuming that complying with one exempts from the other are the most costly mistakes organizations make when beginning their analysis.

If you want to know which frameworks apply to your organization and what gaps you have against each, request your free risk assessment or book a session with our team.

Frequently Asked Questions