DORA vs NIS-2 vs ISO 27001 vs CRA: Four Frameworks Compared

Europe now runs on multiple cyber and resilience regimes. That is good for outcomes, but it creates real pressure when audits, evidence requests, and terminology vary by framework. Many teams duplicate work, maintain parallel trackers, and answer the same control questions in different formats.

The good news: these frameworks share a lot of DNA.

With the EU Cyber Resilience Act entering force in December 2024 and reporting obligations live from 11 September 2026, there is now a fourth regime to account for — and it operates on a fundamentally different basis to the other three. DORA, NIS-2, and ISO 27001 govern organisations. The CRA governs products. For manufacturers and distributors of connected devices and downloadable software, that distinction matters enormously.

This comparison clarifies all four frameworks — DORA, NIS-2, ISO 27001, and the EU Cyber Resilience Act — and shows how to operate one control set and one evidence library that serves all of them. If you need a deeper dive on DORA execution, see our unified approach in the DORA Compliance Guide.

DORA (Digital Operational Resilience Act)

Who it covers

1. Financial entities regulated in the EU
2. ICT providers through contractual flow-down and, if designated, EU-level oversight of critical ICT third-party providers (CTPPs)

What it emphasises

1. Operational resilience programme and ICT risk management
2. Major incident reporting with prescribed clocks and fields
3. Third-party oversight and subcontractor transparency
4. Testing, including Threat-Led Penetration Testing (TLPT) where designated

Why duplication happens

DORA introduces sector-specific reports, registers, and testing expectations that often sit alongside your existing security and continuity artefacts. Teams end up maintaining DORA-specific copies of documents they already keep for ISO or general risk management unless they unify control language and evidence routing.

Why it matters in this comparison EU regulation with harmonised supervision across member states [European Commission]

NIS-2 Directive

Who it covers

Essential and important entities across sectors such as energy, transport, health, water, finance, digital infrastructure, public administration, and more.

What it emphasises

1. Cyber governance and accountability
2. Risk management and incident notification to national competent authorities (NCAs)
3. Supply-chain security and cooperation with NCAs
4. Incident notification timelines defined at EU level and implemented nationally

Why duplication happens

NIS-2 obligations are implemented via national law, so you may face different notification specifics per country in addition to DORA requirements. Without a single register and shared control names, you can end up answering similar questions twice in different formats.

Why it matters in this comparison

EU directive transposed into national law with broad cross-sector reach [ENISA]

ISO/IEC 27001 (2022 revision)

Who it covers

Any organisation that wants a certifiable Information Security Management System.

What it emphasises

1. Risk-based security management across people, process, and technology
2. Control objectives via Annex A and continuous improvement

Why duplication happens

ISO/IEC 27001 is the foundation for many controls, but it does not set legal reporting clocks or sector-specific oversight requirements. Without mapping, teams keep ISO evidence in one place and rebuild near-identical proof sets for DORA and NIS-2.

Why it matters in this comparison

Global standard that anchors cross-framework mapping and certification [ISO]

Cyber Resilience Act (CRA)

Who it covers

Manufacturers, importers, and distributors of products with digital elements placed on the EU market. This includes connected hardware and downloadable software. SaaS delivered purely as a service is largely out of scope, but any product component that can be downloaded or updated on a device falls within the regulation.

What it emphasises

1. Security by design: security requirements must be addressed before a product reaches market, not retrofitted after
2. Vulnerability handling: documented processes for identifying, disclosing, and remediating vulnerabilities throughout the support period
3. Minimum five-year security updates: manufacturers must provide free security patches for at least five years after market placement
4. Software Bill of Materials (SBOM): a machine-readable inventory of all software components, kept current as the product changes
5. CE marking: products must carry CE marking to demonstrate conformity with CRA requirements

Key dates

1. In force: 10 December 2024
2. Reporting obligations live: 11 September 2026
3. Full application: 11 December 2027

Why it matters in this comparison

The CRA is the only product regulation in this group. DORA, NIS-2, and ISO 27001 govern what organisations do. The CRA governs what products are. A single organisation can face all four simultaneously. A financial services firm that manufactures connected devices, for example, faces DORA as a regulated entity, NIS-2 as a potential essential service operator, ISO 27001 as a certification baseline, and the CRA as a product manufacturer.

All four regimes push organisations toward the same core outcomes. Use the overlap to reduce duplication and reuse evidence.

1. Governance and accountability: Boards and committees are active with named owners and decision rights
2. Risk assessment and treatment: Ongoing assessment with treatment plans, KRIs/KPIs, and time-bound actions
3. Incident response: Classification logic, escalation, communication, and post-incident reviews
4. Third-party management: Tiering, required clauses, assurance artefacts, and evidence calendars
5. Continuous monitoring: Control health tracking, exceptions, and retesting
6. Business continuity and testing: Plans, exercises, failover tests, and lessons-learned cycles
7. Documentation and traceability: Policies, procedures, registers, and logs with clear lineage to obligations

Use this table to compare obligations at a glance. Cells show where a theme is explicitly required or strongly supported.

Shared objectives table

Small distinctions change how you plan, resource, and evidence controls. The CRA introduces a dimension none of the other three frameworks require: product conformity.

The CRA differs from the other three in one fundamental way: it regulates products, not organisations. A single company can face all four simultaneously. A financial services firm that manufactures connected devices faces DORA as an entity, NIS-2 as a potential essential service operator, ISO 27001 as a certification baseline, and the CRA as a product manufacturer.

Use this table to scan the structural differences that drive audit and reporting expectations.

What it means in audits

1. DORA: expect detailed checks on registers, incident logic, testing cadence, and supplier oversight evidence
2. NIS-2: expect requests to show national notification decisioning and proof of supply-chain security measures
3. ISO/IEC 27001: expect ISMS governance, risk treatment, the Statement of Applicability, and certification-grade records
4. CRA: expect technical documentation, a current SBOM, conformity assessment records, and evidence of your vulnerability disclosure process

The CRA does not replace DORA, NIS-2, or ISO 27001. It adds a product-specific layer that sits alongside your existing organisational compliance work.

Three obligations are genuinely new — they do not map to anything in the other three frameworks:

1. CE marking and conformity assessment: a product certification process, not an organisational audit. Depending on the product's risk classification, this is completed via self-assessment or a notified body. It is a pre-market requirement, not a periodic review.
2. Minimum support period: manufacturers must provide free security updates for at least five years after market placement. This is an ongoing commercial and engineering obligation, not a documentation exercise.
3. SBOM: a machine-readable component inventory that must be created before market placement and updated whenever the product changes. The format and content requirements are defined in the CRA's implementing acts.

Everything else maps to work you are likely already doing.

Where existing controls extend

Practical implication: if you already have a mature ISO 27001 ISMS and are DORA-compliant, the incremental CRA workload is primarily the SBOM, the CE conformity assessment, and the formalisation of your vulnerability handling process. The governance, risk, and incident infrastructure you have built for the other frameworks provides a strong foundation.

A note on UK applicability

The CRA applies to products placed on the EU market. UK businesses that sell connected products into the EU must comply regardless of where they are based. The UK's own Cyber Security and Resilience Bill is in development and may introduce parallel requirements for the domestic market, but at the time of writing the CRA is the operative obligation for EU market access.

Map once, reuse often. The goal is to map controls once, then expose them through multiple framework views.

Use this table to see how common control themes align across all four regimes.

Traceability matters because supervisors, NCAs, certification bodies, and market surveillance authorities ask for different slices of the same programme. Use obligation → control → artefact → report mapping so each audience sees exactly what they need without duplicate work.

Treated this way, a four-framework comparison becomes a control-mapping exercise rather than a parallel paperwork effort.

A practical path to unify compliance and cut duplicate work across all four regimes.

Step 1: Map what you already have

1. Start with your ISO/IEC 27001 control set and Statement of Applicability
2. Map each control to DORA outcomes, NIS-2 obligations, and CRA product requirements
3. Capture gaps that are legal-specific: DORA's incident clocks and data fields, CRA's SBOM and CE marking requirements

Step 2: Consolidate one control set

1. Collapse duplicates so each obligation points to a single control
2. Assign owners, cadences, and evidence locations to every control
3. Keep one register for services, systems, data, suppliers, and product components

Step 3: Align language and artefacts

1. Normalise control names so your controls read consistently across frameworks
2. Use consistent tagging from obligation to control to artefact
3. Snapshot evidence before and after major changes so you can show what was true at the time

Step 4: Schedule testing and retesting

1. Put continuity drills, security testing, and post-incident reviews on a calendar
2. If designated for TLPT under DORA, integrate threat-led testing into your annual plan
3. Track findings to closure and attach retest proof

Step 5: Calibrate incident workflows

1. Mirror DORA-aligned fields and timelines where applicable
2. Document NIS-2 notification logic and national contacts
3. Build a separate workflow for CRA's 24-hour ENISA notification for actively exploited vulnerabilities
4. Route the same incident record to multiple reporting views to avoid duplicate data entry

Step 6: Report once, serve many

1. Build a dashboard with switchable views by framework
2. Export tailored packs for supervisors, NCAs, certification bodies, market surveillance authorities, and leadership
3. Keep a change log so recurring audits see progress without re-asking for basics

For a practical build of a unified reporting dashboard, see The 5 Pillars of DORA Explained

Run one control set, many frameworks — with a system designed for governance and evidence across all four regimes.

Control library and continuous control monitoring

1. Central control library with owners, cadences, and status
2. Exception queues and retest tracking for continuous improvement
3. Framework mapping that covers DORA, NIS-2, ISO 27001, and emerging product compliance obligations

Automated evidence collection

1. Pull artefacts on a schedule and capture versioned snapshots
2. Tag evidence to obligations and control IDs for traceability across all four frameworks

Incident and vendor workflows

1. Forms that can mirror DORA incident fields and clocks
2. Separate workflow configuration for CRA's 24-hour ENISA notification requirement
3. Vendor register, tiering, flow-down clauses, subcontractor visibility, and audit rights in one place

Policy and document governance

1. Lifecycle management, owner, cadence, and last-updated stamps
2. Version-controlled documentation ready for supervisory review, NCA inspection, or conformity assessment

Reporting and audit packs

1. Multi-framework dashboards and exportable evidence packs for supervisors, NCAs, certification bodies, market surveillance authorities, and leadership

Across EU cyber regulations, the fastest way to cut audit drag is to unify, not multiply. Treat DORA, NIS-2, ISO 27001, and the EU Cyber Resilience Act as four lenses on one operating system. Map controls once. Keep one evidence library. Switch reporting views for each audience.

The CRA adds a product-specific layer that is genuinely new — the SBOM, the CE marking process, and the minimum support period obligation are not covered elsewhere. But the governance, risk, and incident infrastructure you have already built for DORA, NIS-2, and ISO 27001 is the right foundation to build from.

This compliance framework comparison shows how one operating model can satisfy all four without multiplying work.

Book a demo to see how SureCloud maps controls across DORA, NIS-2, ISO 27001, and the EU Cyber Resilience Act