NIS2, CER Directive, and DORA: Navigating Overlapping Frameworks

Who should read this: Compliance Officers, Risk Leaders, In-house Counsel

The European Union's regulatory landscape for cybersecurity has become increasingly dense. Organisations across the EU now contend with multiple, interlocking directives that govern how they secure networks, manage incident response, and certify their practices. The NIS2 Directive, alongside the Digital Operational Resilience Act (DORA) and the proposed Cyber Resilience Act (CER), creates a layered compliance environment where scope, obligations, and enforcement mechanisms overlap--sometimes intentionally, often with nuance.

Understanding these frameworks is not merely a compliance exercise. It affects resource allocation, governance structures, incident response procedures, and cybersecurity investment strategies. This post unpacks the relationship between NIS2, DORA, and CER, clarifies their distinct scopes, and provides practical guidance on how to navigate the overlap without duplicating effort or creating compliance gaps.

The regulatory interaction stems from deliberate policy design: DORA targets the financial sector's operational resilience, CER focuses on supply-chain product security, and NIS2 establishes a baseline for critical entities and essential service providers across all sectors. Yet their operational definitions, thresholds, and implementation timelines differ significantly. Compliance officers must understand where they converge and where sector-specific rules take precedence.

The Three Frameworks: Scope and Applicability

The NIS2 Directive establishes a broad, sector-neutral framework applying to essential service providers (in critical sectors) and important digital service providers. Article 4 defines these entities by reference to their role in essential services--energy, transport, water, healthcare, digital infrastructure, and public administration--or their criticality as digital service providers such as cloud providers, managed service providers, and data centre operators.

DORA, by contrast, applies explicitly to the financial services sector: credit institutions, investment firms, payment institutions, electronic money institutions, and certain crypto-asset service providers, along with their third-party service providers. Unlike NIS2's broad approach, DORA establishes distinct operational resilience requirements tailored to financial system stability. The threshold is not criticality in a general sense but systemic importance to financial markets.

The CER Directive--not yet fully implemented but already shaping procurement and product design--targets manufacturers and importers of products with digital elements that connect to networks. Its focus is preventative: by securing products before they enter the supply chain, CER aims to reduce the attack surface that organisations (including those under NIS2) inherit when deploying software and hardware.

The relationship is architectural. CER creates minimum product security standards; organisations subject to NIS2 then deploy those products within their own risk management frameworks; and if they operate in the financial sector, they simultaneously implement DORA's operational resilience requirements. An entity might be subject to all three: a fintech company offering payment services (DORA) using cloud infrastructure (NIS2 essential service provider) and purchasing encrypted communication tools (CER-compliant products).

Jurisdictional Reach and Entity Classification

Article 4 of NIS2 clarifies that essential service providers include those established in an EU Member State or offering services to customers in a Member State. The directive does not apply extraterritorially in the sense of regulating non-EU entities unless they operate within the EU's jurisdictional scope. DORA's reach is similarly EU-focused but narrower: it applies to regulated financial entities and their service providers.

CER extends beyond the EU's borders: manufacturers and importers anywhere in the world face compliance obligations if their products are sold to EU customers or other EU entities. This creates a global supply-chain security baseline that affects procurement across all sectors.

For a multinational operating across sectors and geographies, the compliance matrix becomes complex. Consider a telecommunications group with subsidiaries in energy (NIS2 essential service provider), financial services (DORA-regulated), and software product divisions (CER obligations). Each subsidiary faces distinct regulatory regimes. The parent organisation's governance must accommodate these differences whilst leveraging common cybersecurity practices.

Key Obligations and Overlaps

All three frameworks mandate incident reporting, though with different thresholds and procedures. NIS2 requires notification of competent authorities and CSIRTs for incidents meeting the "significant" threshold (Article 23). DORA establishes operational resilience standards with distinct critical incident and major incident categories, each triggering specific reporting and remediation timelines. CER requires responsible disclosure to manufacturers.

Similarly, all three emphasise governance and risk management. NIS2 requires entities to implement proportionate technical and organisational measures (Articles 21-22). DORA mandates comprehensive operational resilience testing and third-party risk management. CER ensures security is embedded in product design (security by design and default).

The overlap is deliberate but requires clarification. An entity subject to both NIS2 and DORA must design a cybersecurity programme that satisfies both directives' requirements. This does not mean duplicating controls; rather, it means ensuring that controls map to each directive's distinct risk priorities. DORA's focus on operational continuity and third-party concentration risk may drive specific controls (such as detailed sub-processor mapping and failure-mode testing) that NIS2 does not explicitly mandate but that good practice under NIS2 would recommend.

Governance Architecture and Member State Implementation

A critical distinction emerges in how each framework structures governance. NIS2 places significant authority in Member States: each state designates competent authorities, establishes CSIRTs, and may set specific implementation timelines and sector-specific risk thresholds. Recital 28 notes that the CER Directive complements NIS2 by addressing product-level security, thereby reducing the compliance burden on organisations implementing NIS2. This suggests that a well-implemented CER reduces the need for defensive controls against known product vulnerabilities at the organisational level.

DORA, managed by the European Banking Authority and other financial regulators, creates a more harmonised framework. Financial regulators in each Member State implement DORA with less discretion, ensuring consistency across EU financial services. This reflects the system-critical nature of financial markets and the need for coordinated regulatory response.

Member States implementing NIS2 may incorporate CER compliance as a recognised control or exemption. For example, a healthcare provider (essential service under NIS2) deploying medical devices compliant with CER would satisfy product-security elements of its NIS2 obligations. Conversely, a financial institution (DORA-regulated) cannot rely solely on CER compliance; DORA's operational resilience requirements are distinct and sector-specific.

Practical Alignment Strategy

For compliance officers, the key is to map overlaps without treating each framework as siloed. A single cybersecurity governance structure can accommodate NIS2, DORA, and CER if designed to address their distinct risk priorities:

Establish a common incident response framework that feeds into sector-specific reporting mechanisms. NIS2 and DORA both require incident notification; a single well-designed process can satisfy both, with branching logic to route incidents to appropriate authorities.

Document the risk assessment and control baseline in language that satisfies all applicable frameworks. Use NIS2's proportionality principle (Article 21) as the foundation, then add DORA-specific operational resilience controls and CER product-selection criteria.

Leverage third-party risk management common to all three frameworks, but tailor the focus: NIS2 emphasises service continuity, DORA emphasises operational resilience and concentration risk, CER emphasises product vulnerability management.

Coordinate with procurement to ensure product selections comply with CER, reducing the need for compensating controls under NIS2 and DORA.

Key Takeaways

- NIS2 establishes a broad baseline for critical entities; DORA targets financial services resilience; CER secures products at source. Together, they create a defence-in-depth regulatory architecture.
- Entity classification under each framework is distinct. An organisation may be NIS2-regulated but not DORA-regulated, or vice versa. Determine your classification under each directive before designing your compliance programme.
- Overlapping requirements (incident reporting, governance, risk management) can be consolidated into a single framework with sector-specific branching; avoid duplicating controls.
- DORA's operational resilience standards are more prescriptive than NIS2's proportionality-based approach, signalling that financial entities face higher security expectations.
- CER compliance reduces product-level security risk across all frameworks; incorporate CER-compliant product selection into your overall compliance strategy.