Patch-Management-Prozess NIS-2-konform: SLA, Rollen, Nachweise

Art. 21 Abs. 2 lit. e NIS-2 verlangt von wesentlichen und wichtigen Einrichtungen einen Prozess zum Schwachstellen- und Patch-Management als Teil der Cybersicherheitsmaßnahmen. Die Richtlinie ist am 17. Oktober 2024 in den Mitgliedstaaten anwendbar geworden, und das deutsche NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz konkretisiert die Pflicht für rund 29.500 betroffene Unternehmen. Patch-Management ist damit nicht mehr eine technische IT-Disziplin, sondern eine dokumentationspflichtige Governance-Aufgabe, deren Wirksamkeit das BSI im Audit prüft und deren Versäumnis zu Bußgeldern bis 10 Mio. Euro oder 2 Prozent des weltweiten Konzernumsatzes führt.

Dieser Leitfaden zeigt, wie Sie einen Patch-Management-Prozess aufbauen, der NIS-2 und ISO/IEC 27001:2022 Anhang A 8.8 gleichzeitig erfüllt. Sie erhalten konkrete SLA-Fenster, eine Rollenmatrix vom Informationssicherheitsbeauftragten bis zum Asset-Owner, einen Beispiel-Eskalationspfad für kritische Schwachstellen mit CVSS-Score von 9,0 und höher und eine Nachweisstruktur, die im BSI-Audit, im ISO-Surveillance-Audit und in der Geschäftsleitungs-Berichtslinie gleichermaßen tragfähig ist. Der Beitrag schließt mit einem 30-60-90-Tage-Plan, mit dem ein bestehender Patch-Prozess auf NIS-2 gehoben wird. Gleichzeitig zeigen wir, an welchen Stellen ein Workspace mit Versionierung und Audit-Modus die manuelle Pflege ablöst und wie sich die Berichtslinie zur Geschäftsleitung als wiederholbarer Quartalsbericht realisieren lässt.

Art. 21 NIS-2 listet zehn Mindestmaßnahmen für das Risikomanagement der Cybersicherheit. Lit. e nennt ausdrücklich Maßnahmen zum Schwachstellenmanagement und zur Offenlegung. Lit. f verlangt Maßnahmen zur Bewertung der Wirksamkeit. Lit. h fordert grundlegende Cyberhygiene und Schulungen. Patch-Management berührt mindestens drei dieser Punkte gleichzeitig, weil ein wirksamer Prozess sowohl die Erkennung als auch die Bewertung und Behebung von Schwachstellen umfasst und dabei die Geschäftsleitung in die Aufsichtspflicht nimmt. Die Geschäftsleitungshaftung ist in Art. 20 NIS-2 ausdrücklich verankert und betrifft Vorstand und Geschäftsführung persönlich.

Das BSI hat in seinen sektorspezifischen Konkretisierungen klar formuliert, dass ein dokumentierter Prozess, ein Asset-Inventar und definierte SLA-Fenster Mindestbestandteile sind. Eine Excel-Liste mit Patch-Status und ein Ticketsystem ohne Rollendokumentation reichen nicht. Erforderlich sind eine schriftliche Patch-Policy, eine Risikoklassifizierung pro Asset, ein dokumentiertes Bewertungsverfahren für Schwachstellen nach CVSS und eine Berichtslinie an den Informationssicherheitsbeauftragten und die Geschäftsleitung. Das Bußgeldrahmenwerk unterscheidet zwischen wesentlichen Einrichtungen mit bis zu 10 Mio. Euro oder 2 Prozent Konzernumsatz und wichtigen Einrichtungen mit bis zu 7 Mio. Euro oder 1,4 Prozent Konzernumsatz. Ergänzend gelten Anordnungs- und Untersagungsbefugnisse des BSI, die im Wiederholungsfall auch das operative Geschäft empfindlich treffen können, wenn Patches systematisch ausbleiben. Zur Klarstellung: NIS-2 umfasst 18 Sektoren, von Energie und Verkehr über Finanzmarkt und Gesundheit bis zu digitalen Infrastrukturen, IKT-Dienstleistungen und Lebensmittelproduktion. Die Schwellenwerte mittlere Unternehmen ab 50 Beschäftigten und 10 Mio. Euro Umsatz greifen unabhängig von der bisherigen KRITIS-Einstufung, sodass viele Unternehmen erstmals in den regulierten Bereich fallen, ohne historisch eine BSI-Beziehung zu pflegen, was den Aufbau einer dokumentierten Patch-Praxis besonders dringlich macht.

ISO/IEC 27001:2022 wurde am 25. Oktober 2022 veröffentlicht und ersetzt die Edition von 2013 vollständig seit 31. Oktober 2025. Anhang A 8.8 trägt den Titel Management technischer Schwachstellen und verlangt einen dokumentierten Prozess für die rechtzeitige Identifizierung, Bewertung und Behandlung technischer Schwachstellen. Der Control-Eigentümer ist typischerweise der ISB oder eine IT-Sicherheitsfunktion mit Berichtslinie zum ISB. Die Norm verlangt nicht nur die Existenz eines Prozesses, sondern dessen messbare Wirksamkeit, also dokumentierte SLAs, Erfolgsmessung und Korrekturmaßnahmen bei Abweichungen.

Die Brücke zwischen NIS-2 und ISO 27001 ist hier besonders eng. Ein Unternehmen, das ISO 27001 mit dokumentierter Umsetzung von A.8.8 betreibt, erfüllt den operativen Kern der NIS-2 Anforderungen aus Art. 21 Abs. 2 lit. e automatisch. Was fehlt, ist die organisatorische Verankerung: die Bestellung des ISB mit Berichtsweg zur Geschäftsleitung, die Verzahnung mit dem NIS-2 24-Stunden-Meldepfad und die Geschäftsleitungs-Berichtslinie. CIVAC mappt die 93 Controls aus ISO/IEC 27001:2022 Anhang A automatisch auf die NIS-2 Anforderungen, sodass A.8.8 in der Plattform doppelt wirkt: einmal für das ISO-Surveillance-Audit, einmal für das BSI. Bestellurkunde, unterschrieben, abgelegt, belegbar. Der ISB sieht in einer Ansicht den Schwachstellen-Status, die offenen Maßnahmen und die SLA-Treffer, und das Management Review erhält denselben Bericht ohne Aufbereitungsaufwand. Ein wesentlicher Vorteil dieser doppelten Wirkung: Die Bewertung der Wirksamkeit nach Art. 21 Abs. 2 lit. f NIS-2 ist ohne zusätzlichen Auditaufwand möglich, weil die Trefferquote pro SLA-Stufe als laufende Kennzahl im Workspace mitgeführt wird und im Surveillance-Audit unmittelbar abrufbar ist. Wer eine Patch-Policy heute neu aufsetzt, profitiert davon, beide Regelwerke parallel zu adressieren, weil eine spätere Trennung erfahrungsgemäß Doppelarbeit verursacht und Inkonsistenzen erzeugt, die im Audit als Findings festgehalten werden.

Ein belastbarer Patch-SLA orientiert sich am CVSS-Score (Common Vulnerability Scoring System) und an der Kritikalität des Assets. Bewährt hat sich ein vierstufiges Modell. Stufe 1: Bewertung jeder neuen Schwachstelle innerhalb von 24 Stunden ab Bekanntwerden durch das CSIRT oder einen relevanten Hersteller-Bulletin. Stufe 2: Notfall-Patch innerhalb von 72 Stunden bei CVSS ab 9,0 (kritisch) und aktiver Ausnutzung im freien Feld (zero-day oder bekannte aktive Exploitation). Stufe 3: Patch innerhalb von 7 Tagen für CVSS 7,0 bis 8,9 (hoch) auf kritischen Assets. Stufe 4: Patch innerhalb von 30 Tagen für hoch und 90 Tagen für mittel auf nicht-kritischen Assets.

Diese Fenster sind keine gesetzliche Vorgabe, sondern Branchenstandard, der auf den BSI Lagebild-Empfehlungen und auf den Empfehlungen des CISA Known Exploited Vulnerabilities Catalog basiert. Der entscheidende Punkt ist die dokumentierte Definition im Unternehmen, die zwischen ISB, Asset-Owner und Geschäftsleitung abgestimmt ist. Frist läuft ab Kenntnis. Wer keinen dokumentierten SLA hat, wird im Audit gefragt, wann die letzte Apache-Log4j-Schwachstelle vom 9. Dezember 2021 vollständig geschlossen war und welcher Berichtsweg dabei greift. Eine plausible Antwort gibt es nur mit dokumentierten Fenstern, einem Patch-Backlog mit Eskalations-Workflow und einer Reporting-Linie zur Geschäftsleitung. Die NIS-2 Umsetzung in Deutschland macht diese Dokumentationspflicht für rund 29.500 Unternehmen verbindlich. In der Praxis empfiehlt sich, das SLA-Modell pro Sektor und pro Asset-Klasse zu differenzieren: Ein OT-System in einer Produktionsanlage hat andere Wartungsfenster als ein klassischer Office-Server, und ein Internet-exponierter Webserver eine andere Behandlungsdringlichkeit als ein internes Backoffice-System. Die Differenzierung wird in der Patch-Policy festgeschrieben, von der Geschäftsleitung freigegeben und im Workspace versioniert. So entsteht eine belastbare Grundlage, die im Audit nicht als willkürlich, sondern als risikobasiert begründet bewertet wird.

Ein NIS-2-konformer Patch-Prozess verteilt Verantwortung auf drei klar getrennte Rollen. Der Informationssicherheitsbeauftragte (ISB) verantwortet den Prozess als solchen: die Patch-Policy, die SLA-Definition, die Eskalationswege und die Berichtslinie an die Geschäftsleitung. Der Asset-Owner verantwortet die Umsetzung pro System: er entscheidet über Wartungsfenster, koordiniert mit dem Betrieb, dokumentiert Tests und Rollback-Verfahren. Die Geschäftsleitung verantwortet die Aufsichtspflicht nach Art. 20 NIS-2 und § 130 OWiG: sie genehmigt die Patch-Policy, prüft regelmäßig die Berichte und entscheidet bei Konflikten zwischen IT-Sicherheit und Geschäftsbetrieb.

In der Praxis scheitert die Rollenklarheit häufig an Doppelfunktionen. Der IT-Leiter wird zum ISB ernannt und prüft eigene Bereiche, was die Unabhängigkeit verletzt. Der Asset-Owner ist nominell der Fachbereich, aber operativ ein Dienstleister, was die Eskalation verzögert. Die Geschäftsleitung erhält Patch-Berichte, deren Aussagekraft sie ohne Kontext nicht bewerten kann. CIVAC adressiert diese Lücken durch eine dokumentierte Bestellurkunde für den ISB mit Kündigungsschutz, einen Asset-Owner-Workflow mit Vier-Augen-Prinzip und einen vorgefertigten Geschäftsleitungs-Quartalsbericht, der die wichtigsten KPIs darstellt: SLA-Trefferquote, offene kritische Schwachstellen, durchschnittliche Patch-Latenz und Trend gegenüber Vorquartal. So entsteht ein Berichtswesen, das die Geschäftsleitung tatsächlich nutzen kann, statt eine Excel-Liste, die in der Mailbox versinkt. Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software. Die Rollenmatrix wird durch eine RACI-Tabelle ergänzt, die für jede Patch-Aktivität verantwortlich, ausführend, befragt und informiert ausweist. So lässt sich auch in Konzernstrukturen mit Tochterunternehmen, ausgelagerten IT-Dienstleistern und konzernweit geteilten Plattform-Services eindeutig nachweisen, wer welche Entscheidung getroffen hat, wann sie getroffen wurde und auf welcher Datenbasis. Dieselbe Tabelle dient als Onboarding-Dokument für neue Asset-Owner und als Audit-Beleg für die nachweisbare Trennung von Verantwortung und Ausführung.

Vor dem ersten Patch steht das Asset-Inventar. Art. 21 NIS-2 verlangt eine Risikoanalyse, die ohne vollständige Kenntnis der eingesetzten Systeme nicht möglich ist. ISO/IEC 27001:2022 A.5.9 (Inventar von Informationen und anderen Vermögenswerten) ist die direkte Norm-Entsprechung. Ein praxistaugliches Inventar listet je Asset mindestens die folgenden Attribute: eindeutige ID, Asset-Klasse (Server, Endgerät, Netzwerkkomponente, OT-Komponente, SaaS), Asset-Owner, Kritikalität (gering, mittel, hoch, kritisch), Standort, Betriebssystem mit Version, eingesetzte Softwarekomponenten, externe Erreichbarkeit, Patch-Status und letzter Audit-Stichtag.

Klassische CMDBs sind häufig unvollständig, weil sie OT-Komponenten, Schatten-IT, SaaS-Verträge und mobile Endgeräte nur lückenhaft abbilden. Für NIS-2 reicht das nicht. Eine kombinierte Erfassung aus aktiven Scans, passiver Netzwerkbeobachtung und vertraglicher Erfassung der SaaS-Dienste ist Mindestanspruch. CIVAC integriert das Asset-Inventar in den Workspace und koppelt es an die Schwachstellen-Feeds, sodass jede neue Schwachstelle automatisch auf betroffene Assets zugeordnet wird. Damit reduziert sich der manuelle Aufwand der Schwachstellenbewertung deutlich, und die Geschäftsleitung kann auf Knopfdruck die Frage beantworten, wie viele Assets mit einer CVSS-9-Schwachstelle aktuell unbehandelt sind. Dieser Bericht ist im BSI-Audit die erste Frage. Wer keine Antwort hat, hat keinen Prozess, und das BSI dokumentiert eine wesentliche Abweichung mit den entsprechenden Folgen für die Geschäftsleitungs-Haftung. Aus diesem Grund empfehlen wir, vor dem Aufbau eines vollwertigen Patch-Prozesses zunächst das Asset-Inventar in drei Iterationen zu konsolidieren: einmal nach Buchhaltung und Beschaffung, einmal nach aktiven Netzwerk-Scans, einmal nach Identity-Provider und SaaS-Spend. Die Schnittmenge ergibt einen belastbaren Ausgangspunkt, der im Quartalsrhythmus aktualisiert wird. Auf dieser Grundlage liefert der Workspace eine kumulierte Sicht auf Asset-Bestand, Kritikalitätsverteilung und Patch-Backlog, die als Lagebild für die Geschäftsleitung dient.

Die reine CVSS-Punktzahl reicht für eine Patch-Priorisierung nicht aus. CVSS bewertet die technische Schwere einer Schwachstelle, nicht die tatsächliche Ausnutzbarkeit in Ihrer Umgebung. Eine CVSS-10-Schwachstelle in einer Komponente, die intern nicht erreichbar ist und keine sensiblen Daten verarbeitet, ist weniger dringend als eine CVSS-7-Schwachstelle in einem öffentlich erreichbaren Webserver. Die NIS-2 Anforderung an eine wirksame Risikobehandlung verlangt deshalb die Kombination aus CVSS, Threat Intelligence (etwa CISA KEV, MITRE ATT&CK-Mapping, herstellerspezifische Bulletins) und Business Impact (Geschäftsprozess-Abhängigkeit, Datenklassifikation, regulatorische Pflichten).

Ein praxistaugliches Bewertungsverfahren nutzt eine dreidimensionale Matrix: Schweregrad (CVSS), Wahrscheinlichkeit (Threat Intelligence) und Schaden (Business Impact). Aus diesen drei Dimensionen ergibt sich eine priorisierte Liste, die in das SLA-Modell aus Stufe 1 bis 4 einfließt. CIVAC bringt eine vorkonfigurierte Bewertungsmatrix mit, die sich an die individuelle Risikobereitschaft anpassen lässt, und integriert öffentliche Feeds wie das NIST National Vulnerability Database und den CISA KEV-Katalog automatisch. Damit ist die Bewertungslogik dokumentiert, nachvollziehbar und im Audit prüfbar. Audit-fest, dokumentiert, § 130 OWiG-fest. Wer die Bewertung ohne dokumentierte Methodik durchführt, riskiert im Audit den Vorwurf der willkürlichen Priorisierung, und im Schadensfall den Vorwurf der unzureichenden Sorgfalt durch die Geschäftsleitung, der bis zu strafrechtlicher Verantwortung reichen kann. Die Bewertungsmethodik wird in der Patch-Policy festgeschrieben, von der Geschäftsleitung genehmigt und mindestens jährlich überprüft. Sie sollte explizit auch dokumentieren, wie mit Schwachstellen umgegangen wird, für die keine CVSS-Bewertung vorliegt, etwa bei sehr neuen Zero-Day-Veröffentlichungen ohne offizielles Scoring, um auch in diesen Sonderfällen einen reproduzierbaren Entscheidungsweg zu sichern. Eine kurze Eskalationsregel mit dokumentierter Genehmigung durch den ISB erfüllt diese Anforderung.

Der technische Kern des Patch-Managements liegt im strukturierten Vorgehen von Test über Rollout zu Rollback. Ein bewährter Ablauf umfasst sechs Schritte. Erstens: Patch-Beschaffung aus vertrauenswürdiger Quelle mit Signaturprüfung. Zweitens: Test in einer Vorproduktionsumgebung mit dokumentierten Testfällen und einem Abnahme-Kriterium pro Asset-Klasse. Drittens: Genehmigung durch den Asset-Owner mit Vier-Augen-Prinzip. Viertens: Rollout in produktive Systeme mit Wartungsfenster, Kommunikation an betroffene Fachbereiche und protokollierter Durchführung. Fünftens: Verifikation, dass der Patch installiert und wirksam ist (Versionsprüfung, Funktionstest). Sechstens: Rollback-Plan, der bei Funktionsstörungen innerhalb der ersten Stunden aktivierbar ist.

Der Rollback-Plan wird häufig unterschätzt, ist aber Audit-relevant. Auditoren fragen nach dokumentierten Fällen, in denen ein Patch zurückgenommen wurde, nach der Dokumentation der Wiederherstellungszeit und nach Lessons Learned. Wer Rollback nicht dokumentiert, signalisiert ein unreifes Prozessverständnis. CIVAC integriert diese sechs Schritte in einen Patch-Workflow mit Zeitstempel pro Schritt, Verantwortlichem pro Schritt und Eskalationsregeln bei Verzögerung. Der ISB sieht im Dashboard, wie viele Patches in welcher Phase stehen und ob SLA-Fenster eingehalten werden. Der Prüfer ruft an, der Nachweis liegt bereit. Notfall-Patches erhalten einen abgekürzten Ablauf mit Sofort-Genehmigung des ISB oder der Geschäftsleitung, dokumentiert im Workspace mit Begründung und Folgemaßnahmen, sodass auch unter Zeitdruck die Nachweiskette geschlossen bleibt. Für Notfall-Patches mit potenziellem Datenschutzbezug verzahnt sich der Workflow zusätzlich mit dem Art. 33 DSGVO-Meldepfad, weil eine ausgenutzte Schwachstelle zu einer meldepflichtigen Datenpanne führen kann. Frist läuft ab Kenntnis. Beide Pfade laufen im selben Workspace und teilen die Beweisaufnahme, sodass das CSIRT und der Datenschutzbeauftragte ohne Medienbruch zusammenarbeiten. Diese Verzahnung ist im klassischen Setup mit getrennten Systemen eine der größten Schwachstellen, weil Eskalationen verzögert ankommen und Fristen kollidieren.

Ein NIS-2-konformer Patch-Prozess erzeugt fünf Nachweistypen, die im Audit verlangt werden. Erstens: die schriftliche Patch-Policy mit Datum, Version, Genehmigung der Geschäftsleitung und definierten SLA-Fenstern. Zweitens: das Asset-Inventar mit aktuellem Stand, Kritikalität und Asset-Owner. Drittens: die Schwachstellen-Bewertungen der letzten 12 Monate mit dokumentierter Methodik (CVSS plus Threat Intelligence plus Business Impact). Viertens: die Patch-Historie mit Zeitstempel, SLA-Treffer pro Schwachstelle und Begründung bei Abweichungen. Fünftens: die Berichtslinie zur Geschäftsleitung mit quartalsweisem Review-Protokoll und dokumentierten Beschlüssen.

Diese fünf Nachweistypen lassen sich in fragmentierten Systemen kaum konsistent erzeugen. Wer die Policy in SharePoint, das Inventar in einer CMDB, die Bewertungen in einem Schwachstellen-Scanner und die Patches im Ticketsystem führt, erzeugt im Audit eine tagelange Sucharbeit, die der Auditor mit Abweichungs-Findings honoriert. CIVAC bündelt alle fünf Nachweistypen in einem Workspace, mit Versionierung pro Dokument und einem Audit-Modus, der auf Knopfdruck einen Nachweisbericht für einen Stichtag erzeugt. Bestellurkunde, unterschrieben, abgelegt, belegbar. So wird aus einer technischen IT-Aufgabe ein dokumentierter Governance-Prozess, der dem BSI, dem ISO-Auditor und der Geschäftsleitung gleichermaßen standhält und der die Aufsichtspflicht der Geschäftsleitung nach § 130 OWiG sauber belegt. Ergänzend lassen sich Audit-Berichte je Stichtag erzeugen, die zusätzlich zu den Pflichtnachweisen auch ein Wirksamkeits-Reporting mit Trend pro Quartal mitführen, was das Management Review deutlich aussagekräftiger macht als eine reine Aktivitätsliste. Bestellurkunde, unterschrieben, abgelegt, belegbar. Genau diese Vier-Wort-Beweiskette ist es, die im BSI-Audit den Unterschied zwischen einer leichten Anmerkung und einem belastbaren Findings-Bericht ausmacht.

Ein bestehender Patch-Prozess lässt sich in 90 Tagen auf NIS-2-Niveau heben. Tage 1 bis 30: Inventar erstellen, Asset-Owner benennen, ISB bestellen oder bestätigen, Patch-Policy als Entwurf mit definierten SLA-Fenstern, Geschäftsleitungs-Briefing. Tage 31 bis 60: Bewertungsmethodik dokumentieren, Schwachstellen-Feed integrieren, Workflow für Test und Rollout produktiv setzen, erste internen Übungen mit einer kritischen Schwachstelle. Tage 61 bis 90: Geschäftsleitungs-Quartalsbericht erstellen, Audit-Bereitschaftstest, dokumentierte Korrekturmaßnahmen aus der ersten Übung, Verzahnung mit dem NIS-2 24/72-Meldepfad. Am Ende steht ein Prozess, der dem BSI und dem ISO-Auditor standhält und der die Geschäftsleitungs-Haftung nach Art. 20 NIS-2 wirksam adressiert.

CIVAC begleitet diesen Weg als Compliance-Plattform und Officer-as-a-Service. Lizenzieren Sie den Workspace für Ihre internen Beauftragten oder lassen Sie unsere Beauftragten bestellen. Aus dem Lesen einen Auftrag machen. Schreiben Sie uns an info@civac.de oder buchen Sie ein Erstgespräch über das Kontaktformular auf civac.de. In 45 Minuten erhalten Sie eine ehrliche Reifegradeinschätzung Ihres aktuellen Patch-Prozesses, eine priorisierte Maßnahmenliste und ein klares Angebot zur Umsetzung. Andere führen Compliance wie einen Aktenschrank. Wir führen sie wie Software. Wer den Schritt heute geht, ist beim ersten BSI-Audit nach NIS-2 nicht der erste Fall, sondern der dokumentierte Beleg, dass Aufsichtspflicht und IT-Sicherheit in derselben Architektur funktionieren. Der Prüfer ruft an, der Nachweis liegt bereit. Sie können diesen Satz wörtlich nehmen, weil er das Endergebnis eines strukturierten 90-Tage-Programms beschreibt, das in vielen mittelständischen Strukturen ohne zusätzliche Werkzeug-Investitionen jenseits des Workspace umsetzbar ist und die Geschäftsleitungs-Haftung nachweisbar reduziert.