CRA vs NIS2 vs DORA: which applies to you

The short answer: the CRA regulates products — if you make, import or rebrand software or connected hardware sold in the EU, it applies to you regardless of your industry. NIS2 regulates organizations — if you operate in one of eighteen critical or important sectors above a size threshold, it applies to how you run security. DORA regulates financial entities and their ICT providers — banks, insurers, investment firms, and the technology companies that serve them. They are not alternatives: a fintech that ships a software product can be under all three at once.

The rest of this guide is the detail: what each covers, how to tell which bind you, where they overlap, and which evidence you can build once and reuse across all of them.

What each regulation covers

CRA: products with digital elements

The CRA attaches to the thing you sell, not the sector you are in. Hardware or software with a data connection, sold in the EU: secure by design, supported with free security updates, backed by vulnerability handling, and — from 11 September 2026 — subject to a 24-hour reporting clock for actively exploited vulnerabilities and severe incidents. Full obligations, including CE marking, apply from 11 December 2027. The detail is in our guides to what the Cyber Resilience Act is and what changes on 11 September 2026.

If you answer yes to "do we make, import or rebrand a product with digital elements sold in the EU," the CRA applies. Nothing about your customers or your sector changes that.

NIS2: essential and important entities

NIS2 attaches to the organization. It covers eighteen sectors — energy, transport, health, digital infrastructure, ICT service management, manufacturing of critical products, digital providers and more — split into essential and important entities, generally from 50 employees or €10M turnover upward within those sectors. Because it is a directive, the operative law is national: member states transposed it (deadline 17 October 2024, several ran late), and details like registration duties and enforcement practice vary by country.

What it demands is organizational: risk-management measures across ten mandated areas — including supply-chain security, incident handling, business continuity and encryption — management-body accountability for approving and overseeing those measures, and incident reporting to the national CSIRT on a 24-hour early warning / 72-hour notification / one-month final report cadence.

DORA: financial entities and their ICT providers

DORA attaches to the financial sector and reaches through it into technology suppliers. In-scope financial entities — banks, insurers, investment firms, payment institutions, crypto-asset service providers and more — must run ICT risk management, test their resilience, report major ICT incidents, and maintain a register of information covering every ICT third-party arrangement. Critical ICT providers to the sector fall under direct oversight by the European Supervisory Authorities.

If you sell software or ICT services to financial entities, DORA arrives via your contracts: the mandated provisions, audit and access rights, exit plans, and a place in your customer's register — even though you are not a financial entity yourself.

Where they overlap

Three real overlaps matter in practice:

• Incident reporting. All three run fast-notification regimes with similar clocks (24-hour early warnings appear in both CRA and NIS2; DORA has its own staged timeline for major incidents). One detection-and-decision process can feed all of them — but the recipients, thresholds and forms differ, so the routing has to be explicit.
• Supply chain. NIS2 mandates supply-chain security measures, DORA mandates the third-party register and contractual controls, and the CRA makes you responsible for the components inside your product. All three converge on the same capability: knowing your suppliers and being able to evidence their state.
• Management accountability. NIS2 puts approval and oversight duties on the management body; DORA does the same for financial entities; the CRA's conformity declaration is signed on behalf of the manufacturer. Someone named has to own it, in writing, in all three.

A fourth overlap is quieter but decides budgets: all three regimes are evidence regimes. None of them is satisfied by having done the work — each is satisfied by being able to show the work, on request, to a supervisor with the power to fine or to pull a product. That shifts the engineering question from "are we secure?" to "can we produce the record?": the risk assessment with a date on it, the incident report filed inside the window, the supplier register that matches reality. Teams that treat evidence as a byproduct of normal operation clear all three regimes with one habit; teams that reconstruct it per-request pay for the same work three times.

If more than one applies to you

First, work through the three questions in order, because they are independent: Do we ship a product with digital elements to the EU? (CRA — check exclusions before assuming no.) Are we in a NIS2 sector above the size threshold, in any member state where we operate? (NIS2 — and the sector list is longer than most people expect; check the national transposition, since details differ by country.) Are we a financial entity, or do we sell ICT services to any? (DORA — the second half catches most B2B software companies with bank logos on their site.)

Common stacks: a SaaS company selling to banks (CRA for the product + DORA through contracts), a medical-device-adjacent manufacturer (CRA + NIS2 as a manufacturing sector entity), a fintech with its own app (all three). The mistake to avoid is running three parallel projects — the regulations share more plumbing than their page counts suggest.

One sequencing note when several apply: order the work by enforcement reality, not by page count. DORA is fully in force and financial supervisors are actively asking for the register of information; NIS2 enforcement is live but uneven across member states; the CRA's reporting duty is live as of 11 September 2026 with the main obligations following in December 2027. That usually means: DORA contractual and register work first if you touch finance, the shared plumbing next, CRA conformity work on a 2027 clock — with its reporting capability pulled forward because that deadline has already passed.

Where ISO 27001 and SOC 2 fit into this

A common point of confusion: ISO 27001 and SOC 2 are not laws and none of the three regulations requires them. They are voluntary frameworks — but they are far from irrelevant here, for two reasons.

First, coverage: a genuinely operated ISMS already implements most of what NIS2's ten risk-management areas and DORA's ICT risk framework demand, and a good chunk of the CRA's process-side duties (secure development, vulnerability handling, supplier control). Regulators drafting these laws borrowed heavily from the same control tradition, which is why the overlap is structural rather than accidental.

Second, evidence: when a supervisor, market surveillance authority or enterprise customer asks how you meet the requirements, a certificate plus a current Statement of Applicability is the shortest credible answer available. It does not discharge the legal duty — an ISO certificate is not a CE mark, and NIS2 supervisors can look behind it — but it collapses most of the proving.

The practical read: if you are subject to any of the three and were considering ISO 27001 anyway, do it — the marginal cost of the regulation on top of a real ISMS is a fraction of the standalone cost. If you hold certifications already, start your gap analysis from them rather than from a blank page.

What overlapping evidence you can reuse

Build these once and they serve every regime that applies:

• A risk assessment with named owners — the CRA requires it per product, NIS2 per organization, DORA per ICT estate; the method and the register can be shared.
• A supplier register with security state per vendor — DORA's register of information, NIS2's supply-chain measures and the CRA's component accountability all draw on it.
• An incident process with decision criteria and contact routing — one process, three notification targets.
• Access control and asset records — every regime's auditors ask for them; none of them accept "it's in someone's head."
• A living evidence trail — dated, signed, current. The single most reusable artifact of all.

That reuse is the design principle behind ZeroRisk: requirements from CRA, NIS2, DORA and the ISO/SOC 2 world map onto one control set, the agent pre-fills and drafts, and every verdict is signed by a named person — so adding a second regulation starts largely pre-filled instead of starting over. See it on the CRA solution page, or check where you stand across all of them with the free gap report.