DORA and NIS2 Overlap Mapping Guide

Groups that contain both financial entities and other regulated businesses often end up running two separate EU cyber compliance programmes, with duplicated controls, conflicting incident clocks and two sets of evidence for the same systems. DORA (Regulation (EU) 2022/2554) and NIS2 (Directive (EU) 2022/2555) were negotiated together and are designed to fit: for financial entities DORA is the sector-specific law that displaces most of NIS2. The difficulty is in the edges, such as non-financial group companies, ICT providers that are themselves NIS2 entities, and national transposition. This guide maps who falls under which regime, where the requirements line up, where they differ, and how to run one control and evidence set that satisfies both. It is for CISOs, compliance and risk teams in financial groups and their ICT providers.

Key takeaways

DORA is lex specialis for financial entities. Article 1(2) of DORA and Article 4 of NIS2 mean a financial entity in DORA scope follows DORA for ICT risk management, incident reporting, supervision and enforcement, even if national NIS2 law also identifies it as essential or important.
NIS2 still reaches the rest of the group. Group IT companies, data centres, managed service providers and non-financial subsidiaries are assessed under national NIS2 law in their own right.
Your ICT suppliers may be NIS2 regulated. Cloud, data centre, managed service and managed security providers are covered by Commission Implementing Regulation (EU) 2024/2690, so their NIS2 evidence can feed your DORA due diligence.
Build one control catalogue with two reporting outputs. Roughly the same controls satisfy NIS2 Article 21 and DORA Chapter II; the real divergence is in incident classification, timelines, testing depth and the third-party register.
Machine identities sit in scope of both. Access control, authentication and asset management obligations cover service accounts, API keys and certificates as much as people, and both regimes expect you to evidence it.

What it is and who it applies to

DORA is an EU regulation, directly applicable in every Member State and applied from 17 January 2025. NIS2 is a directive: Member States had to transpose it by 17 October 2024, and it repealed the original NIS Directive from 18 October 2024. So DORA text, with its regulatory and implementing technical standards (RTS and ITS), is the same everywhere, while NIS2 arrives through national laws that differ in detail, timing and authority structure.

DORA covers 20 types of financial entity listed in Article 2(1), points (a) to (t), from credit institutions and payment institutions to insurers, investment firms, crypto-asset service providers and trading venues, plus ICT third-party service providers in point (u) for the oversight framework. NIS2 lists banking and financial market infrastructures among its high criticality sectors, alongside energy, transport, health, digital infrastructure, ICT service management and others, with a size threshold for most entity types.

The lex specialis rule

NIS2 Article 4 says that where a sector-specific Union act requires entities to adopt cybersecurity risk-management measures or notify significant incidents, with effect at least equivalent to NIS2, the corresponding NIS2 provisions do not apply. NIS2 recital 28 states that DORA "should be considered to be a sector-specific Union legal act" for financial entities, and DORA Article 1(2) confirms the same from its side. The result:

Organisation in the group	Primary regime	What still applies from the other
Bank, insurer, investment firm or other DORA financial entity	DORA and its RTS/ITS	National NIS2 law may still identify the entity; Member States may require DORA incident reports to be shared with NIS2 CSIRTs (DORA Article 19(1)); NIS2 information-sharing structures remain available
Group shared-services or IT company (not a financial entity)	National NIS2 law if it meets a sector and size test (for example as a managed service provider or data centre)	Treated as an ICT third-party provider under DORA by the financial entities it serves, so DORA contract and register requirements reach it
Non-financial subsidiary (for example energy trading arm, payments processor outside DORA scope)	National NIS2 law if in scope	None directly, but group policy usually applies one standard
External cloud, MSP or MSSP serving the group	NIS2, with Implementing Regulation 2024/2690 setting technical requirements	DORA contractual provisions; possible designation as a critical ICT third-party provider (CTPP)

Transposition status changes, so check it on the Commission's NIS2 transposition page and with each national authority. On 7 May 2025 the Commission sent reasoned opinions to 19 Member States for failing to notify full transposition. See the NIS2 Directive Guide for the NIS2 obligations in full and the DORA Guide for DORA.

Structure and key requirements

Both laws follow the same logic: governance, risk management measures, incident reporting, testing and supply chain. The table aligns the main provisions so one control owner can answer both.

Domain	DORA (Regulation 2022/2554 and standards)	NIS2 (Directive 2022/2555 and 2024/2690)	Main difference to plan for
Governance	Article 5: management body defines, approves, oversees and bears ultimate responsibility for ICT risk; approves the digital operational resilience strategy	Article 20: management bodies approve and oversee risk-management measures, can be held liable, and must follow training	DORA expects a documented resilience strategy and ICT risk management framework; NIS2 national laws add personal liability rules that vary by country
Risk management measures	Articles 6 to 16, detailed in RTS on the ICT risk management framework	Article 21(2), ten minimum measures (a) to (j); detailed for digital providers by 2024/2690	DORA is more prescriptive (backup, ICT change, network segmentation, logging); NIS2 is outcome-based except for 2024/2690 entities
Incident classification	Articles 17 and 18, major ICT-related incident criteria set by RTS	Article 23(3), significant incident; thresholds in 2024/2690 for digital providers	Different criteria: map one internal severity scale to both
Incident reporting	Article 19; RTS 2025/301: initial notification within 4 hours of classifying as major and no later than 24 hours from awareness; intermediate within 72 hours of the initial; final within one month of the latest intermediate	Article 23(4): early warning within 24 hours of awareness; incident notification within 72 hours; final report within one month of the notification	DORA's four-hour clock runs from classification; the weekend extension in 2025/301 does not apply to entities identified as essential or important under NIS2
Testing	Articles 24 to 27: annual testing of critical systems; threat-led penetration testing (TLPT) for selected entities at least every three years, RTS 2025/1190	Article 21(2)(f): policies and procedures to assess the effectiveness of measures	TLPT has no NIS2 equivalent; plan it as a DORA-only workstream
Third parties	Articles 28 to 30: ICT third-party risk strategy, register of information (templates in ITS 2024/2956), concentration risk assessment, mandatory contract terms, exit strategies; Articles 31 onward: CTPP oversight	Article 21(2)(d) and 21(3): supply chain security, considering supplier vulnerabilities and secure development practices	DORA requires a structured register and contract clauses; NIS2 does not
Penalties	Set by Member States (administrative penalties and remedial measures)	Article 34: maximum at least EUR 10 million or 2% of worldwide turnover for essential entities, EUR 7 million or 1.4% for important entities	Same breach of control could be judged by different authorities with different tools

The NIS2 Article 21(2) minimum measures are: (a) risk analysis and information system security policies; (b) incident handling; (c) business continuity, backup management, disaster recovery and crisis management; (d) supply chain security; (e) security in acquisition, development and maintenance, including vulnerability handling and disclosure; (f) assessing the effectiveness of measures; (g) basic cyber hygiene and training; (h) cryptography and encryption; (i) human resources security, access control policies and asset management; (j) multi-factor or continuous authentication and secured communications. Each has a DORA Chapter II counterpart.

Identity and NHI requirements

Neither law uses the term non-human identity, but both apply to it directly. Access control, authentication, asset inventories and logging cover every account that can touch a regulated system, and in a bank most of those accounts are service accounts, API clients, certificates and automation tokens.

Obligation	DORA source	NIS2 source	What it means for machine identities
Least privilege and access policy	Article 9(4)(c); identity management and access control articles of the ICT risk management RTS	Article 21(2)(i)	Each service account has a named owner, documented purpose and scoped permissions; no shared interactive use
Strong authentication	Article 9(4)(d)	Article 21(2)(j)	Use certificates, workload identity federation or managed identities instead of static passwords; MFA for human administrators of NHI platforms
Cryptography and key management	RTS on the ICT risk management framework (encryption and key lifecycle)	Article 21(2)(h)	Certificate and key inventory, defined rotation periods, protected storage in a vault or HSM
Asset inventory	Article 8: identify and classify ICT assets and their dependencies	Article 21(2)(i)	Inventory of service accounts, API keys and tokens mapped to the business functions they support
Third-party access	Articles 28 to 30	Article 21(2)(d)	Credentials issued to suppliers and SaaS integrations recorded against the contract and revoked at exit

Practical points:

One inventory, two uses: the service account inventory that proves DORA Article 8 asset identification also answers NIS2 asset management. See the Service Account Inventory Template.
Credentials in the register: for each ICT third-party arrangement in the DORA register, record which tokens, OAuth grants and keys the provider holds. That turns an exit plan into a revocation list.
Secrets as evidence: rotation logs and vault audit trails are among the easiest evidence to produce for both regimes. See the Secrets Management Guide.
Privileged automation: deployment pipelines and orchestration accounts that can change production are privileged access under both laws. See the Privileged Access Management Guide.

Implementation steps

Scope every legal entity. List each group company, its licence type and DORA Article 2 category, and test each non-financial entity against the national NIS2 sector and size rules in every country where it operates. Record the authority for each. Output: a scoping register signed off by legal.
Choose the anchor framework. For most financial groups DORA is the stricter regime, so build the control catalogue on DORA Chapter II and the ICT risk management RTS, then tag each control with the NIS2 Article 21(2) letter it satisfies. Non-financial entities inherit the same controls with proportionate depth.
Unify incident classification. Write one internal severity model with fields for both DORA major-incident criteria and NIS2 significant-incident criteria (and 2024/2690 thresholds for any digital provider in the group). The triage form should output which regulators to notify and which clock started when.
Build the reporting runbook. One timeline, two tracks: DORA initial notification at four hours from classification (24 hours from awareness at the latest), NIS2 early warning at 24 hours, then the 72-hour and one-month reports. Pre-fill templates and name a deputy for weekends, because the DORA weekend extension does not cover NIS2-identified entities or credit institutions. See the Incident Response Plan Template.
Build the register of information once. Use the ITS 2024/2956 templates as the master supplier record for the whole group, including non-DORA entities. It answers NIS2 supply chain questions and is the input the ESAs used to designate CTPPs.
Plan testing in layers. Annual vulnerability and scenario testing for all critical systems serves both laws. Add TLPT for entities the competent authority selects, following RTS 2025/1190. See the Threat-Led Penetration Testing Guide.
Pilot with one entity. Run the unified catalogue, register and incident runbook in one financial entity and one NIS2 entity for a quarter. Run a tabletop that triggers both clocks. Fix gaps before group-wide rollout.
Keep a rollback route. Retain the previous entity-level procedures until the first live or simulated incident has been reported through the unified process without missed deadlines; only then retire them.

Decision guidance by organisation size

Single financial entity, no other regulated companies: run DORA only and keep a one-page NIS2 note explaining why Article 4 applies.
Mid-sized group with an in-house IT company: treat the IT company as both a NIS2 entity (if in scope) and a DORA ICT provider. Intra-group contracts need DORA Article 30 terms.
Large cross-border group: appoint one owner for each control family across all entities, and a regulatory desk per country to track transposition differences. DORA proportionality (Article 4) lets smaller entities in the group apply lighter depth, which NIS2 also allows through its essential and important tiers.
ICT provider serving banks: expect to be audited under DORA contract rights while complying with NIS2 and 2024/2690 yourself. Map your NIS2 evidence to DORA Article 30 information and audit clauses so one evidence pack serves both.

Evidence and assessment

Supervisors under both regimes want proof that controls operate. Build evidence that answers both.

Evidence artefact	DORA use	NIS2 use
Management body minutes approving strategy and risk appetite	Article 5	Article 20
Control catalogue with ownership and test results	ICT risk management framework review	Article 21 measures and 21(2)(f) effectiveness
Incident log with classification decisions and timestamps	Articles 17 to 19, RTS 2025/301	Article 23
Register of information	Article 28(3), ITS 2024/2956	Article 21(2)(d) supply chain
Test reports (vulnerability, scenario, TLPT)	Articles 24 to 27	Article 21(2)(e) and (f)
Identity and secrets inventories, access reviews, rotation logs	Article 9 and RTS access control	Article 21(2)(i) and (j)
Training records for the management body	Article 5 ICT training	Article 20(2)

Measure the programme with a small set of indicators:

Reporting timeliness: percentage of reportable incidents and exercises where every notification met the shorter of the two clocks.
Control coverage: percentage of catalogue controls tagged to both a DORA article and an NIS2 Article 21(2) letter, with a current test result.
Register completeness: percentage of ICT arrangements in the register with all mandatory fields and a mapped business function.
Machine identity ownership: percentage of service accounts and API keys with a named owner and rotation date inside policy.
Finding closure: median days to close supervisory and test findings, tracked per entity.

ENISA's NIS2 Technical Implementation Guidance (June 2025) gives examples of evidence for each 2024/2690 requirement, a useful template even outside that regulation.

Mapping to other frameworks

Most groups already hold an ISO/IEC 27001 certificate or use NIST CSF. Mapping both laws to that existing base avoids a third catalogue.

Topic	DORA	NIS2	ISO/IEC 27001:2022 Annex A	NIST CSF 2.0
Governance and accountability	Art. 5	Art. 20	5.1, 5.2, 5.4	GV.RR-01, GV.RM-03
Asset and supplier inventory	Art. 8, Art. 28(3)	Art. 21(2)(i), (d)	5.9, 5.19, 5.22	ID.AM-04, GV.SC-04
Access control and authentication	Art. 9(4)	Art. 21(2)(i), (j)	5.15, 5.16, 5.17, 5.18, 8.5	PR.AA-01, PR.AA-05
Supplier contracts and exit	Art. 28, Art. 30	Art. 21(2)(d)	5.20, 5.21, 5.23	GV.SC-05, GV.SC-10
Incident management and reporting	Art. 17 to 19	Art. 23	5.24, 5.25, 5.26	RS.MA-01, RS.CO-02
Continuity and recovery	Art. 11, Art. 12	Art. 21(2)(c)	5.29, 5.30, 8.13	PR.IR-03, RC.RP-01
Testing and improvement	Art. 24 to 27	Art. 21(2)(f)	5.35, 8.8	ID.IM-02

An ISO/IEC 27001 certificate is useful evidence but does not prove DORA or NIS2 compliance on its own: its scope may exclude regulated services, and it has no incident reporting clocks, register of information or TLPT. See the ISO 27001 Certification Guide. For banks, the EBA guidelines on ICT and security risk management remain a reference point for how supervisors read DORA; see the EBA ICT and Security Risk Guidelines Guide. For the wider landscape see the Global Cybersecurity Regulatory Map.

Common pitfalls

Assuming lex specialis covers the whole group. It covers DORA financial entities. The group IT company that runs their data centres may be a NIS2 entity with its own registration and reporting duties.
Running two incident clocks from two teams. When the DORA desk and the NIS2 desk triage separately, the same event gets classified twice and the shorter deadline is missed. One triage, one timestamp, two outputs.
Treating the register of information as a procurement spreadsheet. Missing business function mapping and subcontractor chains make the register useless for concentration analysis and exit planning. See the Third-Party Concentration Risk Guide.
Relying on an outdated national law. Several Member States transposed late; draft texts and final acts differ. Track each country through the official journal and the competent authority.
Leaving machine identities out of access reviews. Both regimes ask for access control evidence. Human-only reviews are how supplier and integration tokens outlive their contracts.
Over-scoping NIS2 controls onto DORA entities. Building a parallel NIS2 programme for an entity where Article 4 applies duplicates effort and creates conflicting evidence. Document the lex specialis position instead.

Practitioner checklist

Scoping register completed for every group legal entity, with DORA category, NIS2 status per country and competent authority.
Written lex specialis position for each DORA financial entity, reviewed by legal counsel.
Single control catalogue built on DORA Chapter II, each control tagged to an NIS2 Article 21(2) letter and to ISO/IEC 27001 Annex A.
One incident severity model producing DORA and NIS2 classification and the deadlines for both, tested in a tabletop.
Register of information on ITS 2024/2956 templates covering the whole group, including intra-group ICT services.
Intra-group and external ICT contracts reviewed against DORA Article 30 terms.
Service account, API key and certificate inventory with owners, mapped to business functions and to supplier arrangements.
Annual testing plan covering both regimes, plus a TLPT plan where the authority requires it.
Management body training and approvals minuted for both Article 5 DORA and Article 20 NIS2.
Quarterly check of national transposition changes in each country of operation.

Standards and references

Related NHI Mgmt Group resources: DORA Guide · NIS2 Directive Guide · Third-Party Risk Management Guide · Identity Security Regulatory Map · Data Breach Notification Checklist. This guide summarises the overlap between DORA and NIS2 and is not legal advice.

DORA and NIS2 Overlap Mapping Guide: One Programme for Both Regimes