The short answer is that NIS2 and DORA are not two competing rules you pick between. They are two different EU laws with different scopes, and many regulated companies fall under both at the same time. DORA applies to financial entities and their critical ICT third parties. NIS2 applies to operators of essential and important services across a much wider set of sectors. If you run a bank, an insurer, a payment firm, or a crypto-asset service provider, DORA is your primary digital resilience regime. If you run a hospital, an energy utility, a cloud provider, a managed service provider, a manufacturer, or a public administration, NIS2 is the law that names you. Some firms sit in both worlds, and the law tells you how to resolve that overlap.
We help regulated mid-market and enterprise teams figure out which obligations actually bind them, then turn those obligations into a security program that holds up under audit and under attack. This post explains what each law covers, how they differ in legal force and scope, how to tell which one applies to you, and what the work looks like in practice. We write as engineers who run the testing and build the governance and compliance programs behind these regimes, not as lawyers reading statutes from a distance.
What NIS2 actually is
NIS2 is Directive (EU) 2022/2555. It replaces the original 2016 NIS Directive and widens both the sectors in scope and the strictness of the requirements. As a directive, it does not apply to you directly. Each EU member state transposes it into national law, and the national text is what binds your organisation. That matters because the transposition deadline was October 2024, and member states moved at different speeds, so the exact wording, thresholds, and penalties you face depend on the country where you operate. The directive sets the floor. National implementations can go further.
NIS2 splits in-scope organisations into essential entities and important entities. The distinction drives how strictly regulators supervise you and how large the fines can be, but the baseline security duties are similar. The law focuses on risk management measures, incident reporting, supply chain security, and the accountability of management bodies. We cover the sector lists, the size thresholds, and the reporting clock in detail in our NIS2 explainer, and the dedicated NIS2 compliance page lays out how we map the directive to controls you can test.
What DORA actually is
DORA is Regulation (EU) 2022/2554, the Digital Operational Resilience Act. It has been in force since January 2025. The word regulation matters here. Unlike a directive, a regulation applies directly across every member state with the same text. There is no national transposition that changes the substance. The rules you read in DORA, plus the regulatory technical standards that flesh them out, are the rules that bind a financial entity in Dublin, Frankfurt, and Zagreb in the same way.
DORA targets the financial sector and its ICT supply chain. It builds operational resilience around five pillars: ICT risk management, ICT incident classification and reporting, digital operational resilience testing, ICT third party risk management, and information sharing. The testing pillar is where DORA goes further than most prior financial rules, because it requires threat-led penetration testing for the most significant entities. We break the obligations into an actionable sequence in our DORA compliance checklist, and the DORA compliance page shows how each pillar connects to concrete engagements.
Directive versus regulation, and why the legal form changes your plan
The single biggest structural difference is legal form, and it has practical consequences for how you plan. A regulation is uniform and self-executing. A directive depends on national law. This affects three things directly: where you look for the binding text, how much variation you face across countries, and how predictable your obligations are over time.
- DORA gives you one rulebook. A financial group operating in several EU states can build a single resilience program and apply it consistently, because the regulation and its technical standards do not change from country to country.
- NIS2 gives you many rulebooks. A multinational under NIS2 must check each national transposition, because thresholds, registration duties, reporting portals, and penalty levels differ between member states.
- DORA includes detailed regulatory technical standards and implementing technical standards that specify how to do the work, which reduces interpretation risk but raises the bar on evidence.
- NIS2 leaves more room for national authorities to define specifics, so your local regulator's guidance becomes a primary source rather than a footnote.
- For groups that fall under both laws, the practical move is to build to the stricter standard once and then map the same evidence to both regimes, which is the approach we take on GRC engagements.
How to tell which one applies to you
Start with what your organisation does, not with which law you would prefer. DORA scopes by financial activity. NIS2 scopes by sector and size. Run these questions in order and you will usually land in the right place quickly.
- Are you a financial entity as DORA defines it, meaning a credit institution, payment institution, electronic money institution, investment firm, insurer, reinsurer, crypto-asset service provider, central counterparty, trading venue, or similar regulated financial actor? If yes, DORA applies.
- Are you an ICT third party service provider that financial entities depend on, such as a cloud platform, a data analytics provider, or a critical software vendor? If yes, DORA reaches you through its third party provisions, and the most critical providers face direct oversight.
- Do you operate in a NIS2 sector such as energy, transport, banking, financial market infrastructure, health, drinking and waste water, digital infrastructure, ICT service management, public administration, space, postal services, waste management, chemicals, food, manufacturing, digital providers, or research? If yes, check the size thresholds next.
- Do you meet the size threshold, generally medium-sized or larger, meaning at least 50 staff or more than 10 million euro in turnover, with some entities in scope regardless of size because of their criticality? If yes, NIS2 likely applies.
- Do both apply at once, for example a bank that is also classed as financial market infrastructure? If yes, read the next section, because the law tells you how the two interact.
When both apply, and the lex specialis rule
Financial entities frequently appear in both the DORA scope and the NIS2 sector list, because banking and financial market infrastructure are named in NIS2 as well. The EU anticipated this overlap. DORA operates as lex specialis for ICT risk management in the financial sector. In plain terms, where DORA covers a topic for a financial entity, DORA's specific rules take precedence over the more general NIS2 requirements for that same topic. You do not apply both sets of ICT risk and incident rules twice.
This does not make NIS2 irrelevant to financial firms in every respect, and it does not let you ignore national supervisory expectations. It means your ICT risk management, incident reporting, and resilience testing follow DORA, while you still pay attention to how national NIS2 authorities and financial supervisors coordinate. The safe engineering posture is to build the DORA program to its full depth, then confirm with counsel that it satisfies the financial-sector carve-out in your member state.
NIS2 and DORA overlap substantially. For most regulated firms, the practical task is to build one program whose controls and evidence satisfy both.
Where the two laws line up
Despite the different legal form and scope, the two regimes ask for many of the same things, because they are both built on sound security engineering. If you build a real program rather than a paper one, most of your work counts toward both. The shared spine looks like this.
- Both require governance and accountability at the top, with management bodies that approve risk measures, understand the exposure, and can be held responsible for failures rather than delegating blame downward.
- Both demand structured ICT or network and information system risk management, covering asset inventory, access control, encryption, vulnerability management, and business continuity.
- Both impose incident reporting on a clock, with an early notification followed by more detailed reports, so your detection and response process must produce facts fast under managed detection and response.
- Both put supply chain and third party risk at the center, because attackers reach regulated firms through vendors, and we cover that exposure through external attack surface management and vendor assessment.
- Both expect testing rather than assertions, which is why offensive testing and continuous validation sit at the core of any defensible response to either law.
Where they differ in the actual work
The frameworks diverge most in the testing pillar and in the detail of the technical standards. DORA is explicit and prescriptive about resilience testing. It requires a testing program for all financial entities, and it requires threat-led penetration testing, modeled on the TIBER-EU framework, for entities identified as significant. That testing is intelligence-driven, simulates real adversaries, and targets production systems under controlled conditions. This is far closer to a red team exercise than to a checklist scan.
NIS2 requires risk-proportionate security measures and testing, but it is less prescriptive about the form. National implementations and sectoral guidance fill the gap. In both cases the difference between a credible program and a fragile one comes down to whether you run genuine adversarial testing or settle for automated scanning. We explain that gap in PTaaS versus pentest versus automated scanning and in pentest versus scan, and our offensive security service delivers the threat-led testing DORA's significant entities need.
What the work looks like step by step
Whichever law applies, the path from obligation to evidence follows a similar sequence. We run it as a program, not a one-time scramble before an audit. The order matters, because each step produces the inputs the next step needs.
- Scoping and applicability, where we confirm which law or laws bind you, identify the entity classification, and map the relevant national transposition for NIS2 or the applicable technical standards for DORA.
- Gap assessment against the chosen control set, comparing your current state to the legal requirements and to a recognised baseline such as ISO/IEC 27001:2022, which gives you 93 Annex A controls across four themes to anchor the work.
- Remediation planning, where we prioritise fixes by real risk, sequence them against deadlines, and assign owners so the program does not stall after the report.
- Technical validation through penetration testing and threat-led testing, covering web application testing, API security against the OWASP API Security Top 10, network testing, and cloud assessment.
- Incident readiness, where we exercise the reporting clock, rehearse detection and escalation, and confirm you can produce the early notification each law demands within the required window.
- Evidence assembly and ongoing monitoring, where we package the artifacts both for regulators and for the next cycle, because neither law treats compliance as a single event.
How this ties to ISO 27001, SOC 2, and the EU AI Act
Neither NIS2 nor DORA names a specific certification you must hold, but both reward firms that already run a recognised management system. ISO/IEC 27001:2022 maps closely to the risk management expectations in both laws, and an existing certification gives you a large share of the governance and control evidence ready to reuse. We connect that mapping in our ISO 27001 certification guide and on the ISO 27001 compliance page.
SOC 2 helps differently. It is not an EU regime, but its Trust Services Criteria produce third party evidence that financial entities and their vendors lean on for DORA's supply chain requirements. The relationship between the two frameworks is worth understanding before you pick one, which we cover in SOC 2 versus ISO 27001 and SOC 2 readiness. If you build or deploy AI systems inside a regulated entity, the EU AI Act adds a further layer, and securing those systems against attacks like prompt injection becomes part of the same resilience story we describe in securing LLM apps.
Common mistakes and red flags
The failures we see most often are not exotic. They come from treating these laws as a documentation exercise rather than a security program. Watch for these patterns in your own organisation or in any vendor pitching you a fast path to compliance.
- Assuming you must choose one law, then ignoring the other, when in fact a financial entity in a NIS2 sector needs to reconcile both through the lex specialis rule rather than pick a side.
- Reading the directive text for NIS2 instead of your national transposition, which means you miss country-specific thresholds, registration duties, and penalties that actually bind you.
- Buying an automated scan and calling it resilience testing, when DORA's significant entities need threat-led penetration testing and both laws expect real adversarial validation.
- Treating third party risk as a questionnaire, when attackers reach you through vendors, and both regimes put supply chain security at the center of the obligations.
- Missing the incident reporting clock because detection and escalation were never rehearsed, which turns a technical incident into a regulatory failure on top of it.
Cost and effort, honestly
The effort scales with your size, your sector, and how much real security work you have already done. A firm with an existing ISO 27001 certification and a mature vulnerability management program faces a mapping and validation exercise. A firm starting from spreadsheets faces a build. The largest single variable for financial entities is the testing pillar, because threat-led penetration testing is a specialised, multi-week engagement rather than a quick scan. We break down the drivers of testing cost in our penetration testing cost guide, and the honest answer is that the price of a credible program is far lower than the fines and operational damage a regulator or an attacker can impose.
Where we fit
We help you answer the applicability question first, then build a single program that satisfies whichever laws bind you. That means confirming scope, mapping obligations to testable controls, running the offensive and resilience testing both regimes expect, and assembling evidence that holds up in front of a regulator. Start with our GRC service for the governance and mapping work, and pair it with offensive testing for the validation. If you want a clear read on which law applies to you and what the program would cost, book a scoping call and we will work through it with you.