NIS2, DORA and the Cyber Resilience Act: what do you need to do with them?

What are NIS2, DORA, and the CRA?

What is NIS2 (Cybersecurity Act)?

NIS2 is a European directive. That means: each country must transpose this directive into national legislation. In the Netherlands, this is done through the Cybersecurity Act (Cbw).

Important to know: the EU deadline to transpose NIS2 was October 17, 2024. Many countries (including the Netherlands) are still working on translating it into national regulations.

Status in the Netherlands: the Cbw will only come into effect after approval by the House of Representatives and the Senate. The government itself expects this by the end of Q2 2026, but that depends on the pace in the chambers.

What is DORA?

DORA (Digital Operational Resilience Act) is a European regulation. That is the difference with NIS2: a regulation applies directly throughout the EU.

DORA focuses on the financial sector (banks, insurers, investment firms, and more) and has been applicable since January 17, 2025.

What is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act is also a European regulation, but with a different approach: it is not primarily about organizations, but about products with digital elements (hardware, software, and often associated "remote" services).

The CRA has been in effect since December 10, 2024. The reporting obligations start on September 11, 2026, and the main requirements will apply from December 11, 2027.

Current development: on March 3, 2026, the European Commission published draft guidelines for feedback, focusing on, among other things, remote data processing, open source, support periods, and the relationship with other EU legislation.

Why is the EU setting these rules?

The simple reason: we are more digitally dependent than ever, and that dependency is in chains.

• One incident at a supplier can affect dozens of organizations.
• Disruptions and attacks do not stop at national borders.
• The impact is no longer "just IT": it affects production, healthcare, payments, logistics, public services.

That is why the EU wants a higher, more equal baseline level of cyber resilience, with clear expectations about measures, reporting, supervision, and (increasingly) demonstrability. This is reflected in the NIS2 objective and the pressure on member states to strengthen resilience in critical organizations within society.

What are these rules mainly focused on?

Focus areas within NIS2 / Cybersecurity Act

NIS2/Cbw is about "controlled security" for essential and important organizations: not just technology, but also governance, processes, and the chain.

In the Dutch explanation, you see three pillars:

1. Duty of care: taking appropriate measures based on risks, aimed at continuity and protection of information.

2. Registration obligation: organizations in scope must (soon) register mandatorily. Voluntary registration has been possible since October 17, 2024; mandatory registration will only apply after the Cbw comes into effect.

3. Reporting obligation (significant incidents): in steps and with speed:

• within 24 hours early warning,

• within 72 hours follow-up report,

• no later than 1 month after the first report a final report.

What you increasingly see in practice here: organizations that wait for "the exact legal text" fall behind. The reporting chain, decision-making, and crisis organization must be practiced, not just written down.

Focus areas within DORA

DORA is made for one scenario: the financial sector must keep running, even when ICT is under pressure.

The focus is on:

• ICT risk management: policy, controls, monitoring, ownership.

• Incident management and reporting: processes to control and report major ICT incidents.

• Testing resilience: not just a test once a year, but structural and demonstrable.

• Third parties/suppliers: control over outsourcing, contracts, exit scenarios.

Supervision of critical ICT suppliers: this is an important trend. On November 18, 2025, European supervisors published the first list of designated critical ICT third-party providers.

In short: DORA makes "supplier management" an explicit priority.

Focus areas within the CRA

The CRA brings cybersecurity into the product: secure by design becomes a requirement to sell in the EU.

The core revolves around:

• Safe design and secure default settings.

• Managing vulnerabilities: finding, fixing, communicating.

• Updates and support: how long does a product remain safe and supported?

• Reporting problems: reporting obligations will start in 2026.

Clarity about scope: especially for software, cloud-like functions, and open source. That is why extra guidance is now coming from the Commission.

A practical observation: the CRA affects not only "security teams." Product management, development, legal, QA, and supply chain suddenly come together in one compliance issue.

Why is compliance important?

Of course: it is legislation, so you want to avoid fines, supervision, reputational damage, and liability. But there are three reasons that often weigh heavier than "compliance":

• Continuity: you do not want one incident to stop your service.

• Trust: customers and chain partners increasingly ask for demonstrable resilience.

• Market access: with the CRA, product security literally becomes a ticket to the EU market (or at least a hard sales condition).

Who invests now, buys peace of mind: fewer ad hoc incidents, faster recovery, better predictability.

How do you start without drowning in rules?

If you want to approach it practically, this almost always works:

Determine scope: do you fall under NIS2/Cbw, DORA, CRA, or multiple?

• Expose your critical chain: which suppliers are "single points of failure"?

• Make incident reporting feasible: can you report within 24/72 hours with the right information, without panic?

• Start collecting evidence: not just policy, but also logs, tests, exercises, and follow-up.

• For product teams: develop processes for vulnerability handling, update processes, and support agreements in your lifecycle.

If you choose one action for this week: do a scope check and test your incident flow (who does what, when, with what information). Then you are already ahead of many organizations still "waiting for the law."

(This blog is intended as an informative overview and not legal advice.)