DORA Certifications Bundle
399 € excl. VAT
Interactive Comparison
DORA vs NIS2
Two EU frameworks. One landscape. Find out in 30 seconds which one applies to you, where they overlap, and how a single platform covers both.
Two EU frameworks. One landscape. Find out in 30 seconds which one applies to you, where they overlap, and how a single platform covers both.
Digital Operational Resilience Act
Regulation (EU) 2022/2554
Network & Information Security 2
Directive (EU) 2022/2555
A 3-step decoder. No forms, no signup: just click your way to the answer.
As a medium or large financial entity, both regulations apply. DORA prevails as lex specialis for the requirements both texts cover (incident reporting, third-party risk, governance). NIS2 still applies to areas DORA does not address, for example general cybersecurity hygiene at corporate level. In practice, full DORA compliance covers ~80% of equivalent NIS2 obligations; the remaining gaps must be assessed against your national NIS2 transposition.
Recommended action: use DORA as your primary framework, run a NIS2 gap assessment against the national transposition, document the equivalence mapping and consolidate evidence in a single platform.
Microenterprises and small financial entities below NIS2 size thresholds typically fall outside NIS2 scope. DORA still applies in full, but you may benefit from the simplified ICT risk management framework (Article 16). Some Member States extend NIS2 to small entities under specific conditions: verify with your national authority.
→ Start with CIF identification · Free 5-min DORA assessment
Large financial entities operating critical infrastructure stack three regimes: DORA (operational resilience), NIS2 (baseline cybersecurity) and national critical-infrastructure rules (e.g. France's LPM/IIV, Germany's KRITIS). DORA prevails for ICT-risk topics; NIS2 fills cyber-baseline gaps; national CII rules add bespoke obligations on top. Plan for three reporting flows and three competent authorities.
Cloud hyperscalers, datacentres, DNS and other digital infrastructure are directly subject to NIS2. They are contractually subject to DORA via the mandatory clauses (RTS 2024/1773) imposed by their financial-entity customers. If designated as a Critical ICT Third-Party Provider (CTPP) under DORA Articles 31-44, they fall under direct ESA oversight as well. The first list of designated CTPPs was published in late 2025.
Managed Service Providers (MSP/MSSP) are explicitly listed in NIS2 Annex II as "essential" or "important" entities. You also inherit DORA obligations through contracts with your financial-entity customers: mandatory clauses, audit rights, sub-contracting controls (RTS 2025/532). Building a single control framework that satisfies both is the only way to scale.
Even if you are below NIS2 size thresholds, your financial-entity customers will require you to accept DORA-mandated contractual clauses: incident notification, audit rights, exit plan, sub-contracting authorisation, jurisdiction. Refusal usually means contract loss. Plan early.
Non-financial entities in NIS2 sectors are only subject to NIS2. Your obligations come from your national transposition, not from DORA. However, if you provide ICT services to a financial entity, DORA-style contractual clauses will be imposed on you indirectly. Use NIS2 as your primary framework; track DORA developments to anticipate flow-down clauses from financial customers.
This site focuses on DORA: for NIS2-only entities, refer to your national CSIRT / competent authority.
Public administrations are covered by NIS2, with member-state discretion on scope and obligations. Most countries combine NIS2 transposition with sector-specific rules for government bodies. DORA does not apply unless the public body operates regulated financial activity.
Click each zone to explore who is covered, what each regime imposes uniquely, and where DORA and NIS2 intersect.
Intensity of each obligation theme: from 0 (not addressed) to 5 (highly prescriptive). The redder, the more granular and binding the requirement.
DORA and NIS2 milestones on a single timeline. Top track = DORA. Bottom track = NIS2. Yellow markers = both.
Forty percent of EU financial entities will face dual DORA + NIS2 exposure. Treating each as a separate programme triples cost. Run them as one.
Build your primary control framework around DORA: it is the most prescriptive of the two and acts as lex specialis. Cover the 5 pillars: ICT risk, incidents, testing, third-party risk, information sharing.
Identify NIS2 obligations not satisfied by DORA: cyber awareness training (Art. 20), national CSIRT cooperation (Art. 10-15), EU-CyCLONe coordination, sectoral baseline measures applicable beyond financial activity.
Produce a DORA-NIS2 equivalence matrix. Each NIS2 obligation maps to either: (a) a DORA control covering the same matter, (b) a NIS2-only delta with its own control. Supervisors will ask for this matrix.
Run both programmes from one system. The Register of Information feeds NIS2 supply-chain security, the BIA feeds both ICT risk frameworks, incidents are reported once with two destinations. Stop duplicating.
Resiplan is the specialised SaaS for DORA, business continuity and GRC: designed for EU financial entities and the ICT providers who serve them. Every module produces evidence valid for both regulations, with native equivalence mapping. One CIF inventory, one Register of Information, one incident workflow, two compliance certificates.
DORA (Regulation EU 2022/2554) entered into force on 17 January 2025 and applies directly across all EU member states without requiring national transposition. It covers 21 types of financial entities: from banks and insurers to crypto-asset service providers and payment institutions, plus their critical ICT third-party providers.
DORA is the financial sector's answer to the growing recognition that ICT risk is not just a technical issue but a systemic financial stability risk. It builds on existing EBA, EIOPA, and ESMA guidelines and replaces them with legally binding obligations.
NIS2 (Directive EU 2022/2555) replaces the original NIS Directive (2016) and sets a baseline cybersecurity standard for "essential" and "important" entities across 18 sectors including energy, transport, health, digital infrastructure, and financial markets.
As a Directive, NIS2 required transposition into national law by 17 October 2024. Implementation progress varies across member states: as of early 2026, several countries are still finalising their national frameworks, creating a patchwork of obligations.
DORA Article 2 applies to:
NIS2 Annex I & II cover entities in:
Small payment institution below NIS2 size thresholds. Subject to DORA proportionality rules, but not NIS2 "essential"/"important" designation.
Large bank or major insurer. Covered by both: DORA prevails for overlapping requirements. NIS2 fills remaining gaps.
IT managed service provider that serves financial entities but is not itself a financial entity. Subject to NIS2 directly (and DORA contractually through its customers).
AWS, Azure, Google Cloud: covered by NIS2 as digital infrastructure providers. Subject to DORA contractually via financial entity customers. Potentially designated as CTPPs under DORA direct oversight.
The table below compares the key obligations across both frameworks. Where DORA and NIS2 address the same topic, DORA's requirement is the binding one for financial entities.
| Requirement | DORA | NIS2 |
|---|---|---|
| Incident reporting | 3-stage process: initial report within 4 hours of classification as major; interim report within 72 hours; final report within 1 month. Reported to national competent authority (NCA). | 2-stage process: early warning within 24 hours of becoming aware; full notification within 72 hours. Optional final report within 1 month. Reported to CSIRT or NCA. |
| Risk management | ICT-specific, 5 pillars: governance, protection, detection, response/recovery, learning. Detailed RTS on methodology (RTS 2024/1774). Management body directly accountable. | General cybersecurity risk management. 10 minimum measures (Art. 21) including policies, incident handling, business continuity, supply chain, access controls, MFA, cryptography, HR security. |
| Third-party oversight | Comprehensive: Register of Information mandatory (xBRL-CSV format); 15+ contractual clauses required (Art. 30); CTPP framework with direct ESA oversight of 19 designated providers; concentration risk assessment. | Supply chain security requirements: entities must address cybersecurity risks in the supply chain (Art. 21(2)(d)). No register mandate, no direct supplier oversight framework. |
| Resilience testing | Full programme: vulnerability assessments, network security assessments, scenario-based testing, source code reviews. TLPT mandatory for designated significant entities (every 3 years). RTS specifies methodology. | Security testing required as part of risk management policies, but no TLPT mandate. National authorities may impose specific testing requirements on essential entities. |
| Penalties | No EU-wide cap. Art. 50 requires Member States to empower competent authorities and leaves the amount to national law, the ceiling depends on the country. CTPPs: 1% of average daily worldwide turnover (Art. 35). Member States may add criminal penalties (Art. 52). | Essential entities: Member States must provide for a maximum of at least EUR 10,000,000 or at least 2% of total worldwide annual turnover in the preceding financial year, whichever is higher (Art. 34(4)). Important entities: at least EUR 7,000,000 or at least 1.4% (Art. 34(5)). These are floors on the national maximum, not EU-wide ceilings. Management liability provisions. |
| Supervision model | Multi-level: ESAs (EBA, EIOPA, ESMA) issue binding RTS and guidelines; NCAs supervise individual financial entities; JOC oversees CTPPs directly. Cross-border: ESA coordination. | National competent authorities (NCAs) designated by each member state. NIS2 Cooperation Group for cross-border coordination. No pan-EU supervisory body equivalent to ESAs. |
| Information sharing | Voluntary information sharing arrangements encouraged (Art. 45). ESAs may share threat intelligence with entities. CTPPs subject to incident notification to ESAs. | Member states must establish national CSIRTs; peer-to-peer sharing encouraged. CyCLONe network for large-scale incidents. EU-CyCLONe for crisis management. |
| Governance | Management body (board) formally accountable for ICT risk (Art. 5). Board must approve ICT risk framework, receive regular reports. Individual board member training required. | Management bodies must approve risk management measures and are personally liable for infringements (Art. 20). Training for management recommended but not prescribed in detail. |
Need the full RTS text? All 13 DORA technical standards are available in our free reference guide.
Browse All RTS/ITS StandardsYour obligations depend on your organisation type and the sectors you operate in. The scenarios below cover the most common situations.
DORA is your primary compliance framework. Full DORA compliance satisfies all equivalent NIS2 obligations. Your NCA will supervise you under DORA. NIS2 applies only to areas DORA does not cover (e.g. some physical security aspects). Focus 95% of your resources on DORA.
You face NIS2 obligations directly (as a cloud service, data centre, or managed service provider) AND DORA contractual obligations through your financial entity customers. Largest risk: being designated as a CTPP under DORA, triggering direct ESA oversight. Align NIS2 baseline with DORA contractual requirements. they are largely complementary.
In scope for DORA as a payment institution or e-money institution. May also qualify as NIS2 "important entity" depending on size and national transposition. Use DORA as your compliance backbone. Verify NIS2 designation with your national authority. DORA's proportionality provisions (Art. 16) may reduce your burden if you are a small entity.
Regulated financial subsidiaries: DORA. Non-financial subsidiaries in NIS2 sectors (energy, transport, health): NIS2 only. Group-level: consider implementing a unified security baseline that satisfies both, with DORA-level requirements applied to all critical ICT shared services. Legal entity mapping is essential.
Yes, if you are a financial entity that also qualifies as an "essential" or "important" entity under NIS2 (e.g. a large bank, major payment institution, or financial market infrastructure). However, DORA acts as lex specialis: where DORA and NIS2 requirements overlap, DORA takes precedence for financial entities.
In practice, full DORA compliance will satisfy most equivalent NIS2 obligations. The areas where NIS2 adds obligations beyond DORA are relatively narrow: mainly around national CSIRT coordination, physical security elements, and some aspects of supply chain security. Verify the specific gap with your national competent authority and legal counsel.
DORA takes precedence for financial entities covered by both regulations. Article 1(2) of DORA explicitly states that it constitutes a lex specialis to NIS2 (Directive 2022/2555) for entities within its scope. DORA's more specific and sector-tailored requirements override NIS2's general obligations wherever the two instruments cover the same matter.
NIS2 obligations continue to apply in areas not addressed by DORA. For example, DORA does not prescribe detailed physical security measures for data centres: NIS2's general requirements would fill that gap.
No. Neither DORA nor NIS2 replaces the GDPR. The three frameworks address different aspects of digital governance and may all apply simultaneously:
A single ICT incident at a bank may simultaneously trigger DORA incident reporting (4h initial notification to NCA), NIS2 early warning (24h to CSIRT), and GDPR breach notification (72h to data protection authority), on different timelines and to different authorities.
DORA creates indirect obligations for ICT providers through the contractual requirements placed on financial entities (Article 30). Providers designated as Critical ICT Third-Party Providers (CTPPs) are subject to direct ESA oversight, but this applies to only 19 designated providers as of November 2025.
NIS2 also covers ICT providers that qualify as "digital infrastructure" entities (cloud services, data centres, DNS, internet exchange points, managed service providers). A hyperscaler like AWS or Azure may therefore face: direct NIS2 obligations in their own right, DORA contractual obligations through financial entity customers, and potential DORA direct oversight as a CTPP.
See the full list of 19 designated CTPPs for which providers are subject to direct DORA oversight.
Run them as one programme, not two. Anchor on DORA as the primary framework (it is the most prescriptive and acts as lex specialis) then map the NIS2 deltas: the areas NIS2 covers that DORA does not address.
Produce an equivalence matrix showing how each NIS2 obligation is satisfied, either by an existing DORA control or by a NIS2-only delta control. That matrix is what a supervisor asks for when the two regimes meet, and it is also what stops you from building the same control twice.
One, if the tool genuinely shares its underlying data. The test is whether the same record serves both regimes rather than being entered twice:
If a platform stores two disconnected registers, you have bought two tools with one invoice. Resiplan is one platform built on that shared-data model; the criteria above apply whichever you assess.
DORA mandates harmonised templates (RTS 2025/301) with strict 4h / 72h / 1-month deadlines for major ICT-related incidents, reported to a single competent financial authority per Member State.
NIS2 imposes an early warning within 24h, an incident notification within 72h and a final report within one month, but without harmonised templates: the format depends on the national CSIRT or competent authority.
For financial entities subject to both, DORA reporting prevails as lex specialis: the same incident is reported once, through the DORA channel.
The two regimes are built differently. DORA sets no EU-wide maximum fine for financial entities: Article 50 leaves administrative penalties to national law, so the amount depends on the Member State. The only turnover-based percentage in the Regulation applies to designated critical ICT third-party providers (periodic penalty payments capped at 1% of average daily worldwide turnover, Article 35).
NIS2, by contrast, sets explicit EU-level floors on national caps. NIS2: Directive (EU) 2022/2555, Article 34(4) covers essential entities and NIS2: Directive (EU) 2022/2555, Article 34(5) covers important entities.
So NIS2 gives you a number you can look up; DORA sends you to your national regime. Read the full DORA penalties regime before quoting any figure: the "2% of global turnover" often attributed to DORA belongs to NIS2, not to DORA.
Not sure where you stand across the 5 DORA pillars? Our free tools help you benchmark your current posture and prioritise remediation.
Free Gap Analysis Download DORA Guides All RTS/ITS StandardsMost EU financial institutions running AI are in scope of both. They overlap far less than people assume.
Operational resilience of your ICT estate: risk framework, incident reporting, third-party oversight, testing.
The AI system itself: classification, data governance, human oversight, conformity assessment, transparency.
A bank scoring credit with a bought model is a DORA entity and an AI Act deployer. Two regimes, one system.
Workbooks, playbooks and certifications built for EU financial entities. Add several to your cart: volume discounts apply automatically.
Take our free 5-minute assessment and get an instant DORA compliance score with personalised recommendations.