NIS2, DORA, CRA: How the EU Cybersecurity Frameworks Interact

The EU now operates three overlapping cybersecurity regimes – NIS2, DORA, CRA. How do they talk to each other?

NIS2 regulates organisations in critical sectors. DORA regulates ICT risk for financial entities. The CRA regulates products with digital elements. Most organisations of any size are subject to at least two.

The relationships between them are not symmetrical. DORA displaces NIS2 for financial entities under the lex specialis rule in Article 4. The CRA does not displace either, because it regulates a different object: your products rather than your organisation. A bank that manufactures a connected payment terminal is subject to DORA as an organisation and the CRA as a manufacturer, with NIS2 displaced for the DORA-covered matters and potentially still relevant for the rest.

The frameworks overlap heavily in substance and diverge sharply in operation. Risk management requirements are broadly similar and can be built once. Incident reporting requirements are similar in shape and cannot be consolidated: different triggers, different clocks, different recipients, different channels.

The organisations struggling with this in 2026 are the ones that built three separate compliance programmes. The ones handling it well built one system inventory, one evidence base, and three views onto it.

Key Definitions for NIS2, DORA, CRA

Term	Definition
NIS2	Directive (EU) 2022/2555. Cybersecurity obligations for organisations in critical sectors. Transposition deadline 17 October 2024
DORA	Regulation (EU) 2022/2554. Digital operational resilience for EU financial entities. Applies since 17 January 2025
CRA	Regulation (EU) 2024/2847. Cybersecurity requirements for products with digital elements. Reporting from 11 September 2026, full application 11 December 2027
Lex specialis	The principle that a sector-specific law displaces the general law for the matters it covers
Essential entity	A NIS2 classification attracting proactive supervision and higher penalties
Important entity	A NIS2 classification attracting reactive supervision and lower penalties
Product with digital elements	The CRA scope test: any software or hardware product with a data connection
CSIRT	Computer Security Incident Response Team. Receives incident notifications under both NIS2 and the CRA
SRP	Single Reporting Platform. The ENISA-operated CRA reporting channel
CTPP	Critical Third-Party Provider. A DORA designation for systemically important ICT providers

What Each Framework Regulates

The distinction that resolves most confusion is what each instrument takes as its object.

Framework	Regulates	Trigger	Instrument type
NIS2	Organisations	Operating in a listed sector above the size threshold	Directive, transposed nationally
DORA	Organisations	Being a financial entity listed in Article 2	Regulation, directly applicable
CRA	Products	Placing a product with digital elements on the EU market	Regulation, directly applicable

NIS2 and DORA both ask: is your organisation the kind of organisation we regulate? The CRA asks: is your product the kind of product we regulate?

This is why the CRA does not displace either of the others. A NIS2-regulated hospital that manufactures nothing is not a CRA manufacturer. A software company outside every NIS2 sector that sells connected products is a CRA manufacturer and nothing else. An organisation that is both is subject to both, in different capacities.

The DORA Displacement of NIS2

Article 4 of NIS2 provides that where a sector-specific Union legal act requires entities to adopt cybersecurity risk management measures or notify significant incidents, and those requirements are at least equivalent in effect, the sector-specific provisions apply instead.

DORA is that act for financial entities.

What DORA Displaces

Matter	Governed by
ICT risk management framework	DORA Articles 5-16, not NIS2 Article 21
Incident classification and reporting	DORA Articles 17-23, not NIS2 Article 23
Business continuity and recovery	DORA Articles 11-12, not NIS2 Article 21(2)(c)
Third-party ICT risk	DORA Articles 28-44, not NIS2 Article 21(2)(d)
Testing	DORA Articles 24-27, no NIS2 equivalent

The displacement is not an exemption. DORA is more demanding than NIS2 in several respects, notably third-party risk management, where Article 30 imposes mandatory contractual provisions NIS2 does not require, and testing, where Article 26 requires threat-led penetration testing for significant entities.

Where the Displacement Is Incomplete

Two areas require care.

Entity-level scope mismatch. DORA’s Article 2 list and NIS2’s Annex I banking and financial market infrastructure sectors are not identical. An entity in scope of NIS2’s banking category but outside DORA’s Article 2 list remains a NIS2 entity in full.

Group structures. A financial group may contain entities in scope of DORA and entities in scope of NIS2 through a different sector. A bank with a subsidiary operating data centre infrastructure may find the parent under DORA and the subsidiary under NIS2’s digital infrastructure category.

Entity situation	Applicable framework
Bank in scope of DORA	DORA displaces NIS2 for covered matters
Insurance intermediary below DORA threshold, above NIS2 threshold	NIS2 applies
Financial group with non-financial digital infrastructure subsidiary	DORA for the financial entities, NIS2 for the subsidiary
Payment institution	DORA displaces NIS2
ICT provider serving financial entities, not itself a financial entity	NIS2 if in a listed sector; DORA contractual obligations flow through client contracts

The CRA Alongside Both

The CRA stacks rather than displaces. An organisation subject to NIS2 or DORA that also manufactures products with digital elements carries CRA obligations in addition.

Where the Same Organisation Faces Both

Organisation	Organisational framework	Product framework
Medical device manufacturer	NIS2, health sector	CRA excluded, MDR governs product cybersecurity
Industrial automation vendor	NIS2 if in manufacturing above threshold	CRA for connected products
Bank issuing connected payment terminals	DORA	CRA for the terminals
Cloud provider	NIS2, digital infrastructure	CRA if it ships software products
Energy utility with proprietary SCADA software	NIS2, energy	CRA if the software is placed on the market
Software vendor outside all NIS2 sectors	None	CRA

The medical device row is the one that catches people out. The CRA excludes products covered by the MDR and IVDR, deferring to the sector cybersecurity regime. The organisation remains in scope of NIS2 as a health sector entity. And if the device incorporates AI, the EU AI Act applies through the Annex I product safety route.

Incident Reporting: The Point of Maximum Friction

All three frameworks require incident reporting. None of the reports substitutes for another.

Feature	NIS2 Article 23	DORA Article 19	CRA Article 14
Trigger	Significant incident affecting service provision	Major ICT-related incident	Actively exploited vulnerability or severe incident affecting product security
First deadline	24 hours, early warning	4 hours from classification, max 24 hours from awareness	24 hours, early warning
Second stage	72 hours, incident notification	72 hours, intermediate report	72 hours, notification
Final	One month from notification	One month from intermediate report	14 days after corrective measure, or one month for severe incident
Recipient	National CSIRT or competent authority	Competent financial authority	Coordinating CSIRT and ENISA
Channel	National, varies by member state	National financial supervisor	Single Reporting Platform
In force	Per national transposition	17 January 2025	11 September 2026

A Worked Example

A software vulnerability in a connected payment terminal manufactured by a bank is actively exploited, causing service disruption to the bank’s card processing.

Report	Framework	Deadline	To whom
Actively exploited vulnerability in the product	CRA Article 14	24 hours	Coordinating CSIRT and ENISA via SRP
Major ICT-related incident affecting the bank	DORA Article 19	4 hours from classification	Competent financial authority
Personal data breach if customer data affected	GDPR Article 33	72 hours	Data protection authority

Three reports, three recipients, three channels, three clocks. The 4-hour DORA clock is the binding constraint and the process has to be designed around it.

NIS2 does not appear because DORA displaces it for this entity. For a non-financial manufacturer in a NIS2 sector, NIS2 Article 23 would replace the DORA row.

The operational conclusion: one detection and assessment process, terminating in multiple reporting paths triggered by a single classification decision. Organisations running separate incident processes per framework will miss the tightest clock.

Risk Management: Where Consolidation Works

Unlike reporting, risk management requirements overlap enough to build once.

Requirement	NIS2	DORA	CRA
Documented risk management framework	Article 21(2)(a)	Articles 5-6	Annex I, vulnerability handling
Asset inventory	Article 21(2)(i)	Article 8	SBOM, Annex I
Incident handling process	Article 21(2)(b)	Articles 17-23	Article 14 process
Business continuity and recovery	Article 21(2)(c)	Articles 11-12	Not required
Supply chain security	Article 21(2)(d)	Articles 28-30	Supplier SBOM and patching obligations
Secure development	Article 21(2)(e)	Article 9	Annex I, Part I
Effectiveness testing	Article 21(2)(f)	Articles 24-27	Annex I, security testing
Cryptography	Article 21(2)(h)	Article 9	Annex I
Access control and MFA	Article 21(2)(i)-(j)	Article 9	Annex I
Training	Article 21(2)(g), Article 20	Article 13(6)	Not required

The pattern: DORA is the most prescriptive, NIS2 the most general, the CRA the most product-specific. A risk management framework built to DORA’s specification will satisfy NIS2’s Article 21 comfortably. A framework built to NIS2 will not satisfy DORA.

Practical sequence for organisations in scope of multiple frameworks: build to the most demanding applicable standard, then map the outputs into each framework’s vocabulary. Building to the lowest and supplementing upward produces gaps.

---

Management Liability: Where NIS2 Stands Alone

NIS2 Article 20 makes management bodies responsible for approving and overseeing cybersecurity measures, with liability for failure. Article 32(6) permits authorities to temporarily prohibit a chief executive or legal representative of an essential entity from exercising managerial functions where other enforcement has proved ineffective.

DORA imposes management body responsibility under Article 5(2) but does not contain an equivalent suspension power. The CRA imposes obligations on the manufacturer as an entity without personal liability provisions.

For an organisation in scope of both NIS2 and DORA, this matters at board level. The DORA displacement covers risk management and reporting. It does not obviously displace NIS2’s personal accountability architecture, and the safer reading is that management liability remains live.

NIS2, DORA, CRA Penalties Compared

Framework	Entity type	Maximum penalty
NIS2	Essential entity	€10m or 2% of worldwide turnover
NIS2	Important entity	€7m or 1.4% of worldwide turnover
DORA	Financial entity	Set by member state, effective, proportionate, dissuasive
DORA	Critical third-party provider	Up to 1% of average daily worldwide turnover, per day
CRA	Annex I essential requirements	€15m or 2.5% of worldwide turnover
CRA	Other manufacturer obligations	€10m or 2% of worldwide turnover

The DORA critical third-party provider penalty is structurally different from the others. It is a periodic penalty payment calculated daily, designed to make continued non-compliance more expensive than compliance rather than to punish a past failure.

Adding the AI Act

Where AI systems are involved, a fourth framework applies and the intersections multiply.

Scenario	Frameworks engaged
AI system managing critical infrastructure	NIS2 as organisational obligation, AI Act Annex III as high-risk system
AI fraud detection in a bank	DORA as ICT system, AI Act Annex III as high-risk system
Connected product with embedded AI	CRA as product, AI Act by classification
GPAI model sold as a product	CRA as product, AI Act Chapter V as model

AI Act Article 15 requires high-risk AI systems to achieve appropriate accuracy, robustness, and cybersecurity. This overlaps with CRA Annex I for products and with NIS2 Article 21 or DORA Article 9 for the systems the organisation operates.

The reporting position compounds again. An AI Act Article 73 serious incident report to the national market surveillance authority within 15 days sits alongside whichever of the NIS2, DORA, and CRA reports apply.

What Multi-Framework Compliance Actually Requires

The organisations handling this well share a structure.

One system inventory. Every system, application, and product recorded once with its properties: what it does, what data it processes, who operates it, which products it ships in, whether it incorporates AI. The facts are stable. The obligations mapped onto them are not.

One evidence base. Risk assessments, testing records, incident logs, supplier assessments, and architecture documentation stored once and referenced by each framework’s documentation rather than duplicated.

Framework views, not framework programmes. NIS2 Article 21 mapping, DORA Article 6 mapping, CRA Annex I mapping, and AI Act Annex IV mapping as views onto the same underlying record. When a framework changes, the mapping updates. The record does not have to be rebuilt.

One incident process with multiple outputs. A single detection and classification decision, followed by whichever reporting paths the classification triggers, running on their own clocks.

Shift-left at the product layer. For organisations in CRA and AI Act scope, compliance properties are determined at design. Whether the SBOM exists, whether logging is independent, whether human oversight is meaningful: these are architectural decisions, not documentation exercises. Addressing them at audit time means rework the roadmap cannot absorb.

This is what Grecta is built to do. One inventory, one evidence base, and framework mappings that update when the law does, across NIS2, DORA, the CRA, the EU AI Act, GDPR, the Data Act, and US state AI laws.

Contact Grecta to discuss multi-framework compliance infrastructure.

FAQ