NIS2 wird als Sicherheitsthema behandelt, und für die meisten Unternehmen ist es das nicht. Es ist ein Legacy-Thema, das als Sicherheitsthema ankommt.
Der Grund steht im Gesetz. Das BSIG verlangt in der Fassung des NIS2-Umsetzungsgesetzes, die seit Dezember 2025 gilt, in § 30 Risikomanagementmaßnahmen in zehn Bereichen. Mehrere davon sind keine Frage der Absicht, sondern der Bauart: Ein System, das sich nicht aktualisieren lässt, ohne dass jemand es von Hand begleitet, erfüllt sie nicht, egal wie viel Sorgfalt das Team aufbringt.
Dieser Artikel übersetzt die Anforderungen in technische Befunde und eine Reihenfolge. Er ist keine Rechtsberatung, und er beantwortet auch nicht, ob Sie betroffen sind: Das hängt an Sektor, Größe und Umsatz, und dafür gibt es die Prüfhilfen des BSI und im Zweifel eine Anwältin.
Warum das ein Legacy-Thema ist
Von den zehn Bereichen in § 30 BSIG sind vier für ein gewachsenes System strukturell schwierig, und an ihnen entscheidet sich die Sache.
Sicherheit in Entwicklung und Wartung, einschließlich Schwachstellenbehandlung. Das setzt voraus, dass eine gemeldete Schwachstelle in einer Abhängigkeit auch geschlossen werden kann. In einem System auf einer Sprachfassung ohne Wartung ist genau das nicht möglich: Das Paket gibt es, die Korrektur gibt es, und beide setzen eine Fassung voraus, die das System nicht hat.
Sicherheit der Lieferkette. Gemeint sind Dienstleister und Zulieferer, und für eine Anwendung heißt das auch: die Pakete, die sie mitbringt. Wer nicht sagen kann, was installiert ist, kann über seine Lieferkette nichts aussagen.
Aufrechterhaltung des Betriebs, einschließlich Backup-Management und Wiederherstellung. Nicht die Existenz von Sicherungen, sondern die Wiederherstellung. Die meisten Häuser haben das eine und nicht das andere geprobt.
Zugriffskontrolle und Mehrfaktor-Authentisierung. In einem System aus der Zeit vor diesen Anforderungen liegt die Anmeldung oft in der Anwendung selbst, ohne eine Stelle, an der ein zweiter Faktor überhaupt andocken könnte.
Keiner dieser vier Punkte ist mit einem Produkt zu erledigen. Alle vier sind Fragen an die Bauart, und darin liegt der Unterschied zwischen einer Sicherheitsmaßnahme und einer Modernisierung.
Welche Befunde in einem alten PHP-System regelmäßig dabei sind, steht in Zehn Lücken, die in jedem alten PHP-System stecken.
Die Befunde, die jedes Mal dabei sind
Übersetzt man die Bereiche in eine Bestandsaufnahme, kommt in gewachsenen Systemen mit großer Zuverlässigkeit dieselbe Liste heraus.
Eine Sprach- oder Framework-Fassung ohne Sicherheitskorrekturen. Abhängigkeiten, für die es keine Herkunft mehr gibt, weil die Sperrdatei fehlt oder das Paket aufgegeben wurde. Zugangsdaten im Repository oder in einer Konfigurationsdatei auf dem Server. Ein gemeinsames Administratorkonto, das mehrere Personen kennen. Sicherungen, die nie zurückgespielt wurden. Und Protokolle, die entweder nicht existieren oder nach sieben Tagen verschwinden.
Diese Befunde sind keine Überraschung und auch kein Vorwurf. Sie sind das übliche Ergebnis von zehn Jahren Betrieb unter anderen Anforderungen. Neu ist nur, dass sie jetzt einen Adressaten haben.
Die Lieferkette, die niemand als solche liest
Von den zehn Bereichen ist die Lieferkette der, bei dem technische Teams zuerst an Verträge denken und an ihre eigenen Pakete zuletzt. Dabei ist der zweite Teil der, den sie selbst in der Hand haben.
Eine Anwendung bringt Fremdcode mit, und für den gilt dieselbe Frage wie für einen Dienstleister: Woher kommt er, wer pflegt ihn, und was passiert, wenn er aufhört. Die Antwort darauf ist erzeugbar und muss nicht erinnert werden:
# Eine Aufstellung, die aus dem Bau faellt statt aus dem
# Gedaechtnis. Taeglich, nicht einmal im Jahr.
composer audit --format=json > schwachstellen.json
composer licenses --format=json > herkunft.json
# Und die unangenehmste Zeile: Pakete, die seit zwei Jahren
# keine Veroeffentlichung mehr hatten. Ein aufgegebenes Paket
# ist ein Zulieferer, der nicht mehr ans Telefon geht.
composer outdated --direct --format=json | jq -r '.installed[] | "\(.name) \(.version) \(.latest)"'Zwei Dinge fallen dabei regelmäßig auf, und beide sind Lieferkettenbefunde im Sinne des Gesetzes. Das eine sind Pakete ohne Pflege, für die es keinen Nachfolger gibt. Das andere sind Pakete, die von Hand verändert wurden und deshalb keine Korrektur mehr annehmen, ohne dass die Änderung verloren geht. Beides steht in keinem Vertrag und ist trotzdem genau das, was die Anforderung meint.
Tun reicht nicht, nachweisen gehört dazu
Der Punkt, der technische Teams am meisten überrascht: Das Gesetz verlangt auch Verfahren zur Bewertung der Wirksamkeit der Maßnahmen. Es genügt also nicht, dass etwas getan wird. Es muss zeigbar sein, dass es wirkt.
Praktisch heißt das, dass drei Dinge zusammenkommen müssen, und keines davon ist aufwendig, wenn es von Anfang an mitläuft.
Eine Liste dessen, was da ist, und zwar erzeugt statt gepflegt. Eine Aufstellung der Abhängigkeiten mit Fassung und Herkunft entsteht aus dem Bau und ist damit immer aktuell, eine Tabelle im Laufwerk ist es nach einem Quartal nicht mehr.
Ein Protokoll, das übersteht, was es belegen soll. Wer einen Vorfall innerhalb der gesetzlichen Fristen melden muss, braucht die Daten von vor dem Vorfall, nicht die von danach.
Eine Probe mit Datum. Der zurückgespielte Sicherungsstand, der Testlauf des Wiederanlaufs, die entzogene Berechtigung, die nachweislich wirkte. Ein Termin mit Ergebnis ist der Nachweis, den ein Konzept nicht liefert.
Wer das ohnehin baut, hat einen Nebeneffekt: Dieselben drei Dinge sind das, was ein Kunde in einer Lieferantenprüfung sehen will. Die Anforderung kommt heute über NIS2, sie kam vorher schon über Ausschreibungen.
Wie aus den Terminen dahinter eine Liste mit Vorlauf wird, steht in Ein EOL-Kalender für den ganzen Stack.
Die Reihenfolge, die das Geld wert ist
Die verbreitete Reaktion auf eine solche Liste ist ein Vorhaben, das alles gleichzeitig angeht, und es bleibt im zweiten Monat stecken. Die Reihenfolge, die trägt, sortiert nach zwei Kriterien: was ein Angreifer heute nutzen kann, und was die anderen Maßnahmen erst möglich macht.
Zuerst die Zugänge. Geteilte Konten auflösen, Zugangsdaten aus dem Repository holen, Mehrfaktor überall dort, wo eine Anmeldung ins Innere führt. Das ist Tage, nicht Wochen, und es schließt den Weg, über den die meisten Vorfälle tatsächlich laufen.
Dann die Sichtbarkeit. Protokolle mit einer Aufbewahrung, die zur Meldefrist passt, und eine erzeugte Liste der Abhängigkeiten. Ohne diese beiden ist jede weitere Maßnahme unbelegbar.
Dann die Wiederherstellung, einmal geprobt, mit Datum und gemessener Dauer.
Und erst dann die Fassungen. Der Sprung auf eine gewartete Sprach- und Frameworkfassung ist der größte Posten und der einzige, der Monate braucht. Er steht am Ende, weil die drei Schritte davor in der Zwischenzeit schützen.
Was das für das Gespräch im Haus ändert
Der eigentliche Unterschied zu den Jahren davor liegt nicht in der Technik, sondern darin, wer zuhört.
Ein Upgrade war bisher ein Vorschlag aus der Entwicklung und konkurrierte mit Funktionen. Eine gesetzliche Pflicht mit Bußgeldrahmen und persönlicher Verantwortung der Leitung konkurriert nicht, sie wird eingeplant. Für alle, die seit Jahren auf dieselbe Liste zeigen, ist das die erste Gelegenheit, sie abgearbeitet zu bekommen.
Das ist kein Grund, die Liste länger zu machen, als sie ist. Wer NIS2 nutzt, um ein Vorhaben durchzubekommen, das damit nichts zu tun hat, verbrennt genau das Vertrauen, das die Pflicht gerade erzeugt hat. Was auf die Liste gehört, steht im Gesetz, und der Rest gehört in die normale Planung.
Wie eine solche Bestandsaufnahme technisch abläuft und was danach zuerst passiert, steht auf der Seite zur Modernisierung. Die Befunde selbst sind Handarbeit und beginnen mit den Zugängen, nicht mit den Fassungen.
Dieser Artikel setzt eine Reihe über Systeme fort, die es schon gibt. Der Rückblick über die ersten drei Monate ordnet ihre Artikel nach Anlass.
