NIS2 und Cyber Resilience Act: Wirksamkeit muss man belegen

Zwei europäische Regelwerke haben in den vergangenen Monaten die Anforderungen an IT-Sicherheit im Mittelstand deutlich verschärft. Sie werden oft in einem Atemzug genannt, betreffen aber unterschiedliche Adressaten und lösen unterschiedliche Aufgaben aus. Was sie verbindet, ist eine Eigenschaft, die man leicht überliest: Es genügt nicht, Schutzmaßnahmen zu treffen. Man muss belegen können, dass sie wirken.

Zwei Regelwerke, zwei Adressaten

NIS2 ist eine Richtlinie, die Richtlinie (EU) 2022/2555. Sie richtet sich an Organisationen und regelt, wie ein Unternehmen seine eigene IT absichert, Vorfälle meldet und die Lieferkette im Blick behält. In deutsches Recht umgesetzt wurde sie durch das NIS-2-Umsetzungsgesetz, das am 5. Dezember 2025 verkündet wurde und am 6. Dezember 2025 in Kraft getreten ist. Die materiellen Pflichten stehen seither im BSI-Gesetz.

Der Cyber Resilience Act ist eine Verordnung, die Verordnung (EU) 2024/2847. Sie gilt unmittelbar, ohne nationales Umsetzungsgesetz, und richtet sich an Hersteller: an jeden, der ein Produkt mit digitalen Elementen in der EU auf den Markt bringt. Sie regelt nicht, wie ein Unternehmen sich schützt, sondern welche Sicherheitseigenschaften ein Produkt haben muss und wie lange der Hersteller dafür geradesteht. Der Cyber Resilience Act wird stufenweise wirksam. Die Bestimmungen zur Notifizierung von Konformitätsbewertungsstellen gelten seit dem 11. Juni 2026. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026. Die wesentlichen übrigen Verpflichtungen des CRA gelten ab dem 11. Dezember 2027.

Wer Software entwickelt und selbst betreibt, ist von beiden betroffen, in zwei verschiedenen Rollen. Das ist der Fall, der in der Praxis am häufigsten unterschätzt wird.

Wie viele Unternehmen es trifft

Die Zahl, die den Umfang am besten beschreibt, stammt vom BSI selbst: Bislang unterlagen rund 4.500 Organisationen der Regulierung, künftig sind es etwa 29.500 Einrichtungen, also ungefähr das Sechsfache. Der Sprung entsteht, weil NIS2 die betroffenen Sektoren erweitert und Größenschwellen einführt, unter die viele mittelständische Unternehmen fallen, die sich bisher nicht als kritische Infrastruktur verstanden haben.

Was seit wann gilt

NIS2: Die Wirksamkeitsprüfung ist eine eigene Pflicht

Der Kern der NIS2-Umsetzung steht in § 30 BSI-Gesetz. Betroffene Einrichtungen müssen geeignete technische und organisatorische Maßnahmen treffen und diese dokumentieren. Das Gesetz zählt zehn Bereiche auf, die abgedeckt sein müssen, unter anderem Risikoanalyse, Bewältigung von Sicherheitsvorfällen, Business Continuity, Sicherheit der Lieferkette, Kryptografie, Zugriffskontrolle und Multi-Faktor-Authentisierung.

Zwei dieser zehn Bereiche sind für die Qualitätssicherung unmittelbar relevant. Der eine betrifft die Sicherheit bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen einschließlich des Umgangs mit Schwachstellen. Der andere verlangt Konzepte und Verfahren zur Bewertung der Wirksamkeit der getroffenen Risikomanagementmaßnahmen.

Der zweite Punkt ist die eigentliche Neuerung. Eine Maßnahme umzusetzen und eine Maßnahme als wirksam nachzuweisen sind zwei verschiedene Aufgaben, und die zweite verlangt Verfahren, die man vorher festlegt. Das BSI wird an dieser Stelle konkret und nennt vier Bausteine: messbare Kennzahlen mit definierten Grenzwerten, interne und externe Audits, regelmäßige Berichte an die Unternehmensleitung sowie einen Verbesserungsprozess, der aus den Ergebnissen Konsequenzen zieht. Für die Einordnung des erreichten Stands verweist das BSI auf sein eigenes Reifegradmodell mit fünf Stufen, von „geplant“ bis „kontinuierlich verbessert“.

Wer das liest und an Testmanagement denkt, liegt nicht falsch: Kennzahl, Grenzwert, geplante Prüfung, dokumentiertes Ergebnis, abgeleitete Maßnahme. Das ist derselbe Regelkreis, nur auf Sicherheitsmaßnahmen statt auf Funktionalität angewendet.

Die Pflichten mit harten Fristen

NIS2 arbeitet mit Fristen, die keinen Interpretationsspielraum lassen. Die Registrierung beim BSI muss spätestens drei Monate nach dem Zeitpunkt erfolgen, zu dem eine Einrichtung erstmals oder erneut betroffen ist. Bei einem erheblichen Sicherheitsvorfall gilt eine dreistufige Meldekette: eine frühe Erstmeldung innerhalb von 24 Stunden, eine ausführlichere Meldung innerhalb von 72 Stunden und eine Abschlussmeldung spätestens einen Monat nach der 72-Stunden-Meldung.

Ebenfalls neu und für die Praxis folgenreich: Die Verantwortung für Umsetzung und Überwachung liegt ausdrücklich bei der Geschäftsleitung. Sie lässt sich nicht in die IT-Abteilung delegieren, und sie ist mit Schulungspflichten verbunden.

Cyber Resilience Act: Tests stehen im Anhang

Der CRA verpflichtet Hersteller, Cybersicherheit bereits in Entwurf und Entwicklung einzubauen, nach den Grundsätzen „secure by design“ und „secure by default“. Die konkreten Anforderungen stehen in Anhang I, und der ist zweigeteilt: Teil I beschreibt Eigenschaften, die das Produkt haben muss, Teil II den Umgang mit Schwachstellen über den gesamten Unterstützungszeitraum.

In Teil II steht die Anforderung, die dieses Thema zu einer Testmanagement-Aufgabe macht: Hersteller müssen wirksame und regelmäßige Tests und Überprüfungen der Sicherheit des Produkts durchführen. Nicht einmalig zur Zulassung, sondern fortlaufend. Dazu kommt die Pflicht, die enthaltenen Komponenten zu identifizieren und in einer Software-Stückliste, der Software Bill of Materials, in einem gängigen und maschinenlesbaren Format zu führen. Das BSI beschreibt sie treffend als die Zutatenliste der Software: welche Bibliotheken und weiteren Bestandteile stecken drin. Veröffentlicht werden muss sie nicht, geführt werden schon.

Gemeldet wird über die zentrale Meldeplattform der ENISA. Bei aktiv ausgenutzten Schwachstellen und schwerwiegenden Vorfällen ist zunächst innerhalb von 24 Stunden eine Frühwarnung und innerhalb von 72 Stunden eine vollständige Meldung erforderlich. Bei aktiv ausgenutzten Schwachstellen ist der Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Abhilfemaßnahme einzureichen. Bei schwerwiegenden Vorfällen folgt der Abschlussbericht innerhalb eines Monats nach der 72-Stunden-Meldung. Über den erklärten Unterstützungszeitraum schuldet der Hersteller kostenfreie Sicherheitsupdates. Dieser Zeitraum beträgt mindestens fünf Jahre, es sei denn, die erwartete Lebensdauer des Produkts ist kürzer.

Der unterschätzte Teil: Sicherheitsupdates sind Releases

Genau hier entsteht die Aufgabe, die in den meisten Projektplänen fehlt. Mindestens fünf Jahre Pflicht zu Sicherheitsupdates heißen: über Jahre hinweg Änderungen an einem produktiven Produkt, bei Kunden, die es einsetzen. Jedes dieser Updates ist ein Release. Jedes kann etwas kaputt machen, das vorher funktioniert hat.

Ein Hersteller, der Schwachstellen schnell schließen muss und keinen belastbaren Regressionstestbestand hat, steht vor einer unangenehmen Wahl: Er liefert schnell und riskiert Folgefehler beim Kunden, oder er testet gründlich und lässt die Schwachstelle länger offen. Beides ist teuer. Der Ausweg ist nicht mehr Personal, sondern ein Regressionsbestand, der risikobasiert priorisiert ist: Man testet nicht alles bei jedem Patch, sondern das, was am Änderungspfad hängt und geschäftskritisch ist. Diese Priorisierung muss vorher feststehen, nicht in der Nacht des Notfall-Patches entstehen.

Für NIS2-Betroffene gilt die Kehrseite. Auch wer Software nur einkauft und betreibt, muss Sicherheitsupdates einspielen, und zwar zügig. Dass ein Update den eigenen Betrieb nicht stört, weiß man nur, wenn man es prüft. Ein Abnahmetest für Fremdsoftware ist kein Luxus, er ist die Voraussetzung dafür, überhaupt schnell patchen zu können.

Was Testmanagement beiträgt und was nicht

Hier ist eine klare Abgrenzung fällig, weil rund um NIS2 viel verkauft wird, was mit dem Gesetz wenig zu tun hat. Testmanagement ist kein Ersatz für ein Informationssicherheits-Managementsystem, keine Zertifizierungsberatung und kein Penetrationstest. Wer ein ISMS aufbauen, eine Lieferkettenanalyse führen oder eine Sicherheitsarchitektur prüfen lassen will, braucht dafür die passenden Spezialisten.

Was Testmanagement beisteuert, ist der Teil, an dem beide Regelwerke denselben Bedarf haben, nämlich den strukturierten Nachweis:

• Ein Risikobild, das Anforderungen und Änderungen nach Eintrittswahrscheinlichkeit und Auswirkung bewertet und daraus die Prüftiefe ableitet. Es liefert die Begründung dafür, warum bestimmte Dinge tief und andere flach geprüft werden.
• Ein prüffähiges Testkonzept mit definierten Entry- und Exit-Kriterien. Ohne vorher festgelegte Kriterien gibt es keine Wirksamkeitsaussage, sondern nur ein Gefühl.
• Eine Requirements-Traceability-Matrix, die zeigt, welche Anforderung durch welchen Test abgedeckt ist. Sie ist in einem Audit das Dokument, das die Frage „Woher wissen Sie das?“ in einem Satz beantwortet.
• Eine risikobasierte Regressionsstrategie für den Unterstützungszeitraum. Sie entscheidet darüber, ob ein Sicherheitsupdate in Tagen oder in Wochen ausgeliefert werden kann.
• Ein dokumentierter Freigabe-Nachweis je Release, mit Ergebnis, offenen Punkten und benannten Restrisiken.

Nichts davon ist NIS2- oder CRA-spezifisch. Das ist der Punkt: Wer Qualität ohnehin datenbasiert steuert, muss für diese Regelwerke keine zweite Welt aufbauen, sondern seine bestehende Nachweiskette auf Sicherheitsthemen ausdehnen.

Wer was macht

Damit keine falsche Erwartung entsteht: Qelivia plant, steuert und dokumentiert das Testen. Wir erstellen das Risikobild, das Testkonzept, den Autoren-Standard und den Freigabe-Nachweis, und wir übernehmen Review und Abnahme des Testfallbestands. Die Tests selbst führt Ihr Team durch, in Ihrem Tool oder in einer von uns bereitgestellten Testumgebung. Der Grund ist derselbe wie bei jedem anderen Mandat: Das system- und fachspezifische Detailwissen liegt bei Ihnen, und niemand von außen kann es seriös ersetzen.

Ebenso deutlich: Ein Testkonzept ist keine Konformitätsbewertung nach dem CRA und keine Aufsichtsmeldung nach NIS2. Es ersetzt weder die rechtliche Prüfung noch die notifizierte Stelle, wo eine gefordert ist. Was es liefert, ist die technische Grundlage, auf der beides überhaupt erst aufsetzen kann.

Fazit

NIS2 und der Cyber Resilience Act sind zwei verschiedene Regelwerke mit einer gemeinsamen Frage. NIS2 fragt eine Organisation: Wirken Ihre Maßnahmen, und woher wissen Sie das? Der CRA fragt einen Hersteller: Ist Ihr Produkt sicher, und zwar über den gesamten Unterstützungszeitraum? Beide Fragen lassen sich nur mit Belegen beantworten, die während der Arbeit entstehen, nicht danach. Wer die Nachweiskette jetzt einzieht, hat den Beleg später als Nebenprodukt. Wer wartet, muss ihn rekonstruieren, und genau das geht bei Prüfergebnissen nicht.

Hinweis: Dieser Artikel gibt den Stand vom 25. August 2026 wieder und fasst öffentlich zugängliche Quellen des BSI und der EU-Institutionen zusammen. Er ist keine Rechtsberatung. Ob und in welcher Rolle Ihr Unternehmen von NIS2 oder vom Cyber Resilience Act betroffen ist, gehört anwaltlich geprüft.