DORA vs NIS2: which rules apply to a financial entity
If a financial entity covered by DORA has been told that NIS2 also applies, the short answer is that DORA is the sector-specific act for it. Under Article 1(2) of DORA, read with Article 4 of NIS2, DORA's ICT risk management, incident management and reporting, resilience testing, information sharing and ICT third-party rules replace the equivalent NIS2 provisions, and NIS2's supervision and enforcement provisions are disapplied (NIS2 Article 4(1) and recital 28). In practice, the risk management program, incident classification and reporting, and provider contracts are built once to DORA, not twice to two regimes. The remaining question is which NIS2 obligations, if any, still bite, and that depends on three things: the entity type under DORA Article 2(1), whether the entity is classed as essential or important under NIS2, and what the member state has chosen to do.
The third factor is the one most often missed. DORA Article 19(1) lets each member state require financial entities to send copies of their DORA incident reports to NIS2 authorities or CSIRTs, and Article 19(6)(c) requires competent authorities to share incident details with those bodies. So the same incident can reach two national authorities even though only one regime governs the obligation. Ask your national competent authority and your national NIS2 authority, in writing, whether copies are required, through which channel, and on what template. Also confirm how your entity is recorded under NIS2 if you are a regulated financial entity that is also designated as essential or important, because that status affects which authority is informed and whether it may join oversight discussions.
Plan for timing rather than content differences. The NIS2 clock (an early warning within 24 hours, a notification within 72 hours and a final report within one month) is not the DORA clock (an initial notification within 4 hours of classification as major and within 24 hours of awareness, an intermediate report within 72 hours and a final report within one month of the latest intermediate report). Build your incident workflow to the DORA timings, then confirm with each national authority whether any copy must follow a different schedule. The European Commission's Digital Omnibus proposal COM(2025) 837 would route both sets of reports through a single entry point, but as of October 2026 it is still awaiting committee decision, so treat today's dual routing as the working rule.
Where DORA and NIS2 differ on timelines and penalties
This table compares application dates, incident reporting clocks and penalty regimes for DORA and NIS2 side by side. Read each row as the rule that applies to a financial entity covered by both acts, and check the DORA column first because DORA's lex specialis rules displace NIS2 for ICT risk, incident reporting and testing. The main takeaway is that the reporting clocks differ in start point and first deadline, while fine levels are set very differently.
| Aspect | DORA | NIS2 |
|---|---|---|
| Legal form | Regulation, directly applicable in all member states without national transposition | Directive, transposed into national law |
| Application date | From 17 January 2025 | Transposition due 17 October 2024; national measures applied from 18 October 2024 |
| First incident notification | Initial notification within 4 hours of classifying an incident as major, and within 24 hours of becoming aware of it | Early warning within 24 hours of becoming aware of a significant incident |
| Second report | Intermediate report within 72 hours of the initial notification | Incident notification within 72 hours of becoming aware |
| Final report | Final report within one month of the latest intermediate report | Final report within one month of the incident notification |
| Maximum administrative fines | Left to member states under Article 50 of DORA | At least EUR 10 million or 2 % of worldwide annual turnover for essential entities; at least EUR 7 million or 1.4 % for important entities |
| EU-level financial sanctions | Periodic penalty payments on critical ICT third-party providers, up to 1 % of average daily worldwide turnover | None set at EU level beyond the maximum fine ranges |
| Who applies the rules to a dual-scope financial entity | DORA governs ICT risk, incident reporting, testing and ICT third-party risk; NIS2 provisions on these topics do not apply | NIS2 supervision and enforcement do not apply to those DORA-covered areas |
Which obligations DORA takes over from NIS2
Recital 28 of NIS2 names six areas where DORA's provisions apply instead of NIS2's for financial entities covered by DORA. For each area, the practical question is the same: which DORA artefact already answers the NIS2 duty, and where does a separate NIS2 record still need to exist. The cards below treat each area as a mapping exercise, not a second compliance program.
ICT risk management framework
Covers the governance, risk framework, protection and recovery controls that NIS2 Article 21 would otherwise require. Map the DORA ICT risk management framework and its review report as the single record for these measures, and confirm that the management body's approval covers both regimes. Do not build a parallel Article 21 risk register; instead, add a short note listing where each NIS2 measure is addressed in the DORA framework, so a NIS2 authority asking for it can find it quickly.
Incident management process
Incident detection, handling and classification are run once, under DORA's rules for major incidents. Map the DORA incident management process as the operational procedure, and add only the NIS2-specific fields and clocks your national authority requires. Confirm with your competent authority whether NIS2 reporting is handled through DORA channels, because member states may require copies of DORA reports to NIS2 authorities or CSIRTs under Article 19(1).
Incident reporting clocks
The NIS2 and DORA clocks differ, so a single incident can produce two deadline sets. Map the DORA timeline (initial notification, intermediate report and final report) as the controlling schedule for financial entities, and record the NIS2 early warning and notification dates alongside it in the same incident file. Do not run separate case handling for each regime. Confirm in advance which authority receives which report and in what format.
Resilience testing programme
DORA's testing programme, including basic testing of ICT tools and systems and threat-led penetration testing where it applies, covers the testing NIS2 would expect. Map the DORA testing plan and its results as the evidence base, and avoid commissioning a second testing cycle purely for NIS2. Check whether your national NIS2 authority asks for test reports in a particular form, and keep a cross-reference table in the testing file rather than duplicating findings.
Information sharing arrangements
DORA Article 45 covers voluntary exchange of cyber threat information among financial entities, which NIS2 would otherwise treat through its own information-sharing provisions. Map existing DORA sharing arrangements, including the terms, participants and confidentiality rules, as the governing record. Confirm whether any NIS2 information-sharing obligation applies to your entity beyond what DORA covers, and document that check so it is not repeated each year.
ICT third-party risk register and contracts
Your ICT provider inventory, contractual clauses, exit plans and oversight records satisfy DORA's third-party requirements, which replace NIS2 supply-chain duties for covered entities. Map the DORA register of information and contract files as the single supplier record. Do not maintain a separate NIS2 supplier list. Where a provider is itself a NIS2 essential or important entity, confirm with that provider how its NIS2 authority interacts with DORA oversight, since the framework is stated to be without prejudice to NIS2.
Penalty exposure and authority scope
Penalty exposure differs sharply. NIS2 sets fixed EU-level maximum fines for essential and important entities, while DORA leaves administrative penalties for financial entities to member states. Confirm which authority supervises your entity under each regime, and map the penalty assessment to the regime your national authority applies. Treat the NIS2 penalty table as a reference point only, and confirm the applicable national figures with counsel before budgeting.
How incident information flows between authorities
The core point for a financial entity that is also an NIS2 essential or important entity is that one DORA incident report may end up with two sets of authorities. Article 19(1) of DORA lets member states require financial entities to send copies of their DORA incident reports to NIS2 authorities or CSIRTs. Whether your entity must do this depends on the national choice made in each member state where you operate, so you should confirm with your competent financial authority and any national NIS2 authority exactly what must be copied, to whom, through which channel and on what timing. Until that is written down, your incident runbook cannot show a complete reporting path.
On the receiving side, Article 19(6)(c) requires competent authorities to share incident details with NIS2 authorities, single points of contact or CSIRTs. This means your financial supervisor may pass on information about your incident without you sending a second copy yourself. Do not treat that as a reason to skip your own notifications. Check that your reports contain the fields your financial supervisor and any NIS2 recipient will need, and that the classification you give under DORA is consistent with what you tell any NIS2 body, so the authorities do not receive conflicting accounts of the same event.
For critical ICT third-party providers, the flow works in the other direction. Under Articles 32(4)(e) and 42(5), where a critical provider is also an NIS2 essential or important entity, its NIS2 authority may join the Oversight Forum as an observer and may be consulted before the ESAs decide on suspending a service. Article 32(8) states that the oversight framework is without prejudice to NIS2. Providers should confirm whether any of their group entities fall under NIS2 in each member state, and financial entities relying on those providers should ask in due diligence how a suspension decision would be communicated and whether the provider's NIS2 obligations could affect service continuity in their exit planning.
What the Digital Omnibus single entry point would change
This sequence explains what the Commission's Digital Omnibus proposal would change for DORA and NIS2 incident reporting, and what to track before any change takes effect. Each step ends with an output you can file or monitor.
Confirm the current reporting rules still apply
Start from the rules in force today. DORA Article 19 and the NIS2 incident reporting deadlines apply as written in the Regulation and the Directive, and the proposal changes nothing until it is adopted and applied. Your compliance lead should record the current DORA incident reporting process and the NIS2 notification route used by your national authority, dated to the review. The output is a signed-off reporting procedure that reflects today's law.
Read COM(2025) 837 against the existing articles
Review the Commission's proposal of 19 November 2025 with your legal and compliance teams. The proposal would amend DORA Article 19 so that major incident reports and voluntary threat notifications pass through a single entry point, and would add a new NIS2 Article 23a requiring both NIS2 and DORA incident reports to be submitted that way. Map each changed provision to your current reporting workflow. The output is a short memo listing which of your reporting steps would change and which would stay the same.
Track procedure 2025/0360(COD) in Parliament
Monitor the European Parliament Legislative Observatory entry for procedure 2025/0360(COD). As of October 2026 the procedure is awaiting committee decision, so the text can still change in the legislative process. Assign a named owner to check the status on a fixed cadence and log each change, such as a committee vote, amendment or Council position. The output is a dated status record that shows the procedure stage you are relying on.
Ask your national authority for transition guidance
Contact the competent authority that supervises your entity, and the NIS2 authority or CSIRT that receives your notifications if they differ. Ask how they plan to handle reports during any transition, whether they expect to receive copies under the current Article 19 arrangements, and which channels they will use. Record the answers in writing. The output is a written response or published guidance from each authority, stored with your reporting procedure.
Check the single entry point with your reporting tools
Ask your incident management, SIEM and case management vendors, or your internal platform team, how their reporting workflows would adapt to a single entry point if the proposal is adopted. Confirm which templates, identifiers and data fields your tools already produce for DORA and NIS2 reports. Where a capability is unclear, record it as an open question rather than an assumption. The output is a tool-by-tool gap list with an owner for each open item.
Brief the management body on the open risk
Present the proposal, its current stage and the reporting rules in force to the management body, which remains accountable for ICT risk management under DORA. Explain that planning should assume today's dual-track reporting until the legislation changes, and that any change would need a documented transition. The output is a minuted briefing with the decisions taken and the review date set.
Re-test the reporting plan on each legislative change
Each time the procedure moves, or a national authority publishes new guidance, update the reporting procedure and rerun a tabletop exercise on a major incident report. Confirm that the team can still meet the deadlines that apply on the day of the exercise. The output is an updated procedure version and an exercise record that names any gaps found and the owner who will close them.
How the overlap affects banks, payment firms and their ICT providers
A financial entity that is identified as essential or important under NIS2 sits under two laws at once. Article 1(2) of DORA makes it a sector-specific Union act for the purposes of NIS2's Article 4, and NIS2 recital 28 says DORA's provisions on ICT risk management, incident handling, resilience testing, information sharing and ICT third-party risk apply in place of NIS2's equivalent provisions. In practice, DORA is the rulebook for these obligations, and the NIS2 risk-management and reporting duties are not applied in parallel.
- Rulebook for security duties: DORA Chapters II to V govern ICT risk management, incident reporting and third-party risk. NIS2 Article 21 measures are not a second checklist to run alongside them.
- Reporting clock: DORA's major incident deadlines apply, which differ from NIS2 Article 23(4) timings. Confirm the exact sequence with your competent authority.
- Penalties: NIS2's fine ceilings are disapplied for covered obligations, while DORA leaves administrative penalties to member states under Article 50.
- Copies to NIS2 authorities: Under Article 19(1), a member state may require copies of DORA incident reports to go to NIS2 authorities or CSIRTs. Ask your regulator whether it does.
- Contracts: Customers and providers will write DORA Article 30 clauses into agreements, not NIS2 supply chain language.
The organization owns the risk decisions, incident classification, board accountability and regulatory relationship. An implementation partner can prepare the incident runbooks, evidence packs and reporting templates. Confirm in writing which NIS2 duties your national authority still expects you to meet directly.
Many financial entities are not identified under NIS2 at all, or they fall outside its scope for reasons of size or sector. DORA still applies to them directly because it applies to the 20 types of financial entity listed in Article 2(1). For these organizations, DORA is the only EU operational resilience rulebook in the picture, so NIS2 does not shape their obligations, reporting clock or supervision.
- Single rulebook: DORA sets the ICT risk framework, incident reporting, testing and third-party requirements without a NIS2 overlay.
- Proportionality: Article 4 and the simplified regime may reduce some obligations depending on entity type. Verify your classification with your competent authority.
- Supervision: The national competent authority for your entity type supervises compliance under Article 46, with no NIS2 authority in the chain.
- Information flows: Article 19 sharing rules may still matter if a member state links DORA reports to other bodies. Ask your authority how it handles this.
- Contract expectations: Customers still impose DORA-based clauses on their ICT suppliers, even where NIS2 is not in play.
The organization owns its classification decision, the policies, the register of information and the board sign-off. An implementation partner can prepare the documentation, gap assessment and testing evidence. Do not assume that being out of NIS2 scope reduces the DORA workload.
ICT providers are not financial entities, so DORA reaches them mainly through the contracts their financial customers sign and, for the largest providers, through direct oversight. Article 2(1)(u) lists ICT third-party service providers within DORA's scope. A provider that is also an essential or important NIS2 entity has its own NIS2 duties, and DORA Articles 32(4)(e) and 42(5) allow its NIS2 authority to take part in oversight discussions.
- Customer-driven obligations: Financial customers will demand incident assistance, audit rights, subcontracting conditions and exit support under DORA.
- Possible NIS2 duties: If the provider is itself an essential or important entity, NIS2 obligations apply to it in addition to the DORA contract terms.
- Critical designation: Only a provider designated by the ESAs as critical faces direct oversight, including oversight plans and fees.
- Information requests: Expect requests for identifiers and register data under the DORA register of information.
- Single entry point: The Digital Omnibus proposal COM(2025) 837 would route reports through one entry point. It is not law yet.
The provider owns its service controls, subcontractor oversight and incident handling. An implementation partner can help map customer clauses to controls and prepare evidence. Confirm with each customer which DORA clauses it will require and whether your NIS2 status changes your duties.
Questions buyers ask about DORA and NIS2 overlap
Does DORA replace NIS2 for a bank?
For most purposes covered by DORA, yes. DORA is a sector-specific Union act for financial entities that NIS2 treats as essential or important entities, so the DORA rules on ICT risk management, incident management and reporting, resilience testing, information sharing and ICT third-party risk apply in place of the corresponding NIS2 provisions. NIS2 recital 28 says member states should not apply the NIS2 risk-management, reporting, supervision and enforcement provisions to financial entities covered by DORA. A bank still needs to confirm with its national authority how its specific situation is handled, because member states have some room to decide how DORA reports reach NIS2 authorities under Article 19(1).
Must a payment institution report the same incident twice?
Not necessarily, but it may need to plan for it. Under DORA Article 19(1), a member state can require financial entities to send copies of their DORA incident reports to NIS2 authorities or CSIRTs. Whether that applies depends on national law, so the institution should ask its competent authority which channel and format it must use. Its DORA deadlines differ from NIS2's: DORA requires an initial notification within 4 hours of classification as major and within 24 hours of awareness, while NIS2 Article 23(4) sets a 24-hour early warning. Map both timelines into one incident runbook so the first notification is never late. The Digital Omnibus proposal could later route both report types through a single entry point, but that proposal is still awaiting committee decision.
What must our organization do itself, and what can a partner prepare?
Your organization owns its controls, decisions and sign-offs. Management remains accountable for ICT risk, the policies must be approved by the management body, and incident classification and reporting decisions must be made by your staff. An implementation partner can help prepare systems, configuration, logging, documentation drafts, mapping workbooks and evidence packs, and can run security testing you have scoped. Only an independent auditor or a supervisor's process assesses compliance. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure and prepares evidence, but it does not issue audit reports, attestations or certifications. Agree the split of responsibilities in writing before the work starts.
How long does mapping DORA to NIS2 take?
The effort depends on your entity type, the number of ICT services, how many NIS2 obligations apply to you directly and how much of your current framework already covers DORA. A bank with many outsourced ICT services and a payment institution with a small stack will need very different work. The reliable starting points are the dates in the legal texts: DORA has applied since 17 January 2025, and NIS2 national measures have applied since 18 October 2024. Ask any provider for a phased plan tied to written scope, covering which entities, services, reporting channels and systems are included, rather than a fixed duration. Confirm the expected timing with your competent authority as well.
Does a certificate prove we are compliant with both DORA and NIS2?
No. No certificate proves DORA compliance, and DORA sets no certification scheme. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). A certificate from a third party covering an ISO or other framework can support your evidence file, but it does not establish dual compliance with DORA and NIS2. Supervisors will look at your governance, documentation, testing, incident records and contracts, and they can ask for that evidence at any time.
What should we confirm with our national authority?
Start with the questions that the Regulation leaves to member states. Ask which authority supervises your entity, whether DORA incident reports must be copied to a NIS2 authority or CSIRT under Article 19(1), which channel and template to use, and how the competent authority will share incident details under Article 19(6)(c). Also ask how your entity is treated if it is identified as essential or important under NIS2, and how national penalties apply under Article 50. Record the answers in writing and keep them with your compliance evidence. Check the official texts on EUR-Lex as well, since national practice can change.
Could a single reporting entry point change our process?
It could, but nothing has changed yet. The Commission's Digital Omnibus proposal COM(2025) 837 would require both NIS2 and DORA incident reports to go through a single entry point under a new NIS2 Article 23a. As of October 2026, the European Parliament's Legislative Observatory lists the procedure 2025/0360(COD) as awaiting committee decision. Until a change is adopted and applies, keep your current DORA and NIS2 reporting channels. Design your incident tooling so that report routing can be changed by configuration rather than rebuilt, and review the proposal's status before each planning cycle.
How to check a DORA and NIS2 advisor before signing
An advisor working on DORA and NIS2 must understand how the two regimes connect, how the timelines differ and what the national authority expects. The cards below set out the checks to run before signing, and each one should be answered in writing.
Understanding of Article 1(2) and recital 28
Ask the advisor to explain, in their own words, how Article 1(2) of DORA makes it a sector-specific act for NIS2 purposes and how recital 28 directs member states to apply DORA's rules instead of NIS2's to covered financial entities. A capable advisor will identify which NIS2 provisions fall away for your entity and which still apply, such as obligations that sit outside the DORA areas. Vague answers here usually lead to duplicated controls and reporting.
National authority position
Ask which competent authority supervises your entity under DORA and whether that authority, or the NIS2 authority or CSIRT in your member state, has issued guidance on how the two regimes interact. The answer should name the authorities and the documents, and the advisor should say where their view depends on national choices. Ask them to flag any point where member states have not yet settled the position.
Incident timeline mapping
Ask the advisor to show, in a written table, how a single incident maps to the DORA initial notification, intermediate and final reports and to the NIS2 early warning, notification and final report. The table should make clear which clock starts first, since DORA counts from classification as major and NIS2 counts from awareness of a significant incident. Ask how they handle an incident that triggers both regimes on different dates.
No certificates or attestations
Confirm the advisor does not claim to issue a DORA certificate, a compliance attestation or a NIS2 certificate. Under DORA, the only authority-issued attestation covered by the Regulation is the one for a threat-led penetration test that met the requirements. The advisor should prepare evidence and readiness for supervisors, while independent assessors and authorities make determinations. Treat any promise of a certificate as a warning sign.
Scope and deliverables in writing
Check that the scope, deliverables, dates and responsibilities are agreed in writing before work starts. The document should list which DORA and NIS2 obligations are covered, which are excluded, and which parties own each control and each piece of evidence. Ask how changes in scope are priced and approved, and whether the agreement covers any change to the Digital Omnibus proposal if it is adopted.
Fit with the authority workflow
Ask who on the national authority side will receive the work product and how it will be used in supervision, reporting or information flows between DORA and NIS2 authorities. The advisor should be able to describe the expected evidence path and which internal staff must sign off. Confirm that your own compliance and management body remain accountable for the content they submit.
How DeployOpen prepares DORA and NIS2 evidence for your team
DeployOpen works on the DORA and NIS2 overlap as an implementation partner. We prepare the self-hosted open-source platforms, controls and evidence your team needs, inside your own infrastructure. The organization owns its compliance position, and only an independent auditor or competent authority reaches conclusions on it.
How we scope
- Written scope agrees which financial entity or ICT service the DORA and NIS2 work covers before any work starts.
- We map which systems fall under DORA ICT risk rules and which fall under NIS2 measures, with the lex specialis position confirmed by your counsel.
- Scope documents name the authorities expected to receive incident reports so reporting channels are defined from the start.
How we build
- We implement and harden self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks.
- Logging, backup, access and incident workflows are configured to produce the timestamps and records the DORA and NIS2 reporting clocks require.
- Controls are tested against the requirements of Regulation (EU) 2022/2554 and Directive (EU) 2022/2555 before handover.
How we hand over
- Deliverables include configuration records, runbooks, and evidence packs mapped to the specific articles in scope.
- Documentation states which steps your team owns, such as signing policies and submitting reports to authorities.
- Handover sessions walk your staff through the reporting process so they can run it without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work closes.
- Retainers can cover updates when the Digital Omnibus change to a single reporting entry point is adopted, after confirming its final text.
- Your independent auditor or assessor receives the evidence you choose to share, and the organization decides what goes to authorities.
