Most organisations facing more than one EU cybersecurity regulation build a separate programme for each, and produce the same artefacts several times over. They do not need to. The regulations were drafted at different times for different purposes, but they co
The short answer
Most organisations facing more than one EU cybersecurity regulation build a separate programme for each, and produce the same artefacts several times over. They do not need to. The regulations were drafted at different times for different purposes, but they converge on a small set of underlying capabilities — knowing what is in your product, hearing when something is wrong, being able to tell the right people in time, and proving all three afterwards.
The practical consequence: **one well-built artefact usually answers a requirement in two or three instruments at once**. What does not transfer is the *obligation* itself. Producing an SBOM does not make you CRA-compliant; it satisfies a requirement that CRA, NIS2 and DORA each state in their own terms, and each will judge it against its own criteria.
Who this applies to
You are in multi-regulation scope if more than one of these is true:
Overlap is the norm, not the exception. A connected medical device manufacturer selling to EU hospitals is in CRA and RED scope for the product, likely NIS2 through the customer relationship, and AI Act scope if any component makes automated clinical determinations.
- You place a product with digital elements on the EU market → **CRA**, Regulation (EU) 2024/2847
- You operate in an essential or important sector under Annex I or II → **NIS2**, Directive (EU) 2022/2555
- You are a financial entity under Article 2 → **DORA**, Regulation (EU) 2022/2554
- You provide or deploy an AI system, particularly a high-risk one → **AI Act**, Regulation (EU) 2024/1689
- Your product is radio equipment with an internet connection → **RED Article 3(3)**, Directive 2014/53/EU as activated by Delegated Regulation (EU) 2022/30
The seven artefacts that carry the most weight
Ordered by how many instruments they answer.
**1. Software bill of materials**
| Instrument | Where it appears | |---|---| | **CRA** | Annex I Part II — vulnerability handling requires an SBOM covering at least the top-level dependencies, in a commonly used machine-readable format | | **NIS2** | Article 21(2)(d) — supply chain security, including security-related aspects of relationships with direct suppliers | | **DORA** | Articles 28–30 — ICT third-party risk, and the register of information on contractual arrangements |
One inventory, generated in CI, in SPDX or CycloneDX. The CRA is the most prescriptive on format, so build to the CRA standard and the other two are comfortably answered.
**Where the overlap stops:** DORA's register of information is contractual, not technical. It records who your ICT providers are and under what terms — an SBOM does not contain that. They are complementary artefacts, not the same one.
**2. Coordinated vulnerability disclosure policy**
| Instrument | Where it appears | |---|---| | **CRA** | Article 13(8) and Annex I Part II — a policy on coordinated vulnerability disclosure, and a contact address for reporting | | **NIS2** | Article 21(2)(e) — security in acquisition, development and maintenance, including vulnerability handling and disclosure |
One published policy, one monitored contact point, one named owner with a deputy. The document is identical; only the regulatory reference in the header changes.
**3. Incident response procedure**
| Instrument | Where it appears | |---|---| | **CRA** | Article 14 — reporting actively exploited vulnerabilities and severe incidents | | **NIS2** | Article 23 — significant incident notification, and Article 21(2)(b) incident handling | | **DORA** | Articles 17–19 — ICT-related incident management, classification and reporting | | **AI Act** | Article 73 — serious incident reporting for high-risk systems |
The *procedure* is one document. **The clocks and the recipients are not.** This is the single most common and most expensive confusion, and it is worth being precise about it:
Build one runbook with a decision point at the top that asks which instrument applies to this event and which entity you are. Do not build three runbooks.
**4. Risk management framework**
| Instrument | Where it appears | |---|---| | **NIS2** | Article 21(1) — appropriate and proportionate technical, operational and organisational measures | | **DORA** | Articles 5–15 — the ICT risk management framework | | **AI Act** | Article 9 — a risk management system for high-risk AI, established and maintained across the lifecycle | | **CRA** | Article 13(2)–(3) — a cybersecurity risk assessment, documented in the technical documentation |
One methodology, one register, four regulatory references. **But note the AI Act diverges in kind, not just in wording**: its risk framing concerns risk *to health, safety and fundamental rights*, not only risk to the organisation. An information-security risk register does not cover it. Extend the methodology rather than assuming it transfers.
**5. Access control and authentication**
NIS2 Article 21(2)(i) and (j) cover human resources security, access control policies, asset management, and multi-factor authentication. DORA Article 9 covers protection and prevention, including access management. CRA Annex I Part I requires products to protect against unauthorised access by appropriate control mechanisms.
The organisational policy answers NIS2 and DORA. **The CRA requirement is different in nature** — it is about how the *product* behaves, not how your company operates. A strong corporate access policy does not satisfy it.
**6. Logging and monitoring**
CRA Annex I Part I requires products to record and monitor relevant internal activity, including access to and modification of data. NIS2 Article 21(2) covers detection under incident handling. DORA Article 10 covers detection mechanisms. AI Act Article 12 requires automatic logging over the lifetime of a high-risk system.
Same technical capability, four justifications. The AI Act imposes the longest retention thinking, so design to that and the rest follow.
**7. Governance and management accountability**
NIS2 Article 20 requires management bodies to approve the cybersecurity risk-management measures, oversee implementation, and follow training. DORA places the ICT risk management framework under the management body. The AI Act requires human oversight arrangements for high-risk systems under Article 14.
**One board minute, properly drafted, evidences all three.** This is the cheapest cross-regulation win available and it is routinely missed, because governance evidence is produced by a different part of the organisation than technical evidence.
- **NIS2 Article 23**, stated in the Directive: early warning within **24 hours**, incident notification within **72 hours**, final report within **one month**.
- **CRA Article 14**: early warning within **24 hours**, a fuller notification within **72 hours**, and a final report tied to the availability of a corrective or mitigating measure.
- **DORA**: classification criteria and reporting windows for major ICT-related incidents are set in delegated and implementing acts adopted under the Regulation, not in the Article text. Verify the current windows against the acts themselves before writing a runbook.
Where the mapping breaks down
Four failure modes, in order of how often they cause trouble.
**Assuming a satisfied requirement transfers as compliance.** It does not. Each regulation judges the artefact against its own criteria, with its own supervisor. An SBOM built for the CRA answers a NIS2 supply-chain question — it does not make you NIS2-compliant.
**Ignoring lex specialis.** NIS2 Article 4 provides that where a sector-specific Union act imposes at least equivalent obligations, that act applies instead. For financial entities, DORA displaces NIS2 Articles 21 and 23. Running both in parallel produces evidence nobody will ask for. See our detailed treatment of the DORA and NIS2 interaction.
**Mapping at framework level instead of article level.** "We are ISO 27001 aligned, so we are covered" is the most expensive sentence in EU compliance. Certification schemes and regulations do not share a unit of obligation. A control that satisfies an ISO objective may leave a specific article requirement unaddressed, and the gap is only visible article by article.
**Forgetting that Directives reach you through national law.** NIS2 is a Directive. Its practical requirements arrive via your Member State's transposition, which may be stricter or differently scoped than the text. Any mapping conclusion not checked against national law is provisional.
How to build the map
1. **Establish scope per instrument, per product or entity.** Scope is rarely company-wide. Portfolios are mixed, and group structures split the answer. 2. **Decompose to article level.** Not "NIS2 requires supply-chain security" but "Article 21(2)(d) requires security-related aspects of relationships with direct suppliers, evidenced by X." 3. **Attach each obligation to an artefact you already have or must build.** Most organisations discover they have 60–70% of the evidence and cannot demonstrate it. 4. **Record which instruments each artefact answers, and against which article.** This is the map. Without the article reference it is a list, not a map. 5. **Track freshness.** An SBOM from last year's release answers nothing. Most cross-regulation programmes fail on staleness, not on absence.
Tools available on NexCyber
- Free applicability assessment — establish scope across CRA, NIS2, DORA, AI Act and RED
- Compliance responsibility mapper — RACI by role across instruments
- Penalty calculator — maximum exposure by regulation
Further reading
→ NIS2 × CRA overlap — the six shared obligation areas → DORA × NIS2 — which instrument governs when both apply → AI Act × CRA overlap for connected products → What the CRA requires of an SBOM → NIS2 incident reporting timelines
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Obligation mapping depends on your scope, your Member State's transposition where a Directive applies, and the current text of delegated acts. Confirm with your competent authority or a qualified adviser.*
This is an educational explainer. For the canonical regulation reference, see the dedicated Assessment page — or run an assessment to see how it applies to your product.