DORA, NIS2 and CRA: A Field Guide to Europe's New Cybersecurity Rulebook

Three overlapping EU regulations are reshaping how companies prove they are secure. Here is what DORA, NIS2 and the Cyber Resilience Act actually demand — and why the deadlines matter.

DORA, NIS2 and CRA: A Field Guide to Europe's New Cybersecurity Rulebook

On 17 January 2025, a regulation came into force that most European companies had spent two years preparing for and many still were not ready to meet. It was not a data protection rule and it was not aimed at hospitals or energy grids. It was aimed at banks, insurers, fund managers, payment providers — and, crucially, at the technology vendors that keep them running. Its name is DORA, and it is only the first of three regulatory waves now breaking over the continent.

Anyone who has spent the past decade watching cybersecurity law evolve in Europe knows the pattern: a new directive arrives, member states transpose it at different speeds, and companies spend years chasing a moving target. What is different this time is the sheer density. DORA, NIS2 and the Cyber Resilience Act (CRA) do not replace one another. They overlap, cross-reference and, in places, deliberately exclude one another. For a security leader trying to build a compliance roadmap, that is both the opportunity and the trap.

Why Europe Is Regulating Resilience, Not Just Privacy

The GDPR taught European organisations to think about personal data as a liability with legal weight. The new generation of rules asks a harder question: not what data do you hold, but can you keep operating when someone attacks you?

The shift is deliberate. Cyberattacks have grown more sophisticated and more damaging, and the sectors that keep society functioning — finance, energy, transport, health, telecoms — are precisely the ones that are most interconnected and most exposed. A single compromised software supplier can ripple across hundreds of institutions in hours. Regulators looked at that dependency and concluded that voluntary best practice was not enough.

The goal, in the words of the framework behind these rules, is improving operational resilience — and doing so holistically, treating physical and logical security as one problem rather than two. That is why these regulations sit alongside older obligations from the GDPR, telecoms sector rules, certification schemes such as the EU Cybersecurity Act, and the CER directive on critical entities. They are not a tidy stack. They are a lattice.

DORA: Resilience Rules for Finance and Its Suppliers

DORA — the Digital Operational Resilience Act, formally Regulation (EU) 2022/2554 — was published in December 2022 and became directly applicable on 17 January 2025. "Directly applicable" is the important phrase: unlike a directive, DORA does not need to be transposed into national law. It applies as written, across every EU member state, on the same day.

Its first job is harmonisation. Before DORA, a bank, an insurer, a pension fund and a fund manager could each face different national rules on ICT risk. DORA pulls them under one framework and, in doing so, widens the net to cover a larger number of entities than any single national regime did.

Its second job is where things get uncomfortable for the supply chain. DORA obliges financial institutions to maintain a robust ICT risk management framework — and that obligation flows directly downstream to the technology providers supporting their essential services and products. If you sell critical infrastructure, cloud or software to a European bank, DORA is now part of your contract negotiation whether you are headquartered in Frankfurt or San Francisco.

What the financial sector now has to demonstrate

  • A documented, board-level ICT risk management framework, not a folder of policies nobody reads
  • Incident reporting to competent authorities within tight, defined windows
  • Regular resilience testing, including threat-led penetration testing for significant entities
  • Oversight and contractual controls over critical ICT third-party providers

For our part, we have seen the testing requirement change conversations fastest. Threat-led penetration testing under DORA is not a checkbox scan. It is an intelligence-driven exercise designed to answer a specific question: if a competent, motivated attacker targeted our most critical function, would we still be able to settle payments, process claims, or keep the ledger straight?

Note: DORA is now in its operation and maintenance phase. Regulators and institutions are drawing lessons from real testing and real incident reports, and those lessons are likely to shape best practice in other sectors — particularly around business continuity and supply chain security.

NIS2: Eighteen Sectors, One Baseline

If DORA is a specialist instrument, NIS2 is the general-purpose one. Directive (EU) 2022/2555, adopted in December 2022, replaces and strengthens the original NIS directive with a unified legal framework covering 18 critical sectors, generally applying to medium-sized and large companies.

The relationship between the two is worth stating precisely, because it trips people up. The financial sector is excluded from NIS2 because DORA is lex specialis — the specific law that overrides the general one. If you are a bank, you follow DORA. If you are a telecoms operator, a water utility, a hospital, a digital provider or a manufacturer in one of the covered sectors, NIS2 is your baseline.

NIS2 raises the bar in several directions at once. It extends risk management and notification duties to far more sectors — including telecommunications, which previously had its own separate regime. It demands that national cybersecurity strategies be updated. It places stricter requirements on supply chain security. And it pushes accountability upward: senior management is now expected to own cybersecurity outcomes, not delegate them to a technical team and hope.

The transposition problem

Here is the friction. NIS2 is a directive, which means each member state must write it into national law. Most have been slow. Spain opened its transposition process on 16 January 2025 with a public consultation on a preliminary draft law on cybersecurity coordination and governance. Other countries are at various stages, some further ahead, some lagging.

That staggered timeline creates a genuinely awkward situation for multinationals: the same company can be fully in scope in one country and barely regulated in another, with different reporting portals, different thresholds and different supervisory authorities. The directive also envisages repealing sectoral cybersecurity obligations that previously sat in the General Telecommunications Law, and it must be kept coherent with the CER directive's obligations for critical entities.

Caution: Do not wait for your national transposition to be finalised before you act. The obligations — risk assessments, security measures, incident reporting within short deadlines, demonstrable compliance — are already clear in the directive text. Companies that start late will be building controls under a deadline they no longer control.

The CRA: Security Comes to the Product Itself

The third wave targets something the first two largely leave alone: the products you buy. Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force on 10 December 2024. Its main obligations apply from 11 December 2027 — a date that sounds distant until you count the work involved.

Where DORA and NIS2 regulate the provision of services, the CRA regulates products with digital elements: software and hardware, from consumer devices to industrial components. It exists because the market has persistently under-supplied security. Buyers cannot easily tell whether a product was built with security in mind, and manufacturers have had little incentive to invest in it after the sale.

The CRA changes that with a set of interlocking duties:

  • Security by design, built into the product from the start rather than bolted on
  • Vulnerability management across the product's supported lifetime
  • An obligation to ship security updates, and to keep shipping them
  • Incident and actively exploited vulnerability reporting
  • Conformity assessment and CE marking under the regulation
  • Transparency obligations toward users
  • Clear responsibility assigned to manufacturers, importers and distributors

The CE marking element is the one to watch. It turns cybersecurity from a marketing claim into a condition of market access, in the same way the CE mark already works for electrical safety. If your product does not conform, you do not simply face reputational damage — you face being unable to place it on the European market. The CRA also sits alongside labelling initiatives such as the US Cyber Trust Mark for IoT devices, part of a broader international push toward making security visible and comparable at the point of purchase.

Where the Three Regulations Collide — and Where They Help

Read together, the three instruments cover a striking amount of ground. The table below summarises the practical differences a compliance team needs to hold in mind.

RegulationWho it hitsIn forceCore demand
DORAFinancial entities and their ICT providers17 Jan 2025Operational resilience and third-party risk
NIS218 critical sectors, medium and large firmsTransposing nationallyRisk management and incident reporting
CRAMakers of products with digital elementsMain duties from 11 Dec 2027Secure design, updates, CE marking

The complexity is not only in each regulation individually. It is in the interoperability between them, the deadlines that do not align, and the fact that different competent authorities will interpret and enforce them. A company that is a bank, a software vendor and a manufacturer of connected devices could plausibly find itself answerable to three different supervisory regimes at once, each with its own reporting platform and its own idea of what "timely notification" means.

That is where the real challenge for authorities lies too — and the source text is refreshingly candid about it. Regulators must promote the greatest possible simplicity, including in incident management and reporting platforms and in certification regimes. They must ensure resources are available, provide advice to businesses, and coordinate effectively across sectors so that overlapping obligations do not become contradictory ones.

Certification as the escape hatch

One practical thread runs through all of this: established security schemes and international certifications, such as the ISO 27000 family, are consolidating as the connective tissue that makes compliance tractable. If your organisation already runs a mature ISMS, you are not starting from zero. You are mapping existing controls to new obligations — a far cheaper exercise than building from scratch.

For companies that have invested in real security engineering rather than paperwork, the new regime is less of a burden than it looks. The organisations that struggle most will be those whose controls exist only on paper, because these regulations increasingly ask for evidence: test results, incident timelines, supply chain attestations, conformity assessments.

Important: These regulations shift the burden of proof onto you. Demonstrating compliance — through testing, documentation and reporting — is now as important as achieving it. An untested control and an absent control look identical to a supervisor.

What This Means for Your Security Programme

Step back from the legal detail and a coherent picture emerges. Europe has decided that digital resilience is infrastructure, not an IT concern, and it is using regulation to force the market to behave accordingly. The three instruments attack the problem from three angles: the financial system's operational continuity (DORA), the critical sectors' baseline hygiene (NIS2), and the security of the products everyone else depends on (CRA).

For a security leader, the practical response is not to build three separate compliance programmes. It is to build one strong security programme and map it outward. Start with an honest risk assessment across your critical services. Inventory your suppliers and understand which of them are critical. Get your incident detection and reporting capability to a standard where you could meet a 24-hour notification window without panic. And test — genuinely test — the controls you claim to have, because every one of these regimes eventually asks for proof.

The deadlines are staggered, but they are not generous. DORA is already live. NIS2 obligations are crystallising country by country. The CRA's main duties land in December 2027, which is roughly two full product development cycles away for most hardware makers. The organisations that treat this as a strategic opportunity to harden their operations, rather than a paperwork exercise to survive, will find themselves not just compliant but genuinely more difficult to breach. That, ultimately, is the point.

Request a scoping call · Penetration testing services