Die meisten Organisationen patchen ihre Systeme. Die entscheidende Frage unter NIS2 ist eine andere: Können Sie es beweisen? Nach einem Vorfall — oder im Audit — zählt nicht das Bauchgefühl, dass „wir uns schon kümmern", sondern der lückenlose Nachweis, wann Sie von einer Schwachstelle erfuhren, wie Sie sie bewertet und wann Sie sie geschlossen haben.
Genau hier scheitern viele: Sie handeln, aber sie dokumentieren nicht so, dass es einer Prüfung standhält. Und aus Sicht der Regulierung gilt eine Maßnahme, die sich nicht belegen lässt, im Zweifel als nicht erfolgt.
Warum Schwachstellenmanagement zur Leitungsaufgabe wurde
Die NIS2-Richtlinie verschiebt die Verantwortung ausdrücklich nach oben. Die Leitungsorgane wesentlicher und wichtiger Einrichtungen müssen die Risikomanagementmaßnahmen billigen, ihre Umsetzung überwachen und können für Versäumnisse persönlich haftbar gemacht werden (Artikel 20). Zu den geforderten Maßnahmen zählt ausdrücklich die Behandlung von Schwachstellen (Artikel 21).
Damit ist Patch- und Schwachstellenmanagement keine reine Betriebsaufgabe der IT mehr, sondern Teil der von der Leitung zu verantwortenden Cyberhygiene. Was das für Geschäftsführung und Vorstand konkret bedeutet, haben wir im Detail beschrieben: NIS2-Pflichten für die Geschäftsführung.
Der Perspektivwechsel. NIS2 fragt nicht: „Habt ihr ein Tool?" Es fragt: „Könnt ihr belegen, dass ein wirksamer Prozess existiert, gelebt wird und im Ernstfall trägt?" Der Nachweis ist die eigentliche Pflicht.
Was „Nachweis" konkret bedeutet
Der Nachweis ist nicht der Patch selbst, sondern die belegbare Geschichte drumherum. Ein Auditor oder das nationale CSIRT will nach einem Vorfall eine lückenlose Kette sehen:
Inventar. Welche Systeme und Softwarekomponenten betreiben Sie — und welche sind aus dem Internet erreichbar? Ohne aktuelles Asset-Register ist jede Betroffenheitsaussage Spekulation.
Eingang. Wann ist die Schwachstellenmeldung bei Ihnen eingegangen? Der Zeitstempel des Intakes ist der Startpunkt Ihrer Reaktionszeit.
Bewertung mit Begründung. Betrifft die Lücke Sie — und wenn nicht, warum nicht? Ein dokumentiertes „not_affected" ist genauso ein Nachweis wie ein durchgeführter Patch.
Frist und Entscheidung. Welche Frist galt, wer hat die Behandlung (oder das bewusste Nicht-Handeln) freigegeben? Risikoakzeptanz ist zulässig — aber nur dokumentiert.
Abschluss. Wann wurde die Lücke geschlossen, und woran ist das belegbar? Erst der Abschluss-Nachweis schließt die Kette.
Der Unterschied zwischen „wir patchen" und „wir können es belegen"
In der Praxis klafft genau hier die Lücke. Teams spielen Updates ein, schließen Tickets, arbeiten Rückstände ab — aber die Spur ist über Ticketsysteme, E-Mails, Wartungsprotokolle und Köpfe verteilt. Fragt nach einem Vorfall jemand: „Wann wusstet ihr von CVE-XY und warum habt ihr erst drei Wochen später gehandelt?", lässt sich die Antwort nicht mehr sauber rekonstruieren.
Governance-Realität. Ein nicht dokumentierter, aber durchgeführter Patch schützt technisch — aber im Audit und in der Haftungsfrage steht er einer nicht durchgeführten Maßnahme gleich. Was Sie nicht belegen können, hat aus Prüfsicht nicht stattgefunden.
Ein Audit-Szenario: die unbequemen Fragen
Wie sich die Nachweispflicht anfühlt, wird konkret, sobald ein Prüfer im Raum sitzt. Die Fragen sind selten technisch — sie zielen auf den Prozess und die Belegbarkeit:
„Zeigen Sie mir, wie eine bestimmte Herstellermeldung vom vergangenen Quartal bei Ihnen behandelt wurde." — „Woher wussten Sie, dass Sie betroffen sind, und wann?" — „Wer hat entschieden, dass dieser Patch bis zum Wartungsfenster warten durfte?" — „Welche Frist galt, und wurde sie eingehalten?" — „Wenn Sie bewusst nicht gepatcht haben: Wo ist die dokumentierte Risikoakzeptanz?"
Wer diese Fragen aus einem durchsuchbaren Verlauf in Minuten beantwortet, besteht das Audit souverän. Wer erst E-Mails, Tickets und Wartungsprotokolle zusammensuchen muss, wirkt selbst dann unglaubwürdig, wenn technisch alles richtig gelaufen ist. Nicht die Handlung wird geprüft, sondern die Nachvollziehbarkeit der Handlung.
Typische Nachweislücken
Kein Eingangszeitstempel. Ohne den Moment, in dem eine Meldung bei Ihnen ankam, lässt sich keine Reaktionszeit belegen — und damit auch nicht, dass Sie angemessen schnell waren.
Undokumentiertes „betrifft uns nicht". Die Entscheidung, nicht zu handeln, ist oft die richtige — aber ohne dokumentierte Begründung ist sie im Audit nicht von Nachlässigkeit zu unterscheiden.
Nachträglich änderbare Protokolle. Ein Verlauf, der sich im Nachhinein bearbeiten lässt, ist kein Nachweis. Revisionssicherheit heißt: unveränderlich und zeitgestempelt.
Der Grund für diese Lücke ist selten Nachlässigkeit, sondern Fragmentierung. Die Information, wann eine Meldung eintraf, steht im Postfach eines Mitarbeiters; die Bewertung in einem Chat; der Patch im Ticketsystem; die Freigabe in einem Meeting-Protokoll. Jedes Fragment existiert, aber keines ist mit den anderen verbunden, und keines ist gegen nachträgliche Änderung geschützt. Im Tagesgeschäft fällt das nicht auf — erst wenn jemand die vollständige Kette für eine einzelne CVE sehen will, zeigt sich, dass sie nie an einem Ort zusammenlief. Ein belastbarer Nachweis entsteht nicht dadurch, dass man am Ende alles zusammensucht, sondern dadurch, dass die Spur von Anfang an unveränderlich mitläuft.
Meldepflicht trifft Schwachstellenmanagement
NIS2 verlangt im Ernstfall schnelle Meldungen an das zuständige CSIRT — eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden. Diese Fristen setzen voraus, dass Sie sofort rekonstruieren können, was Sie wann wussten und wie Sie reagiert haben. Ohne einen durchsuchbaren, zeitgestempelten Verlauf wird aus der Meldung eine hektische Sucherei unter Zeitdruck. Die Details der Fristen haben wir hier aufgeschlüsselt: NIS2-Meldepflichten und Fristen.
Mit anderen Worten: Ein sauberer Schwachstellen-Nachweis ist nicht nur Audit-Vorsorge, sondern die Voraussetzung dafür, die gesetzlichen Meldefristen überhaupt einhalten zu können.
Wer betroffen ist — und warum das breiter greift
Ein verbreiteter Irrtum lautet: „NIS2 betrifft nur große Konzerne und kritische Infrastrukturen." Tatsächlich erfasst die Richtlinie wesentliche und wichtige Einrichtungen quer durch viele Sektoren — von Energie, Gesundheit und Transport über digitale Dienste bis zu Abfallwirtschaft, Lebensmittelproduktion und verarbeitendem Gewerbe. Die Größenschwelle setzt bei vielen bereits im gehobenen Mittelstand an.
Entscheidend ist zudem der Effekt entlang der Lieferkette: Auch Organisationen, die selbst knapp unter die Schwelle fallen, werden von ihren NIS2-pflichtigen Kunden vertraglich in die Pflicht genommen. Der Nachweis eines funktionierenden Schwachstellenmanagements wird so zum Wettbewerbsfaktor — wer ihn nicht erbringen kann, verliert Aufträge, unabhängig davon, ob er formal unter die Richtlinie fällt. Die Frage „Sind wir betroffen?" ist damit zweitrangig gegenüber „Können wir belegen, dass wir unsere Systeme im Griff haben?".
So bauen Sie den Nachweis auf
Der Schlüssel ist ein revisionssicherer Audit-Trail, der automatisch mitläuft — statt am Ende mühsam zusammengesucht zu werden. Jede eingehende Meldung erhält einen Zeitstempel, die Betroffenheit wird — idealerweise versionsgenau über CSAF und den VEX-product_status — festgehalten, die Priorisierung erfolgt nachvollziehbar über CVSS, EPSS und KEV, Fristen und Freigaben werden protokolliert, und der Abschluss wird belegt. Wichtig ist, dass diese Einträge unveränderlich sind — ein nachträglich editierbares Protokoll ist kein Nachweis.
Genau diese lückenlose Dokumentation ist der Kern eines Security Advisory Registers: Es hält Eingang, Bewertung, Fristen und Abschluss jeder Meldung prüfsicher fest und liefert damit die Grundlage, die Sie für Audit und Meldepflicht brauchen. Wie der Gesamtprozess aussieht, beschreibt der Leitfaden zum Umgang mit Security Advisories.
Der Nachweis ist auch ein Führungsinstrument
Es wäre kurzsichtig, den Nachweis nur als Audit-Last zu sehen. Dieselben Daten, die einen Prüfer überzeugen, liefern der Leitung eine Kennzahl, die auf jede Risikoagenda gehört: die durchschnittliche Zeit zwischen Bekanntwerden und Schließen einer Schwachstelle an exponierten Systemen. Diese Zahl ist die operative Übersetzung von „Wie schnell reagieren wir?" — und sie lässt sich nur aus einem sauberen Verlauf gewinnen.
Wer diese Kennzahl regelmäßig im Führungsbericht führt, verwandelt Cyberrisiko von einem diffusen Bauchgefühl in eine steuerbare Größe neben den anderen Unternehmensrisiken. Verbessert sich die Reaktionszeit, ist das ein belegbarer Fortschritt; verschlechtert sie sich, ist es ein Frühwarnsignal, lange bevor ein Vorfall es sichtbar macht. So wird der Nachweis vom Kostenfaktor zum Steuerungsinstrument — interessant für die Leitung, nicht nur für die Compliance-Abteilung. Welche Kennzahlen im Führungsbericht wirklich tragen, vertiefen wir in Security-KPIs, die nicht lügen.
„Unter NIS2 ist die wichtigste Frage nicht, ob Sie gehandelt haben — sondern ob Sie es beweisen können."
Häufige Fragen
Reicht unser Ticketsystem als Nachweis?
Nur bedingt. Tickets belegen einzelne Handlungen, aber selten die vollständige Kette von Eingang über Bewertung und Frist bis zum Abschluss — und sie sind meist nachträglich änderbar. Für einen belastbaren Nachweis braucht es einen durchgehenden, unveränderlichen Verlauf.
Müssen wir jede Schwachstelle patchen?
Nein. NIS2 verlangt einen risikobasierten Umgang, keine Vollständigkeit um jeden Preis. Sie dürfen Risiken bewusst akzeptieren — aber die Entscheidung und ihre Begründung müssen dokumentiert und von der zuständigen Stelle freigegeben sein.
Wer haftet, wenn der Nachweis fehlt?
NIS2 nimmt die Leitungsorgane in die Pflicht: Sie müssen die Maßnahmen billigen und ihre Umsetzung überwachen und können persönlich haftbar gemacht werden. Ein fehlender Nachweis ist damit primär ein Governance- und Haftungsproblem, kein reines IT-Thema.
Gilt das nur für große Unternehmen?
NIS2 erfasst wesentliche und wichtige Einrichtungen quer durch viele Sektoren, auch im Mittelstand. Ob Sie betroffen sind, hängt von Sektor und Größe ab — die Nachweispflicht selbst unterscheidet sich davon unabhängig kaum in ihrer Logik.
Fazit: Der Nachweis ist die Pflicht
NIS2 macht Schwachstellenmanagement zur Leitungsaufgabe — und der Maßstab ist nicht die Aktivität, sondern die Belegbarkeit. Wer patcht, aber nicht dokumentiert, erfüllt die technische, nicht die regulatorische Seite. Im Audit und nach einem Vorfall entscheidet der lückenlose, unveränderliche Verlauf.
Der Aufwand dafür entsteht nicht beim Nachweis selbst, sondern durch das nachträgliche Zusammensuchen. Ein Prozess, der die Spur automatisch mitschreibt, dreht das um: Der Nachweis fällt als Nebenprodukt der täglichen Arbeit an.
Was Sie nicht belegen können, zählt im Ernstfall nicht — egal, wie gut Sie es gemeint haben.