Regulierungs-Kollision 2026: NIS2, DORA, CRA und AI Act — die CIO-Landkarte

Was die „Regulierungs-Kollision 2026" ist

Regulierungs-Kollision 2026 bezeichnet die Situation, dass vier EU-Regelwerke — NIS2, DORA, Cyber Resilience Act und AI Act — gleichzeitig auf dieselbe IT-Organisation wirken. Sie regeln verschiedene Objekte (Betreiber, Finanzunternehmen, Produkte, KI-Systeme), verlangen aber dieselben Fähigkeiten: Risikomanagement, Lieferkettenkontrolle, fristgebundene Vorfallsmeldung und prüffähige Nachweise.

Für einen CIO ist das kein juristisches Detailproblem, sondern ein Kapazitätsproblem. Jedes der vier Regelwerke hat einen eigenen Adressaten, eine eigene Aufsichtsbehörde und eine eigene Uhr. Wer sie als vier getrennte Compliance-Projekte aufsetzt, baut vier Risikoregister, vier Incident-Prozesse, vier Lieferantenfragebögen und vier Dokumentationslinien — für in weiten Teilen identische Kontrollen.

Die gute Nachricht: Die Regelwerke überlappen genau dort, wo Delivery-Governance ohnehin arbeitet. Wer seine Kontrollen einmal sauber baut und pro Regelwerk nur die Nachweisform variiert, hat 2026 einen strukturellen Vorteil gegenüber Organisationen, die vier Silos parallel füttern. Eine erste Standortbestimmung liefern die kostenlosen Quick-Checks für NIS2, CRA und AI Act in je rund drei Minuten.

Die vier Regelwerke auf einen Blick — wer wird eigentlich reguliert?

Der häufigste Denkfehler ist die Frage „Welches Gesetz gilt für uns?". Richtig ist: Sie gelten meist mehrfach, weil sie verschiedene Rollen adressieren. Ein Maschinenbauer mit vernetzten Produkten ist NIS2-Betreiber (als wichtige Einrichtung) und zugleich CRA-Hersteller (für sein Produkt). Ein Versicherer ist DORA-Finanzunternehmen und setzt KI-Scoring ein, das unter den AI Act fällt. Die Rollen addieren sich, sie ersetzen sich nicht.

NIS2 (Richtlinie (EU) 2022/2555, siehe https://eur-lex.europa.eu/eli/dir/2022/2555/oj) reguliert Betreiber wichtiger und kritischer Einrichtungen. In Deutschland ist das NIS2-Umsetzungsgesetz seit dem 06.12.2025 in Kraft — ohne Übergangsfrist, mit persönlicher Haftung der Geschäftsleitung; die BSI-Registrierungsfrist lief bereits am 06.03.2026 ab (siehe https://www.bsi.bund.de/DE/Themen/Regulierte-Wirtschaft/regulierte-wirtschaft_node.html). Details im Fahrplan NIS2-Umsetzungsgesetz: Pflichten für Geschäftsführer.

DORA (Verordnung (EU) 2022/2554, siehe https://eur-lex.europa.eu/eli/reg/2022/2554/oj) gilt seit dem 17.01.2025 für Finanzunternehmen und deren IKT-Drittdienstleister. Der Cyber Resilience Act (Verordnung (EU) 2024/2847, siehe https://eur-lex.europa.eu/eli/reg/2024/2847/oj) adressiert Hersteller von Produkten mit digitalen Elementen — die Meldepflichten greifen ab dem 11.09.2026, die volle Anwendbarkeit inklusive CE-Kennzeichnung ab dem 11.12.2027 (siehe https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act).

Der AI Act (Verordnung (EU) 2024/1689, siehe https://eur-lex.europa.eu/eli/reg/2024/1689/oj) reguliert KI-Systeme nach Risikoklasse: Verbotene Praktiken gelten seit dem 02.02.2025, GPAI-Pflichten seit dem 02.08.2025, die Hochrisiko-Pflichten nach Anhang III ab dem 02.08.2026. Der Digital-Omnibus-Vorschlag der Kommission vom 19.11.2025 würde diesen Hochrisiko-Termin verschieben — bis zur formalen Annahme bleibt der ursprüngliche Zeitplan verbindlich (Einordnung im Digital-Omnibus-Update).

Die vier Kollisionszonen — wo dieselbe Arbeit vierfach verlangt wird

Kollisionszone 1: Risikomanagement. NIS2 verlangt ein Risikomanagement für Netz- und Informationssysteme, DORA ein IKT-Risikomanagement-Rahmenwerk, der CRA eine Risikobewertung über den Produktlebenszyklus, der AI Act ein Risikomanagementsystem für Hochrisiko-KI. Vier Anforderungen, ein Kern: identifizieren, bewerten, behandeln, überwachen, dokumentieren. Wer vier Risikoregister führt, produziert vier Wahrheiten — und wird spätestens in der ersten Aufsichtsprüfung an Widersprüchen scheitern.

Kollisionszone 2: Lieferkette und Drittparteien. NIS2 macht Lieferkettensicherheit zur Pflicht, DORA verlangt ein Informationsregister aller IKT-Drittdienstleister samt Ausstiegsstrategien und Vertragsklauseln (siehe unser Guide DORA Art. 30: Pflichtklauseln für IT-Dienstleister), der CRA erzwingt eine Software-Stückliste (SBOM) und damit Transparenz über die eigene Komponenten-Lieferkette, der AI Act verlangt Nachweise über Trainingsdaten und Modell-Herkunft. Alle vier fragen im Kern: Weißt du, was in deinem System steckt, und wer haftet dafür?

Kollisionszone 3: Vorfalls- und Schwachstellenmeldung. Hier ist die Kollision am härtesten spürbar, weil sie unter Zeitdruck stattfindet: Ein einziger Sicherheitsvorfall in einem KI-gestützten Produkt eines Finanzdienstleisters kann gleichzeitig eine NIS2-Frühwarnung, eine DORA-Erstmeldung, eine CRA-Meldung und eine AI-Act-Vorfallsmeldung auslösen — an vier verschiedene Adressaten, mit vier verschiedenen Fristen.

Kollisionszone 4: Nachweise und Governance-Dokumentation. Alle vier Regelwerke verlangen prüffähige Artefakte: Policies, Rollen, Freigaben, Testnachweise, Protokolle. Der Unterschied liegt fast nur in der Verpackung — nicht im Inhalt. Ein einmal sauber gebauter Governance-Dokumenten-Satz bedient alle vier, wenn er von Anfang an regelwerksneutral strukturiert ist.

Die Fristen-Matrix: vier Uhren, ein Vorfall

Die operative Kernfrage lautet nicht „welches Gesetz gilt?", sondern „welche Uhr läuft, sobald wir Kenntnis erlangen?". Alle vier Regelwerke starten ihre Fristen mit der Kenntniserlangung — nicht mit der internen Bestätigung und schon gar nicht mit dem Fix. Das ist der Grund, warum improvisierte Ticket-Workflows in der Praxis reißen.

NIS2 fordert nach Artikel 23 eine Frühwarnung binnen 24 Stunden, eine Vorfallsmeldung binnen 72 Stunden und einen Abschlussbericht binnen eines Monats. DORA verlangt nach Artikel 19 und den zugehörigen technischen Regulierungsstandards eine Erstmeldung schwerwiegender IKT-Vorfälle unverzüglich nach der Klassifizierung und spätestens binnen 24 Stunden nach Kenntnis, gefolgt von Zwischenbericht und Abschlussbericht. Der CRA verlangt nach Artikel 14 bei aktiv ausgenutzten Schwachstellen 24 Stunden Frühwarnung, 72 Stunden Vorfallsmeldung und den Abschlussbericht 14 Tage nach Verfügbarkeit einer Abhilfe. Der AI Act verlangt nach Artikel 73 die Meldung schwerwiegender Vorfälle bei Hochrisiko-KI unverzüglich, spätestens jedoch 15 Tage nach Kenntnis — mit verkürzten Fristen bei weitreichenden Verstößen oder Todesfällen.

Praktische Konsequenz: Die schärfste Uhr diktiert den Prozess. Wenn Ihre Organisation in mehr als einem Regelwerk steht, müssen Erkennung, Klassifizierung und Erstmeldung binnen 24 Stunden funktionieren — inklusive Wochenende. Das ist keine Dokumentationsfrage, sondern eine Frage von Rufbereitschaft, Entscheidungsbefugnis und vorbereiteten Meldevorlagen. Die Fristen-Unterschiede zwischen DORA und NIS2 vertieft der Vergleich DORA vs. NIS2.

Der Konsolidierungs-Ansatz: ein Kontroll-Set statt vier Silos

Die Alternative zu vier Compliance-Projekten ist ein regelwerksneutrales Kontroll-Set, das einmal gebaut und viermal referenziert wird. Das Prinzip ist aus COBIT und dem NIST Cybersecurity Framework 2.0 bekannt: Kontrollen sind die Substanz, Regelwerke sind nur die Sicht darauf (siehe https://www.nist.gov/cyberframework). Statt „NIS2-Risikoregister" und „DORA-Risikoregister" führen Sie ein Risikoregister mit einem Mapping-Feld, das pro Eintrag ausweist, welche Regelwerke betroffen sind.

Fünf gemeinsame Bausteine tragen den Großteil der Last. Erstens: ein Asset- und Systeminventar, das Produkte, Services, IKT-Dienstleister und KI-Systeme in derselben Struktur führt. Zweitens: ein Risikoregister mit Regelwerks-Mapping. Drittens: ein einziger Incident-Prozess mit der schärfsten Uhr (24 Stunden) und einem Klassifizierungsschritt, der entscheidet, an welche Behörden gemeldet wird. Viertens: ein Drittparteien-Register, das DORA-Informationsregister, NIS2-Lieferkettensorgfalt und CRA-SBOM aus derselben Quelle bedient. Fünftens: ein Nachweis-Repository, in dem Policies, Freigaben und Testergebnisse versioniert liegen.

Der Hebel liegt in der Vermeidung von Doppelarbeit, nicht in der Vermeidung von Pflichten. Die Pflichten bleiben vollständig — aber die Kontrolle „Wir erkennen, klassifizieren und melden Vorfälle binnen 24 Stunden" wird einmal gebaut, einmal getestet und viermal nachgewiesen. Wer sie viermal baut, testet sie erfahrungsgemäß keinmal richtig.

• Asset- und Systeminventar (Produkte, Services, IKT-Dienstleister, KI-Systeme — eine Struktur)
• Risikoregister mit Regelwerks-Mapping-Feld (NIS2 / DORA / CRA / AI Act)
• Ein Incident-Prozess, getaktet auf die schärfste Uhr (24 h), mit Klassifizierungs-Gate
• Ein Drittparteien-Register als Quelle für DORA-Informationsregister, NIS2-Lieferkette und CRA-SBOM
• Ein versioniertes Nachweis-Repository (Policies, Rollen, Freigaben, Testnachweise)

90-Tage-Fahrplan für den CIO

Der Fahrplan setzt bewusst an der Betroffenheitsanalyse an — nicht am Tooling. Die häufigste teure Fehlentscheidung ist der Kauf einer GRC-Suite, bevor klar ist, welche Rollen die Organisation überhaupt einnimmt.

1. 1Tage 1–15: Rollen-Inventur. Klären Sie je Geschäftsbereich, in welcher Rolle Sie stehen (NIS2-Betreiber, DORA-Finanzunternehmen oder -Drittdienstleister, CRA-Hersteller, AI-Act-Anbieter oder -Betreiber). Ergebnis: eine Rollen-Matrix, freigegeben von der Geschäftsleitung.
2. 2Tage 16–30: Kontroll-Mapping. Legen Sie die bestehenden Kontrollen gegen die vier Regelwerke und markieren Sie Überlappungen. Ergebnis: eine Gap-Liste, in der jede Lücke genau einer Kontrolle zugeordnet ist — nicht einem Regelwerk.
3. 3Tage 31–50: Incident-Prozess auf 24 Stunden takten. Definieren Sie Erkennung, Klassifizierung, Meldeentscheidung, Eskalation und Vorlagen. Ergebnis: ein Runbook mit benannten Rollen und einer 24/7-Erreichbarkeit.
4. 4Tage 51–70: Drittparteien-Register konsolidieren. Führen Sie Lieferantenlisten, IKT-Register und SBOM-Quellen zusammen. Ergebnis: eine Quelle, vier Sichten.
5. 5Tage 71–90: Meldeübung („Tabletop") mit echtem Zeitdruck. Simulieren Sie einen Vorfall, der mehrere Regelwerke gleichzeitig auslöst, und stoppen Sie die Zeit bis zur ersten Meldung. Ergebnis: eine belastbare Aussage, ob die 24-Stunden-Uhr hält.

Drei Anti-Patterns, die 2026 teuer werden

Anti-Pattern 1: Vier Projekte, vier Budgets, vier Projektleiter. Es entstehen vier Wahrheiten über dieselben Systeme. Spätestens wenn eine Aufsichtsbehörde das Risikoregister sehen will, kollidieren die Versionen. Konsolidieren Sie auf ein Programm mit vier Sichten.

Anti-Pattern 2: Compliance als Dokumentenprojekt. Alle vier Regelwerke verlangen Wirksamkeit, nicht Papier. Ein Meldeprozess, der nie unter Zeitdruck geprobt wurde, ist kein Prozess, sondern ein Dokument. Die 24-Stunden-Uhr ist der einzige belastbare Test.

Anti-Pattern 3: KI als Sonderfall behandeln. KI-Systeme fallen nicht nur unter den AI Act — sie sind zugleich Teil der NIS2-Angriffsfläche, potenziell CRA-Produktbestandteil und im Finanzsektor DORA-relevant. Wer eine separate „KI-Governance" neben der IT-Governance aufbaut, verdoppelt die Kollision, statt sie zu lösen. Wie sich KI-Reife messen lässt, zeigt der KI-Delivery-Reifegrad.

Wer den eigenen Reifegrad in allen vier Zonen belastbar bewerten will, findet die passenden Assessment-Vorlagen in unserem Template-Katalog — die Preise und Umfänge stehen transparent auf der Pricing-Seite.