NIS2, EU AI Act und CRA: die technische Umsetzung statt Papier-Compliance

1. Drei Regelwerke, ein gemeinsamer Kern

Seit Ende 2025 greifen im DACH-Raum drei umfangreiche Regelwerke annähernd gleichzeitig: das deutsche NIS2-Umsetzungsgesetz, der EU AI Act und der Cyber Resilience Act. In der Wahrnehmung vieler Geschäftsführungen ergibt das eine unübersichtliche Menge an Pflichten, die man am liebsten an eine Kanzlei delegieren würde.

Das ist verständlich und führt trotzdem in die falsche Richtung. Denn wer die drei Texte auf ihre technischen Anforderungen reduziert, findet einen erstaunlich kleinen gemeinsamen Kern: Man muss wissen, was man betreibt. Man muss merken, wenn etwas passiert. Man muss es melden können. Man muss belegen können, dass man sich gekümmert hat. Und man muss dieselben Anforderungen an seine Dienstleister weitergeben.

Diese fünf Sätze beschreiben keine Regulierungslast, sondern gute IT-Praxis. Der Unterschied zu vorher ist, dass sie jetzt schriftlich nachweisbar sein müssen. Genau daran scheitern Umsetzungen: nicht an fehlenden Maßnahmen, sondern daran, dass niemand die vorhandenen dokumentiert hat.

Ein zweiter Punkt wird regelmäßig unterschätzt: Auch wer selbst nicht in den Anwendungsbereich fällt, wird über die Lieferkette erreicht. NIS2 verpflichtet betroffene Unternehmen dazu, die Sicherheit ihrer Dienstleister zu bewerten. In der Praxis heißt das, dass Fragebögen und Vertragsklauseln bei Zulieferern und IT-Dienstleistern ankommen, die von NIS2 nie gehört haben. Wer darauf vorbereitet ist, gewinnt Ausschreibungen, für die andere nachreichen müssen.

2. NIS2: seit Dezember 2025 geltendes Recht

Das NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) wurde am 6. Dezember 2025 verkündet und gilt seitdem. Eine Übergangsfrist gibt es nicht. Nach BSI-Schätzung sind rund 29.500 Einrichtungen in achtzehn Sektoren betroffen — deutlich mehr als unter der Vorgängerregelung, weil unter anderem Abfallwirtschaft, Lebensmittelproduktion und Teile des verarbeitenden Gewerbes hinzugekommen sind.

Die Betroffenheit ergibt sich aus Sektor und Größe: in der Regel ab fünfzig Beschäftigten oder zehn Millionen Euro Jahresumsatz. Entscheidend für die Praxis ist der Charakter dieser Prüfung — sie ist eine Selbstidentifikationspflicht. Das BSI informiert Unternehmen nicht darüber, dass sie betroffen sind. Eine Umfrage von G DATA ergab, dass ein erheblicher Teil der Mittelständler die eigene Betroffenheit nicht kannte.

Die Registrierung erfolgt über das Melde- und Unterrichtungskanal-Portal des BSI (muk.bsi.bund.de), das am 6. Januar 2026 online ging. Die Frist nach § 33 BSIG endete am 6. März 2026, das BSI setzte eine Nachfrist bis zum 31. Juli 2026. Beide Termine sind verstrichen — was nichts daran ändert, dass eine nachträgliche Registrierung der einzig sinnvolle Weg ist.

Inhaltlich lassen sich die Pflichten in drei Blöcke gliedern. Das Risikomanagementnach § 30 BSIG umfasst zehn Maßnahmenbereiche — von der Risikoanalyse über Backup- und Notfallmanagement bis zu Mehrfaktor-Authentifizierung und Lieferkettensicherheit. Wer diese Liste liest, liest im Wesentlichen das Inhaltsverzeichnis eines Informationssicherheits-Managementsystems.

Die Meldepflicht nach § 32 BSIG ist dreistufig: eine Frühwarnung binnen 24 Stunden, ein Bericht binnen 72 Stunden, ein Abschlussbericht binnen eines Monats. Diese Fristen kennen keine Vorbereitungszeit. Wer den Ablauf nicht vorab festgelegt hat, verliert die ersten Stunden mit der Frage, wer eigentlich zuständig ist.

Der dritte Block betrifft die Geschäftsleitung unmittelbar: Nach § 38 BSIG muss sie die Maßnahmen billigen, ihre Umsetzung überwachen und sich regelmäßig schulen lassen. Für besonders wichtige Einrichtungen kommt nach § 39 BSIG eine Nachweispflicht hinzu, die innerhalb von drei Jahren nach Inkrafttreten — also bis Dezember 2028 — durch Audits oder Zertifizierungen zu erfüllen ist.

3. EU AI Act: was der Digital Omnibus verschoben hat

Rund um den EU AI Act kursiert seit Sommer 2026 eine Fehlinformation, die für Unternehmen teuer werden kann: dass die Verordnung „auf 2027 verschoben“ sei. Das ist falsch, und der Irrtum betrifft ausgerechnet die Pflichten, die den Mittelstand am unmittelbarsten treffen.

Tatsächlich ist die Verordnung (EU) 2024/1689 seit dem 1. August 2024 in Kraft und wird gestaffelt anwendbar. Seit dem 2. Februar 2025 gelten die Verbote inakzeptabler Praktiken und — für nahezu jedes Unternehmen relevant — die KI-Kompetenzpflicht nach Artikel 4. Seit dem 2. August 2025 gelten die Pflichten für Anbieter von General-Purpose-AI-Modellen.

Der sogenannte Digital Omnibus, Verordnung (EU) 2026/1744, wurde am 24. Juli 2026 im Amtsblatt veröffentlicht und trat am 27. Juli 2026 in Kraft. Verschoben hat er die Anwendung bestimmter Hochrisiko-Vorschriften: auf den 2. Dezember 2027 für eigenständige Hochrisiko-Systeme nach Anhang III und auf den 2. August 2028 für in regulierte Produkte eingebettete Systeme nach Anhang I. Nicht verschoben wurden die Verbote, die KI-Kompetenzpflicht, die GPAI-Regeln und die Transparenzpflichten nach Artikel 50.

Für einen typischen Mittelständler folgt daraus eine überschaubare Aufgabenliste. Die üblicherweise eingesetzten Werkzeuge — Assistenzsysteme für Text und Recherche, KI-Funktionen in Office-Paketen, Dokumentenextraktion in Workflows — fallen in aller Regel in die Klasse begrenzten Risikos. Kritisch wird es dort, wo KI über Menschen entscheidet oder mitentscheidet: Bewerbervorauswahl, Leistungsbewertung, Kreditwürdigkeit, Zugang zu Bildung. Solche Anwendungen sind Hochrisiko nach Anhang III — die Einstufung gilt unverändert, nur der Stichtag für die vollen Pflichten hat sich verschoben.

Die KI-Kompetenzpflicht ist in der Praxis der Punkt, an dem am häufigsten nichts geschieht, obwohl der Aufwand gering ist: eine dokumentierte Schulung mit Teilnehmerliste, eine schriftliche Nutzungsrichtlinie, eine Auffrischung bei wesentlichen Änderungen. Damit ist die Pflicht für die allermeisten Häuser erfüllt — und gleichzeitig das wirksamste Mittel gegen Shadow AI.

4. Cyber Resilience Act: Meldepflicht seit September 2026

Der Cyber Resilience Act, Verordnung (EU) 2024/2847, ist das dritte Regelwerk und wird von Mittelständlern am häufigsten übersehen — weil viele annehmen, er betreffe nur Hersteller von Hardware. Tatsächlich erfasst er Produkte mit digitalen Elementen, und dazu zählt eigenständig vertriebene Software. Wer ein Softwareprodukt, eine App oder ein vernetztes Gerät in Verkehr bringt, ist im Anwendungsbereich.

Der Zeitplan ist gestaffelt. Seit dem 11. Juni 2026 können Konformitätsbewertungsstellen die Erfüllung der Anforderungen bewerten. Seit dem 11. September 2026 gilt die Meldepflicht nach Artikel 14: Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle sind binnen 24 Stunden als Frühwarnung und binnen 72 Stunden mit weiteren Informationen über die zentrale Meldeplattform zu melden. Vollständig anwendbarwird die Verordnung am 11. Dezember 2027 — dann gelten Security-by-Design, das Management von Schwachstellen über den gesamten Produktlebenszyklus und die CE-Kennzeichnung.

Die technisch anspruchsvollste Anforderung ist das Schwachstellenmanagement über den Lebenszyklus. Sie setzt voraus, dass man weiß, was im eigenen Produkt steckt — und das ist die Aufgabe der SBOM, des maschinenlesbaren Komponentenverzeichnisses. Ohne sie ist die Frage „sind wir von dieser neu bekannt gewordenen Schwachstelle betroffen?“ eine mehrtägige Recherche. Mit ihr ist sie eine Abfrage von Minuten. Bei modernen Build-Werkzeugen entsteht eine SBOM praktisch nebenbei; der Aufwand liegt darin, sie systematisch zu archivieren und gegen aktuelle Schwachstellendatenbanken abzugleichen.

5. Die sechs Artefakte, die alle drei bedienen

Wer die drei Regelwerke getrennt abarbeitet, macht dieselbe Arbeit dreimal. Sinnvoller ist es, von den technischen Ergebnissen her zu denken. Sechs Artefakte decken den weit überwiegenden Teil der technischen Anforderungen ab.

Erstens das Asset- und Systeminventar. Welche Systeme werden betrieben, in welchen Versionen, auf welcher Infrastruktur, mit welchen Daten, unter wessen Verantwortung. Grundlage für NIS2-Risikomanagement und CRA-Schwachstellenmanagement gleichermaßen. Ein gepflegtes Verzeichnis in einem Repository ist dafür ausreichend — ein eingekauftes Werkzeug ist nicht erforderlich und ersetzt die Pflegearbeit ohnehin nicht.

Zweitens das KI-Inventar. Dieselbe Logik für KI-Systeme: Zweck, Anbieter, verarbeitete Daten, Verantwortlichkeit, Risikoeinstufung nach AI Act. Der Aufbau deckt gleichzeitig Shadow AI auf, weil er die Frage stellt, was tatsächlich genutzt wird — nicht, was genehmigt wurde.

Drittens der Meldeprozess. Ein einseitiges Dokument genügt: Wer entscheidet, ob ein Vorfall meldepflichtig ist; wer meldet; über welchen Kanal; welche Angaben werden in der Frühwarnung übermittelt; wer vertritt die zuständige Person. Dazu ein jährlicher Trockentest. Das ist die Maßnahme mit dem besten Verhältnis von Aufwand zu Wirkung im gesamten Themenfeld, weil sie im Ernstfall die ersten Stunden rettet.

Viertens die Protokollierung. Zentral gesammelte, gegen Manipulation geschützte und ausreichend lange aufbewahrte Protokolle sind die Voraussetzung dafür, einen Vorfall überhaupt beschreiben zu können. Ohne sie ist die 72-Stunden-Meldung eine Vermutung.

Fünftens die SBOM. Für eigene Softwareprodukte Pflicht unter CRA, für eingekaufte Software ein starkes Argument gegenüber dem Lieferanten. Automatisiert erzeugt, versioniert abgelegt, regelmäßig gegen Schwachstellendatenbanken geprüft.

Sechstens der Nachweisordner. Schulungsnachweise, Sitzungsprotokolle der Geschäftsleitung mit dokumentierter Billigung der Maßnahmen, Lieferantenbewertungen, Testprotokolle. Unspektakulär, und im Prüfungsfall das Einzige, was zählt. Der Grundsatz dahinter ist schlicht: Eine Maßnahme, die nicht dokumentiert ist, hat aus Sicht einer Behörde nicht stattgefunden.

6. Übersicht: Betroffenheit, Fristen, Sanktionen

7. Typische Fehler in der Umsetzung

Betroffenheit nicht geprüft. Der häufigste Fehler und zugleich der billigste zu beheben. Die Prüfung dauert einen halben Tag; sie zu unterlassen erzeugt im Schadensfall die unangenehme Situation, dass die fehlende Registrierung öffentlich sichtbar wird.

Compliance als Dokumentenprojekt. Ein Aktenordner mit Richtlinien, die niemand umsetzt, hilft weder im Prüfungsfall noch im Ernstfall. Umgekehrt sind vorhandene technische Maßnahmen ohne Dokumentation ebenfalls wertlos. Beides gehört zusammen — und beides entsteht schneller, wenn man von den sechs Artefakten aus denkt statt vom Gesetzestext.

Die Geschäftsleitung delegiert vollständig. NIS2 adressiert die Leitungsebene ausdrücklich: Billigung der Maßnahmen, Überwachung, eigene Schulung. Diese Pflichten sind nicht delegierbar. Ein Geschäftsführer, der nicht dokumentieren kann, dass er sich gekümmert hat, hat im Zweifel ein persönliches Problem.

Meldeprozess ungeübt. Ein Ablaufdokument, das nie durchgespielt wurde, hält der Realität nicht stand. Ein Trockentest pro Jahr — jemand ruft an, das Team spielt die ersten zwei Stunden durch — deckt zuverlässig auf, dass die hinterlegte Telefonnummer veraltet ist und niemand weiß, wer die Meldung freigibt.

Lieferanten nicht einbezogen. Die Lieferkettensorgfalt wird gern übersehen, ist aber der Punkt, an dem die Regulierung sich fortpflanzt. Ein knapper Fragebogen an die wichtigsten IT-Dienstleister und eine Vertragsklausel zur Vorfallsmeldung decken den größten Teil ab.

Auf die verschobenen Fristen warten. Die Hochrisiko-Pflichten des AI Act sind verschoben, die Einstufung ist es nicht. Wer ein Recruiting-System mit KI-Unterstützung betreibt, betreibt weiterhin ein Hochrisiko-System — er hat nur mehr Zeit für den Nachweis. Die Governance dafür entsteht nicht in vier Wochen.

8. Roadmap in fünf Schritten

1. Betroffenheit klären (Woche 1)NIS2-Betroffenheit anhand von Sektor, Beschäftigtenzahl und Umsatz prüfen, mit schriftlichem Ergebnis und Datum — auch ein begründetes „nicht betroffen“ ist ein wertvolles Dokument. Parallel klären, ob eigene Software unter den CRA fällt.
2. Inventare aufbauen (Woche 1–3)System-, Dienstleister- und KI-Inventar anlegen. Für das KI-Inventar aktiv nachfragen, nicht nur Genehmigtes erfassen — sonst entsteht ein Verzeichnis der Wunschvorstellung.
3. Meldeprozess festlegen (Woche 2–3)Zuständigkeiten, Kanäle, Vertretungsregelung und Inhalte der Frühwarnung auf einer Seite festhalten. BSI-Registrierung nachholen, falls noch nicht erfolgt. Termin für den ersten Trockentest setzen.
4. Technische Lücken schließen (Woche 3–10)Zentrale Protokollierung, Mehrfaktor-Authentifizierung, geprüfte Backup-Wiederherstellung, SBOM-Erzeugung im Build-Prozess. Nach Risiko priorisieren, nicht nach Aufwand.
5. Nachweise und Rhythmus etablieren (ab Woche 6, fortlaufend)Schulungen durchführen und dokumentieren, Billigung durch die Geschäftsleitung protokollieren, Lieferantenfragebögen versenden. Halbjährliche Überprüfung der Inventare und jährlicher Meldetest im Kalender verankern.

9. Fazit und Quick-Check

Die Gleichzeitigkeit der drei Regelwerke wirkt bedrohlicher, als die Umsetzung tatsächlich ist. Wer sie nicht als drei Rechtsprojekte, sondern als eine Reihe technischer Artefakte begreift, arbeitet einmal statt dreimal — und baut dabei überwiegend Dinge, die ohnehin fehlten: Inventare, Protokolle, ein geübter Meldeweg, dokumentierte Schulungen, geprüfte Lieferanten.

Zwei Punkte verdienen dabei Vorrang. Der Meldeprozess, weil er als Einziger keine Vorbereitungszeit kennt: Tritt der Vorfall ein, läuft die 24-Stunden-Frist ab dem Bekanntwerden, unabhängig davon, ob jemand weiß, wer zuständig ist. Und die Inventare, weil ohne sie keine der anderen Pflichten sinnvoll erfüllbar ist — man kann weder Risiken bewerten noch Vorfälle beschreiben noch Betroffenheit von einer Schwachstelle feststellen, wenn unklar ist, was überhaupt betrieben wird.

Acht Fragen, von denen die meisten mit Arbeit eines einzelnen Tages beantwortbar werden. Die Regulierung verlangt keine perfekte Sicherheit — sie verlangt den Nachweis, dass man sich strukturiert gekümmert hat. Dieser Nachweis ist deutlich einfacher zu führen, wenn man ihn nebenbei erzeugt, statt ihn nachträglich zu rekonstruieren.

Häufige Fragen

Fachglossar

NIS2UmsuCG

NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz — das deutsche Gesetz zur Umsetzung der EU-Richtlinie NIS2. Es ändert im Kern das BSI-Gesetz und ist am 6. Dezember 2025 ohne Übergangsfrist in Kraft getreten.

Wesentliche und wichtige Einrichtung

Die beiden Betroffenheitsklassen unter NIS2. Sie unterscheiden sich in der Aufsichtsintensität und im Bußgeldrahmen, nicht wesentlich im Pflichtenkatalog. Die Einordnung ergibt sich aus Sektor, Beschäftigtenzahl und Umsatz.

SBOM

Software Bill of Materials — maschinenlesbares Verzeichnis aller in einem Produkt enthaltenen Komponenten und ihrer Versionen. Grundlage dafür, bei einer neu bekannt gewordenen Schwachstelle innerhalb von Minuten statt Tagen zu wissen, ob man betroffen ist.

KI-Inventar

Verzeichnis aller im Unternehmen eingesetzten KI-Systeme mit Zweck, Anbieter, verarbeiteten Daten, Verantwortlichkeit und Risikoeinstufung. Ausgangspunkt jeder Bewertung nach EU AI Act und zugleich das wirksamste Mittel gegen Shadow AI.

Digital Omnibus

Verordnung (EU) 2026/1744, am 24. Juli 2026 im Amtsblatt veröffentlicht und seit dem 27. Juli 2026 in Kraft. Sie verschiebt die Anwendungstermine für bestimmte Hochrisiko-Pflichten des EU AI Act, lässt Verbote, KI-Kompetenz-, GPAI- und Transparenzpflichten aber unberührt.

Lieferkettensorgfalt (IT)

Pflicht, die Cybersicherheit der eingesetzten Dienstleister und Lieferanten zu bewerten und vertraglich abzusichern. Praktisch der Grund, warum NIS2 auch Unternehmen erreicht, die selbst nicht in den Anwendungsbereich fallen — über die Anforderungen ihrer Kunden.