NIS2, DORA and the CRA: three legal acts, one approach
In the previous post we discussed the importance of analysing the internal and external issues relevant to the organisation, as they constitute the environment our ISMS lives in. While other external issues are sometimes ignored, legal requirements are a well-known part of the external context that most people are concerned with. Below we look at three acts that shape the current EU cybersecurity and resilience landscape.
The new act on security of Network and Information Systems (NIS2) is the second iteration of the EU’s directive aimed at establishing a high common baseline of cybersecurity across all member states. It expands the scope of cybersecurity requirements compared to the original NIS Directive, applying to both medium and large organisations across 18 sectors including energy, transport, health, digital infrastructure, and ICT service providers, with some entities in scope regardless of their size. Those in scope are classified as either essential or important, depending on their sector and size.
The Digital Operational Resilience Act (DORA) is an EU regulation that ensures financial entities can withstand, respond to, and recover from information and communication technology (ICT) disruptions and threats. It applies to almost all financial institutions operating within the EU, such as banks, insurers, investment firms, and payment providers, as well as their third-party technology providers, such as cloud platforms and software vendors.
The Cyber Resilience Act (CRA) is an EU regulation that sets cybersecurity requirements for products with digital elements placed on the EU market. This includes software applications, connected devices, as well as their remote data processing components. It applies to manufacturers, importers, and distributors, covering the entire product lifecycle from design through to end-of-support.
Note that only two of the three are regulations. Regulations and directives are both legal acts of the Union, but they land differently. DORA and the CRA apply directly and in the same form across the Union, while NIS2 is a directive that reaches organisations through the national law of each member state.
Faced with three legal texts, the natural first move is to open three spreadsheets and start mapping each one separately. When read side by side, however, we notice a recurring theme.
Don’t take this article as legal advice
What we do here is reading through the legal texts for the purpose of gaining overall understanding, and specifically focusing on common issues that can help us reduce the effort of dealing with each of them in isolation. The article does not elaborate on all requirements in the texts.
We are not lawyers and we do not provide legal advice.
Not all three acts apply to everyone
We look at the three acts as a well-known set of EU cybersecurity legislation. Which obligations bind a particular organisation is a question that needs to be answered case-by-case, when analysing the context of the organisation.
Why does the law not hand us a checklist?
A rule that has to fit tens of thousands of organisations cannot prescribe the same measures to all of them. For example, NIS2 covers eighteen sectors. The same requirements apply to a national transmission system operator and to a fifty-person managed service provider, and they have to keep applying as technology evolves. Therefore, the obligation is written as a standard of care rather than as a list of controls.
Let’s analyse how that standard is calibrated:
Taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation, the measures referred to in the first subparagraph shall ensure a level of security of network and information systems appropriate to the risks posed. When assessing the proportionality of those measures, due account shall be taken of the degree of the entity’s exposure to risks, the entity’s size and the likelihood of occurrence of incidents and their severity, including their societal and economic impact. — NIS2, Article 21(1)
Exposure, size, likelihood, severity, and the cost of a measure weighed against what it buys — these are the ingredients of a risk assessment and a risk treatment decision. The Directive does not merely permit a risk-based approach; it describes and requires one.
We have seen this construction before
The GDPR in Article 32(1) requires appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art and the costs of implementation. Six years later, NIS2 reuses that construction almost word for word.
Article 21(2) widens the frame by adding a second instruction: The measures must be based on an all-hazards approach, protecting network and information systems, as well as their physical environment from incidents. So we are not only concerned with malicious attacks, but any source of disruption, including failed suppliers, facility floods, botched changes and hardware failures.
It’s important to note the proportionality requirement. If the measures have to be appropriate to the risks, then the records of the risk assessment become part of the defence in case of legal proceedings. This is why, regardless of whether risk is expressed in numbers or in words , it needs to be expressed clearly to justify the decisions. When risk is expressed ambiguously, it’s not only difficult to act on, but also difficult to defend the decisions made.
What about the other two acts?
Given that DORA applies specifically to financial entities, it assumes an overall risk management system to be in place. It explicitly requires that ICT risk management is integrated into the system through a sound, comprehensive and well-documented framework. The general objective is quick, efficient and comprehensive response to ICT risk, which in turn ensures a high level of digital operational resilience of the entities and the wider Union financial network.
The CRA also follows a risk-based approach, but applies it slightly differently. Whereas NIS2 and DORA are concerned with the security and the overall resilience of the organisations themselves, as well as their digital systems, the CRA is concerned with the security and safety of the products. Therefore it doesn’t explicitly require a risk management framework, but it does require manufacturers to undertake an assessment of the cybersecurity risks associated with a product and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases — the product’s lifecycle.
To circle back to where we started, a rule that has to fit tens of thousands of organisations cannot prescribe the same measures to all of them. What it can do is mandate the method that leads each organisation to its own answer.
What else do the three acts have in common, and where do they differ?
Beyond risk management, the three texts overlap on six high-level themes: reporting to an authority, third-party and supply chain risk, vulnerability handling, testing what has been put in place, keeping the organisation able to continue operating, and training the people who run it.
| NIS2 | DORA | CRA | |
|---|---|---|---|
| Reporting to an authority | Significant incidents are reported to the CSIRT or, where applicable, the competent authority. Early warning within 24 hours, notification within 72 hours, final report within one month of that notification (Art. 23) | Major ICT-related incidents are reported to the competent authority. Initial notification within 4 hours of classification and no later than 24 hours from becoming aware, intermediate report within 72 hours, final report within one month of the intermediate report (Art. 19 *) | Actively exploited vulnerabilities and severe incidents affecting product security are reported to the CSIRT designated as coordinator, and to ENISA. Early warning within 24 hours, notification within 72 hours, final report within 14 days of a corrective measure becoming available for a vulnerability, or within one month of the notification for an incident (Art. 14 **) |
| Third-party and supply chain risk | One of the ten minimum measures, covering relationships with direct suppliers and service providers (Art. 21), plus Union-level assessments of critical supply chains (Art. 22) | An entire chapter dedicated: a Register of Information on every contractual arrangement, prescribed contractual terms, concentration risk, and EU oversight of critical ICT third-party providers (Art. 28–44) | Due diligence when integrating third-party components, and a software bill of materials covering at least the top-level dependencies (Art. 13; Annex I, Part II) |
| Vulnerability handling | Part of security in acquisition, development and maintenance, including vulnerability handling and disclosure (Art. 21) | Sits inside detection and the testing programme (Art. 10, 24–27) | The most prescriptive of the three: identify and document vulnerabilities, remediate without delay, run a coordinated disclosure policy, and distribute security updates free of charge (Annex I, Part II) |
| Testing what is in place | Policies and procedures to assess the effectiveness of the measures (Art. 21) | A digital operational resilience testing programme, with threat-led penetration testing at least every three years for entities the supervisor identifies (Art. 24–27) | Effective and regular tests and reviews of product security (Annex I, Part II) |
| Continuity of operations | Business continuity, backup management, disaster recovery and crisis management (Art. 21) | ICT business continuity policy, response and recovery plans, backup and restoration procedures (Art. 11–12) | Not applicable as an organisational duty; expressed as availability of essential and basic functions and resilience properties of the product (Annex I, Part I) |
| Training and awareness | Training for members of management bodies (Art. 20), and cyber hygiene and training for staff (Art. 21) | Compulsory ICT security awareness and resilience training for staff and senior management (Art. 13) | No equivalent; the obligation attaches to the product rather than to the workforce |
*) DORA does not specify the reporting deadlines in its main text.
Article 20 mandates the European Supervisory Authorities (ESAs) to develop the technical standards
that do, adopted by the Commission as
Delegated Regulation (EU) 2025/301
**) CRA reporting obligations apply from 11 September 2026
It’s not surprising that we can draw this parallel between three apparently very distinct acts. They are all concerned with cybersecurity , and most of the themes above are ones a security programme would typically cover. The difference lies in the detail of each theme, and in how far each act goes with it.
Deciding what is applicable, and how each of them will be addressed on a continual basis, is exactly the tailoring work done during the implementation and operation of an ISMS . Whichever of these acts apply to us, they enter that process as inputs rather than as a separate programme of work. Before we look deeper into how an ISMS aligned with ISO/IEC 27001 can help us satisfy those requirements, let’s quickly check one more issue.
Who does the obligation belong to?
NIS2 and DORA aim to raise the security and resilience of the EU internal market. They apply to organisations that are embedded in the Union’s economy and cannot simply be removed from it. Therefore they explicitly name management bodies as responsible for ensuring compliance, escalating non-compliance to personal consequences for the members of those bodies.
Member States shall ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures taken by those entities in order to comply with Article 21, oversee its implementation and can be held liable for infringements by the entities of that Article. — NIS2, Article 20(1)
Notice the three functions of management bodies above: approve, oversee, and be held liable (accountable) for the results. The quote essentially defines governance. For more details on governance, management and ownership of risk please refer to Governing risk & how to be at ease with it in our risk management series.
How far the personal consequences reach
Article 20(1) allows member states to hold members of management bodies liable for infringements of Article 21, in both essential and important entities.
Article 32(5) goes further, but only for essential entities. A competent authority may ask the relevant body or court to prohibit temporarily any natural person at Chief Executive Officer or legal representative level from exercising managerial functions in that entity until the deficiencies are remedied.
DORA assigns the ultimate responsibility for managing ICT risk to the management body in Article 5(2), but leaves penalties to the member states, which apply them through their existing supervisory frameworks.
The CRA takes a different approach. Since it strives to ensure a baseline of security and safety in products, besides penalties on the economic operators behind a product, it escalates non-compliance by potentially removing the product from the market. While management bodies are not explicitly named, the loss of market access is a practical lever that lets the CRA reach manufacturers established outside the Union as effectively as those inside it. Losing access to the Union’s market is a commercial consequence that many boards cannot easily delegate away.
In essence, all three acts rely on proper governance to ensure compliance. While NIS2 and DORA explicitly map this function to management bodies of organisations in scope, the CRA leverages economic pressure to do the same.
The one system to rule them all
While being ISO/IEC 27001 certified does not mean we are automatically compliant with applicable legislation, a management system built to ISO/IEC 27001 can (and should) be tailored to meet most of what these articles ask for.
In fact, as we noted at the start, determining what legislation applies to the organisation, what it requires, and which interested parties (including reporting authorities and other regulatory bodies) have a stake in the outcome is what the standard asks for in Clause 4, and gaps in that analysis, or in how it is operated, can result in nonconformities during an audit. The same goes for reporting authorities and communication to concerned parties. Clause 7.4 requires the organisation to determine what it needs to communicate, when, with whom, and how, for everything relevant to the management system, internal and external communication alike.
So how does the ISMS standard map to the three acts?
| The obligation | NIS2 | DORA | CRA | ISO/IEC 27001 |
|---|---|---|---|---|
| Risk assessment and treatment | Art. 21 | Art. 6, 8 | Art. 13 | 6.1.2, 6.1.3, 8.2, 8.3 |
| Approval and oversight by leadership | Art. 20 | Art. 5 | N/A | 5.1–5.3, 9.3 |
| Assessing the effectiveness of the measures | Art. 21 | Art. 6, 24–27 | Annex I, Part II | 9.1, 9.2 |
| Incident handling | Art. 21 | Art. 17–19 | Art. 14 | A 5.24–5.28 |
| Business continuity and crisis management | Art. 21 | Art. 11, 12 | N/A | A 5.29, 5.30 |
| Supply chain security | Art. 21 | Art. 28–30 | Art. 13 | A 5.19–5.23 |
| Vulnerability handling and secure development | Art. 21 | Art. 24, 25 | Annex I, Part II | A 8.8, 8.25–8.31 |
| Training and awareness | Art. 20, 21 | Art. 5, 13 | N/A | 7.2, 7.3, A 6.3 |
Note that the mapping shows where each obligation lives in the standard, not how far it has to go; where an act is more prescriptive than the control, the act sets the depth.
More detailed mapping
For the digital infrastructure and ICT service management sectors, where the Commission has specified the NIS2 requirements in detail, ENISA publishes technical implementation guidance with a companion mapping table that links each requirement to ISO/IEC 27001 and to several other security frameworks.
In essence, the standard gives us the operating system, while the legislation is one source of inputs that are processed by it.
What remains outside the system
The purpose of an ISMS is to provide a structured way of securing the subject in scope. When legislation applies security requirements to that subject, the ISMS should be designed to satisfy them. However, legal acts also set obligations that are often not directly related to securing anything, but rather to enable authorities to enforce the law. Such obligations need to be met outside the ISMS.
Under NIS2, organisations are expected to self-assess whether they are in scope and register. Each entity assesses its own size and sector against the Directive’s annexes, then registers with the national competent authority or CSIRT, providing its name, contact details, sector and the member states where it operates. Certain digital providers register through a separate route, into a registry maintained by ENISA. Because NIS2 is a directive, both the registration route and the detail of what must be provided come from national law, and they differ from one member state to the next. The rest of the NIS2 obligations are about security, but evidence of the management body’s training and of their approval of the risk-management measures has to be kept for the authority.
References to national law
Since NIS2 is a directive, the text that binds an organisation is the national one. The names, dates and competent authorities differ:
- Germany: transposed by the NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG ), promulgated on 5 December 2025 and in force from 6 December, with no general transition period. The obligations sit in the new BSI-Gesetz (BSIG) it enacted, which replaced the 2009 law of the same name. Registration runs through the BSI portal; the initial deadline was 6 March 2026.
- Austria: Netz- und Informationssystemsicherheitsgesetz 2026 (NISG 2026) , BGBl. I Nr. 94/2025, promulgated on 23 December 2025 and in force from 1 October 2026. Registration with the new Bundesamt für Cybersicherheit is due within three months of that date (§ 29(3)), and a self-declaration on implemented risk management measures twelve months later (§ 33(1)).
- Belgium: law of 26 April 2024 , in force since 18 October 2024, making Belgium one of the few member states to meet the deadline. The Centre for Cybersecurity Belgium acts as national cybersecurity authority. Essential and important entities register within five months of falling in scope (Art. 13); digital infrastructure and service providers had a two-month deadline (Art. 14).
- Sweden: Cybersäkerhetslag (2025:1506) , adopted on 10 December 2025 and in force since 15 January 2026, replacing the 2018 Information Security Act. MSB coordinates, with supervision distributed across sectoral authorities.
Not every member state has arrived. As of mid-2026 France, Ireland, the Netherlands and Spain were still in legislative procedure, and in July 2026 the Commission referred all four to the Court of Justice, asking for a lump sum and daily penalties until transposition is complete. The Commission maintains the authoritative list of national transposition measures on the EUR-Lex national implementing measures page for the Directive.
Outside the EU, neither Switzerland nor the UK is bound by NIS2. Switzerland requires operators of critical infrastructure to report significant cyberattacks to the BACS within 24 hours, but imposes no equivalent of Article 21, while the UK’s Cyber Security and Resilience Bill amends the NIS Regulations 2018 rather than replacing them.
DORA asks for the most exacting record of the three — the register of information. Every contractual arrangement for ICT services needs to be recorded in a prescribed format, kept current, and submitted to the competent authority at least once a year. Where the supervisor identifies an entity for threat-led penetration testing, evidence of it must be preserved: a summary of findings, the remediation plans, and documentation that the test met the standard the regulation sets. The management body’s approval of the ICT risk management framework and of the policy on the use of ICT third-party services has to be on the record as well.
For the CRA a conformity assessment comes first. For most products this is a self-assessment, with third-party assessment required for class II important products, for critical products, and for class I products where the harmonised standards have not been fully applied. Then an EU declaration of conformity and a CE marking. Behind them sits the technical file, drawn up before the product reaches the market, kept current through the support period, and held at the disposal of market surveillance authorities for ten years or for the support period, whichever is longer. The software bill of materials (SBOM) lives inside that file.
Compliance proves good practice — it doesn’t replace it
Meeting the obligations set by law is important. But we must not hyper-focus on them and miss the aspects of security that applicable legislation does not cover. Legal acts and standards exist to set baselines — a minimum level of security appropriate for the context. Many organisations need, or can benefit from, a higher bar than the law prescribes.
In our view, compliance with a framework, whether a legal act or an industry standard, is not a final destination but a natural outcome of addressing security and risk appropriately. Work in that order and the evidence an auditor or a supervisor asks for is a by-product of decisions that had to be made anyway.
This is what we mean when we say that compliance proves good practice rather than replacing it .
What’s next
In this post we read through three legal acts that shape EU cybersecurity legislation: NIS2, DORA and the CRA. We saw that a law written for tens of thousands of very different organisations cannot prescribe the measures each of them needs, so it prescribes the method that produces them instead. That method is risk management, which is also what an ISMS is built around. We then compared the three acts across the themes they share, looked at how each of them assigns accountability for compliance, and mapped their requirements onto the clauses and controls of ISO/IEC 27001. We were also explicit about where the standard has no counterpart: registration, formal records and product conformity paperwork serve the enforcement of the law rather than the security of anything, and are met outside the management system.
In the next post we will finish the context analysis. Regulators are only one of the parties with a stake in our information, so we will look at who else has one and what each of them requires. From there we will derive the scope of our ISMS.
Understanding the environment our ISMS lives in