Regulatory Collision 2026: NIS2, DORA, CRA and the AI Act — a CIO Map

What the "Regulatory Collision 2026" actually is

Regulatory Collision 2026 describes the situation where four EU regimes — NIS2, DORA, the Cyber Resilience Act and the AI Act — act on the same IT organization at the same time. They regulate different objects (operators, financial entities, products, AI systems) but demand the same capabilities: risk management, supply chain control, time-bound incident reporting and auditable evidence.

For a CIO this is not a legal detail problem, it is a capacity problem. Each regime has its own addressee, its own supervisory authority and its own clock. Set them up as four separate compliance projects and you build four risk registers, four incident processes, four vendor questionnaires and four documentation trails — for largely identical controls.

The good news: the regimes overlap exactly where delivery governance already operates. Build your controls once and vary only the evidence format per regime, and you hold a structural advantage in 2026 over organizations feeding four silos in parallel. Our free quick checks for NIS2, CRA and the AI Act give you a first position fix in about three minutes each.

The four regimes at a glance — who is actually regulated?

The most common mistake is asking "which law applies to us?". The correct answer is usually: several, because they address different roles. A manufacturer of connected machinery is a NIS2 operator (as an important entity) and a CRA manufacturer (for its product). An insurer is a DORA financial entity and uses AI scoring that falls under the AI Act. Roles add up; they do not replace each other.

NIS2 (Directive (EU) 2022/2555, see https://eur-lex.europa.eu/eli/dir/2022/2555/oj) regulates operators of important and essential entities. In Germany the NIS2 implementation act has been in force since 6 December 2025 — with no transition period and personal liability for management; the BSI registration deadline already expired on 6 March 2026 (see https://www.bsi.bund.de/EN/Themen/Regulierte-Wirtschaft/regulierte-wirtschaft_node.html). Details in our roadmap NIS2 implementation act: duties for managing directors.

DORA (Regulation (EU) 2022/2554, see https://eur-lex.europa.eu/eli/reg/2022/2554/oj) has applied since 17 January 2025 to financial entities and their ICT third-party providers. The Cyber Resilience Act (Regulation (EU) 2024/2847, see https://eur-lex.europa.eu/eli/reg/2024/2847/oj) addresses manufacturers of products with digital elements — reporting duties start on 11 September 2026, full applicability including CE marking on 11 December 2027 (see https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act).

The AI Act (Regulation (EU) 2024/1689, see https://eur-lex.europa.eu/eli/reg/2024/1689/oj) regulates AI systems by risk class: prohibited practices have applied since 2 February 2025, GPAI obligations since 2 August 2025, and the high-risk obligations under Annex III from 2 August 2026. The Commission's Digital Omnibus proposal of 19 November 2025 would postpone that high-risk date — until formally adopted, the original timeline remains binding (context in our Digital Omnibus update).

The four collision zones — where the same work is demanded four times

Collision zone 1: risk management. NIS2 requires risk management for network and information systems, DORA an ICT risk management framework, the CRA a risk assessment across the product lifecycle, the AI Act a risk management system for high-risk AI. Four requirements, one core: identify, assess, treat, monitor, document. Run four risk registers and you produce four truths — and the first supervisory audit will find the contradictions.

Collision zone 2: supply chain and third parties. NIS2 makes supply chain security mandatory, DORA requires a register of information covering all ICT third-party providers including exit strategies and contract clauses (see our guide DORA Article 30: mandatory clauses for IT providers), the CRA forces a software bill of materials (SBOM) and therefore transparency over your component supply chain, and the AI Act demands evidence about training data and model provenance. All four ask the same question at heart: do you know what is inside your system, and who is liable for it?

Collision zone 3: incident and vulnerability reporting. This is where the collision bites hardest, because it happens under time pressure: a single security incident in an AI-supported product of a financial services provider can simultaneously trigger a NIS2 early warning, a DORA initial notification, a CRA report and an AI Act incident report — to four different addressees, with four different deadlines.

Collision zone 4: evidence and governance documentation. All four regimes require auditable artefacts: policies, roles, approvals, test records, logs. The difference is almost entirely in the packaging, not the substance. One properly built set of governance documents serves all four, provided it is structured regime-neutral from the start.

The deadline matrix: four clocks, one incident

The operational question is not "which law applies?" but "which clock starts the moment we become aware?". All four regimes start their deadlines at awareness — not at internal confirmation, and certainly not at the fix. That is why improvised ticket workflows tear in practice.

NIS2 requires, under Article 23, an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. DORA requires, under Article 19 and the associated regulatory technical standards, an initial notification of major ICT incidents promptly after classification and no later than 24 hours after awareness, followed by an intermediate and a final report. The CRA requires, under Article 14, a 24-hour early warning for actively exploited vulnerabilities, a 72-hour notification and a final report 14 days after a remedy becomes available. The AI Act requires, under Article 73, reporting of serious incidents involving high-risk AI immediately and no later than 15 days after awareness — with shorter deadlines for widespread infringements or fatalities.

The practical consequence: the tightest clock dictates the process. If your organization sits in more than one regime, detection, classification and initial notification must work within 24 hours — weekends included. That is not a documentation question but a question of on-call rotation, decision authority and prepared reporting templates. Our comparison DORA vs. NIS2 goes deeper on the differences.

The consolidation approach: one control set instead of four silos

The alternative to four compliance projects is a regime-neutral control set, built once and referenced four times. The principle is familiar from COBIT and the NIST Cybersecurity Framework 2.0: controls are the substance, regimes are merely views onto them (see https://www.nist.gov/cyberframework). Instead of a "NIS2 risk register" and a "DORA risk register", you keep one risk register with a mapping field that records which regimes each entry touches.

Five shared building blocks carry most of the load. First: an asset and system inventory holding products, services, ICT providers and AI systems in one structure. Second: a risk register with a regime mapping field. Third: a single incident process running on the tightest clock (24 hours) with a classification gate that decides which authorities get notified. Fourth: a third-party register that feeds the DORA register of information, NIS2 supply chain diligence and the CRA SBOM from one source. Fifth: an evidence repository holding versioned policies, approvals and test results.

The leverage lies in avoiding duplicate work, not in avoiding duties. The duties remain in full — but the control "we detect, classify and report incidents within 24 hours" is built once, tested once and evidenced four times. Build it four times and, in our experience, it never gets tested properly at all.

• Asset and system inventory (products, services, ICT providers, AI systems — one structure)
• Risk register with a regime mapping field (NIS2 / DORA / CRA / AI Act)
• One incident process, clocked to the tightest deadline (24 h), with a classification gate
• One third-party register feeding the DORA register, NIS2 supply chain diligence and CRA SBOM
• One versioned evidence repository (policies, roles, approvals, test records)

90-day roadmap for the CIO

The roadmap deliberately starts with applicability, not with tooling. The most common expensive mistake is buying a GRC suite before it is clear which roles the organization actually occupies.

1. 1Days 1–15: role inventory. Determine per business unit which role you hold (NIS2 operator, DORA financial entity or third-party provider, CRA manufacturer, AI Act provider or deployer). Output: a role matrix signed off by management.
2. 2Days 16–30: control mapping. Map existing controls against all four regimes and mark the overlaps. Output: a gap list where each gap maps to exactly one control — not to one regime.
3. 3Days 31–50: clock the incident process to 24 hours. Define detection, classification, reporting decision, escalation and templates. Output: a runbook with named roles and 24/7 reachability.
4. 4Days 51–70: consolidate the third-party register. Merge vendor lists, ICT registers and SBOM sources. Output: one source, four views.
5. 5Days 71–90: run a tabletop reporting exercise under real time pressure. Simulate an incident that triggers several regimes at once and time how long the first notification takes. Output: a defensible answer to whether the 24-hour clock holds.

Three anti-patterns that get expensive in 2026

Anti-pattern 1: four projects, four budgets, four project managers. You end up with four truths about the same systems. The moment a regulator asks to see the risk register, the versions collide. Consolidate into one programme with four views.

Anti-pattern 2: compliance as a documentation project. All four regimes demand effectiveness, not paper. A reporting process that has never been rehearsed under time pressure is not a process, it is a document. The 24-hour clock is the only meaningful test.

Anti-pattern 3: treating AI as a special case. AI systems do not only fall under the AI Act — they are part of the NIS2 attack surface, potentially a CRA product component, and DORA-relevant in financial services. Building a separate "AI governance" next to IT governance doubles the collision instead of resolving it. Our AI delivery maturity model shows how to measure AI readiness inside the existing governance.

To assess your own maturity across all four zones, our template catalogue holds the matching assessments — scope and prices are transparent on the pricing page.