NIS2 und Cyber Resilience Act: Was Softwarehersteller nachweisen müssen

Dieser Beitrag ordnet die Anforderungen aus technischer Sicht ein und stellt keine Rechtsberatung dar. Ob und in welchem Umfang die Regelwerke für Ihr Unternehmen gelten, klären Sie bitte anwaltlich.

Zwei europäische Regelwerke beschäftigen Softwarehersteller derzeit parallel, und sie werden häufig in einen Topf geworfen. Sie stellen aber unterschiedliche Fragen.

NIS2 fragt nach Ihrem Betrieb

Die NIS2-Richtlinie zielt auf die Cybersicherheit von Organisationen in bestimmten Sektoren. Wer betroffen ist, muss Risikomanagementmaßnahmen ergreifen und bestimmte Vorfälle melden. Die Geschäftsleitung haftet dabei persönlich für die Umsetzung – das ist der Punkt, der die Aufmerksamkeit erzeugt hat.

Für die technische Praxis relevant sind vor allem:

• Risikoanalyse und Sicherheitskonzepte für die eigenen Informationssysteme.
• Bewältigung von Sicherheitsvorfällen inklusive Meldewegen und Fristen.
• Sicherheit der Lieferkette, also auch die Bewertung Ihrer Dienstleister und Komponenten.
• Verfahren zur Bewertung der Wirksamkeit der ergriffenen Maßnahmen.

Der letzte Punkt ist derjenige, für den ein Penetrationstest der naheliegende Nachweis ist. „Wir haben Maßnahmen ergriffen" ist eine Behauptung. „Wir lassen die Wirksamkeit regelmäßig extern prüfen und hier sind die Berichte" ist ein Nachweis.

Ein zweiter, oft übersehener Punkt: NIS2 wirkt über die direkt betroffenen Unternehmen hinaus. Wer an ein betroffenes Unternehmen liefert, bekommt dessen Anforderungen über den Vertrag weitergereicht. Viele Softwarehersteller sind deshalb faktisch betroffen, ohne selbst unter die Richtlinie zu fallen.

Der Cyber Resilience Act fragt nach Ihrem Produkt

Der CRA setzt an einer anderen Stelle an: nicht beim Betrieb der Organisation, sondern bei Produkten mit digitalen Elementen, die in der EU auf den Markt kommen. Er verlangt unter anderem:

• Security by Design und by Default – Produkte müssen in einem sicheren Auslieferungszustand sein.
• Schwachstellenbehandlung über den Supportzeitraum, inklusive Bereitstellung von Sicherheitsupdates.
• Eine Software-Stückliste (SBOM) über die enthaltenen Komponenten.
• Meldepflichten für aktiv ausgenutzte Schwachstellen.
• Technische Dokumentation, die die Konformität belegt.

Hier geht es um den Nachweis, dass ein Produkt dem Stand der Technik entspricht. Ein Prüfbericht über das Produkt selbst – Anwendungstest, Code-Review – ist dafür das passende Dokument.

Was ein Report leisten muss, um als Nachweis zu taugen

Nicht jeder Report eignet sich für diesen Zweck. Aus Auditsicht braucht es mindestens:

Bestandteil	Warum
Scope-Beschreibung	Legt fest, worüber die Aussage gilt – und worüber nicht
Zeitraum und Prüfer	Ordnet den Bericht einem Stand und einer Verantwortung zu
Methodik mit Standardbezug	Macht die Abdeckung nachvollziehbar (etwa OWASP ASVS)
Bewertung nach CVSS	Einheitlicher, extern anerkannter Maßstab
Reproduktionsschritte	Belegt, dass tatsächlich geprüft wurde
Retest-Nachweis	Zeigt, dass Befunde behoben wurden – oft der entscheidende Teil

Der letzte Punkt wird regelmäßig unterschätzt. Ein Auditor interessiert sich weniger für die Liste der gefundenen Probleme als dafür, was daraus geworden ist. Ein Report ohne Retest dokumentiert einen Mangel. Ein Report mit Retest dokumentiert einen funktionierenden Prozess.

Ein praktikabler Rhythmus

Für die meisten Softwarehersteller hat sich ein einfaches Muster bewährt:

1. Kontinuierlich: automatisierte Abhängigkeitsprüfung in der Pipeline, SBOM-Erzeugung beim Build.
2. Quartalsweise: leichter Testdurchlauf nach größeren Releases.
3. Jährlich: vollständiger Anwendungstest mit Report und Retest.
4. Anlassbezogen: vor größeren Architekturänderungen oder vor einem Kunden-Audit.

Das erzeugt eine lückenlose Nachweiskette, ohne den Jahresetat zu sprengen. Und es beantwortet die Frage, die im Audit tatsächlich gestellt wird: nicht „haben Sie getestet?", sondern „wie stellen Sie fortlaufend sicher, dass Ihr Produkt sicher bleibt?".