NIS2 vs DORA: 7 differences that matter for your SOC

NIS2 (Directive (EU) 2022/2555) and DORA (Regulation (EU) 2022/2554) pursue the same outcome: operational resilience under supervision. They get there through different legal instruments, different scopes and different levels of prescription. For a SOC the distinction is not academic. It determines which incident clock you run, which testing regime you must evidence and who in your organization is personally accountable.

Difference 1: scope

NIS2 covers essential and important entities across a broad set of sectors: energy, transport, health, drinking water, digital infrastructure, public administration and more. As a directive, it only binds once each member state transposes it into national law; the transposition deadline was 17 October 2024 and progress across the EU is still uneven, so the exact obligations depend on your jurisdiction. DORA is a regulation: it applies directly, without transposition, since 17 January 2025, to financial entities such as banks, insurers, investment firms, payment institutions and crypto-asset service providers, and it extends to ICT third-party providers designated as critical.

Difference 2: precedence

DORA is lex specialis for the financial sector. Where both instruments could apply to a financial entity, DORA's requirements on ICT risk management, incident reporting and testing prevail. The practical reading: a regulated financial entity builds its program around DORA; everyone else in scope builds around NIS2 as transposed nationally. The intent overlaps; the obligations do not simply add up.

Both texts moved accountability up the organization chart, but with different force. NIS2 requires management bodies to approve cybersecurity risk-management measures, oversee their implementation and undergo training; members can be held liable for infringements. DORA goes further: the management body bears explicit final responsibility for ICT risk, must define roles and responsibilities, approve the digital operational resilience strategy and maintain sufficient knowledge to challenge it.

For the SOC this changes the reporting product. Board packs that summarize alert volumes do not evidence oversight. What an assessor looks for: documented board approval of the ICT risk framework, minuted challenge, and a maturity baseline the board has actually seen. Capability numbers without a maturity context do not survive a supervisory interview.

NIS2 treats supply chain security as one of the required risk-management measures: policy, due diligence, security in supplier relationships. DORA dedicates an entire chapter to it. Financial entities must maintain a register of information covering all ICT contractual arrangements, assess the criticality of each provider, embed prescribed clauses in contracts (audit and access rights, exit strategies, incident cooperation) and accept an EU-level oversight framework for providers designated critical.

If your SOC is partly or fully outsourced, this is the difference that bites first. An MSSP serving a financial entity inherits DORA obligations transitively, through contract. Selection files, SLAs and exit clauses become regulatory evidence, not just procurement hygiene. Document the selection process; supervisors ask for traceability.

NIS2 requires policies and procedures to assess the effectiveness of risk-management measures, including regular security testing, but names no methodology. DORA prescribes a digital operational resilience testing programme with annual testing of critical systems, and, for entities identified as significant, threat-led penetration testing (TLPT) at least every three years under article 26. TLPT runs against live production systems, is driven by real threat intelligence on the actors targeting your sector, and is aligned with the TIBER-EU framework.

Sequence maturity before TLPT. A TLPT against a SOC that has never measured its maturity produces findings nobody can prioritize. An independent SOC maturity assessment first establishes which detection and response capabilities exist and at what level; the TLPT then tests them under realistic pressure. The 2026 SOC-CMM data shows self-assessments overestimate maturity by roughly 0.6 points, so an internal baseline alone is a weak starting position.

Difference 6: incident reporting

NIS2 sets a fixed cadence for significant incidents: early warning within 24 hours, incident notification within 72 hours, final report within one month. DORA starts earlier in the process: entities must classify every ICT-related incident against severity criteria, and major incidents trigger an initial notification followed by intermediate and final reports to the financial supervisor, on timelines set out in technical standards. The practical consequence for the SOC: classification logic, severity thresholds and report templates must exist before the incident, inside the runbooks, not improvised during one.

Difference 7: penalties

NIS2 sets administrative fines of up to 10 million EUR or 2% of global annual turnover for essential entities, and up to 7 million EUR or 1.4% for important entities, whichever is higher. DORA leaves most sanctioning to national financial supervisors within their existing powers, but adds a distinctive instrument: critical ICT third-party providers can face periodic penalty payments of up to 1% of average daily worldwide turnover for as long as non-compliance persists. Different mechanics, same message: resilience failures are now priced.

Most groups in scope of both regimes do not need two programs. They need one control framework with a regulatory mapping layer on top.

• Classify first: determine per legal entity whether DORA, NIS2 or neither applies. Precedence resolves most apparent overlaps.
• Build one set of controls for ICT risk, third parties, testing and incident response; map each control to the article of NIS2 or DORA it satisfies.
• Run one incident process with two output formats: the NIS2 24h/72h/1-month cadence and the DORA progressive reports draw on the same facts.
• Maintain one evidence pack. An independent SOC maturity assessment against the SOC-CMM, with its five domains and 27 aspects, gives both supervisors the same defensible baseline and a prioritized roadmap.

The finding to take away: NIS2 and DORA disagree on mechanics, not on direction. Build the capability once, evidence it independently, and report it twice.