NIS2 Patch- und Schwachstellenmanagement: Anforderungen und Praxis

Ein Sicherheitspatch, der drei Monate ungetestet auf einem Produktivsystem liegt, ist nach NIS2 kein Kavaliersdelikt, sondern ein dokumentationspflichtiger Ausnahmefall. Die EU-Durchführungsverordnung (CIR) 2024/2690 verlangt in Abschnitt 6.6, dass Sicherheitspatches „innerhalb einer angemessenen Frist“ eingespielt werden – und dass jede Verzögerung begründet und dokumentiert wird. Für wesentliche und wichtige Einrichtungen unter NIS2 verschiebt das den Fokus: weg vom bloßen Patchen, hin zu einem prüfbaren Prozess aus Priorisierung, Test und Nachweis.

Dieser Artikel ordnet Patch- und Schwachstellenmanagement rechtlich ein, zeigt den geforderten Patch-Prozess, erklärt CVE-Monitoring über die neue EU-Schwachstellendatenbank, liefert ein praxiserprobtes Priorisierungsmodell nach Kritikalität und geht auf die Besonderheiten von OT-Systemen ein – inklusive der BSI-Empfehlungen, die diesen Prozess in der Praxis konkretisieren. Angesprochen sind damit sowohl IT-Verantwortliche, die den Prozess operativ umsetzen, als auch Compliance- und Geschäftsleitungsebene, die Ausnahmen dokumentieren und im Audit vertreten müssen.

Rechtsgrundlage: Wo Patch- und Schwachstellenmanagement in NIS2 verankert ist

Patch- und Schwachstellenmanagement ist eine von zehn in Art. 21(2) NIS2 vorgeschriebenen Risikomanagementmaßnahmen. Sie gilt für jede wesentliche und wichtige Einrichtung gleichermaßen – unabhängig von Sektor oder Größe. Die vollständige Übersicht aller zehn Maßnahmen finden Sie in unserem Leitfaden zu den NIS2-Anforderungen.

Rechtlich verankert ist die Pflicht in Art. 21(2)(e) NIS2: „Sicherheit beim Erwerb, bei der Entwicklung und bei der Wartung von Netz- und Informationssystemen, einschließlich der Behandlung und Offenlegung von Schwachstellen“ – als eigener Pflichtpunkt der zehn Basismaßnahmen [1]. In der Praxis wird Patch-Management häufig unter dem Sammelbegriff „Cyberhygiene“ geführt. Rechtlich präzise ist das nur bedingt richtig: Die „grundlegenden Verfahren im Bereich der Cyberhygiene und Schulungen zur Cybersicherheit“ bilden einen eigenen, separaten Pflichtpunkt (Art. 21(2)(g)) [1]. Beide Pflichten überschneiden sich inhaltlich stark, doch Prüfer und Auditoren erwarten in der Dokumentation die korrekte Zuordnung zu Art. 21(2)(e). Für kleinere Unternehmen ohne eigene Compliance-Abteilung reicht es in der Praxis, diese Unterscheidung einmal im Maßnahmenregister sauber zu vermerken – entscheidend ist, dass später im Audit klar ist, welche Nachweise zu welcher Pflicht gehören.

Einrichtungstyp	Gilt die Pflicht aus Art. 21(2)(e)?
Wesentliche Einrichtung	Ja – volle Anforderung, proaktive Aufsicht
Wichtige Einrichtung	Ja – volle Anforderung, reaktive Aufsicht bei Verdachtsmomenten

Anders als bei einigen anderen Maßnahmen reduziert die Größe des Unternehmens hier nicht den inhaltlichen Umfang der Pflicht – nur die Aufsichtsintensität unterscheidet sich zwischen den beiden Kategorien.

Der Patch-Prozess nach CIR 2024/2690 Abschnitt 6.6

Die Durchführungsverordnung (CIR) 2024/2690 konkretisiert Art. 21(2)(e) technisch – formal bindend allerdings nur für digitale Infrastruktur- und Dienstanbieter (DNS, Cloud, Rechenzentren, CDN, MSP/MSSP, Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdiensteanbieter). Für alle anderen Sektoren dient Abschnitt 6.6 als anerkannte Auslegungshilfe zu Art. 21(2)(e), nicht als direkt bindende Checkliste. Abschnitt 6.6.1 verlangt, dass Sicherheitspatches innerhalb einer angemessenen Frist angewendet werden, vor dem Einsatz in Produktivsystemen getestet werden und ausschließlich aus vertrauenswürdigen Quellen mit geprüfter Integrität stammen [3]. Die Testpflicht folgt derselben Logik wie die Wirksamkeitsbewertung von Sicherheitsmaßnahmen, die wir in unserem Leitfaden zu NIS2-Sicherheitstests vertiefen.

Abschnitt 6.6.2 erlaubt eine Ausnahme: Ein Patch darf zurückgehalten werden, wenn die cybersicherheitsbezogenen Nachteile der Anwendung die Vorteile überwiegen – die betreffende Einrichtung muss diese Entscheidung jedoch ordnungsgemäß dokumentieren und begründen [3]. Genau dieser Mechanismus ist später der formale Hebel für nicht patchbare OT-Systeme.

Rolle	Verantwortung im Patch-Prozess
IT-Betrieb	Patches identifizieren, testen, einspielen, Integrität prüfen
Informationssicherheitsbeauftragte(r)	Kritikalität bewerten, Priorisierung festlegen, Ausnahmeanträge prüfen
Geschäftsleitung	Ausnahme-Dokumentation gegenzeichnen, Restrisiko akzeptieren

Das BSI konkretisiert diese CIR-Vorgaben in vier praktischen Anforderungen: regelmäßige Installation von Updates und Sicherheits-Patches auf allen relevanten Systemen, priorisierte Behandlung sicherheitskritischer Schwachstellen, Schließung bekannter Schwachstellen vor einer möglichen Ausnutzung durch Angreifer sowie ausschließliche Nutzung sicherer Updatemechanismen [5]. In der Praxis bewährt sich ein fester Rhythmus: ein wöchentliches Triage-Meeting zwischen IT-Betrieb und Informationssicherheitsbeauftragten, in dem neue Schwachstellen gegen die Kritikalitätskriterien aus dem nächsten Abschnitt bewertet und Ausnahmen mit Begründung protokolliert werden – damit die „angemessene Frist“ aus 6.6.1 nicht erst im Nachhinein rekonstruiert werden muss.

CVE-Monitoring: Von CVE bis zur neuen EU-Schwachstellendatenbank

Ohne systematisches Monitoring bekannter Schwachstellen lässt sich weder Abschnitt 6.6 noch Abschnitt 6.10 der CIR erfüllen. Abschnitt 6.10 verlangt, dass Einrichtungen Informationen zu technischen Schwachstellen einholen, die eigene Betroffenheit bewerten, ein Offenlegungsverfahren nach dem nationalen Konzept zur koordinierten Offenlegung betreiben und für Schwachstellen mit erheblicher Auswirkung einen Risikominderungsplan erstellen – oder dokumentieren, warum keine Maßnahme erforderlich ist [4]. Der Prozess muss mit Änderungs-, Patch-, Risiko- und Vorfallmanagement kompatibel sein [4].

Art. 12 NIS2 ergänzt das auf EU-Ebene: Jeder Mitgliedstaat benennt ein CSIRT als Koordinator für die koordinierte Offenlegung von Schwachstellen – als vertrauenswürdiger Vermittler zwischen meldender Person und Hersteller, mit verpflichtendem anonymem Meldekanal [2]. ENISA betreibt dazu die Europäische Schwachstellendatenbank (EUVD), die seit dem 13. Mai 2025 live ist und Schwachstellenbeschreibung, betroffene Produkte samt Schweregrad sowie verfügbare Patches oder Gegenmaßnahmen bündelt [2][8]. Die EUVD ersetzt die etablierten CVE-Feeds von MITRE nicht, sondern ergänzt sie um eine EU-Perspektive – ENISA ist seit Januar 2024 selbst CVE Numbering Authority und ordnet EUVD-Einträge bestehenden CVE-IDs zu [8].

Quelle	Zweck
CVE / NVD	Globaler Referenzstandard für Schwachstellen-IDs
EUVD (ENISA)	EU-Perspektive, CSIRT-koordiniert, seit Mai 2025 live, NIS2-Bezug
BSI-Portal / CERT-Bund	Nationale Frühwarnung, direkter Bezug zur Meldepflicht

Auf nationaler Ebene empfiehlt das BSI den Einsatz des Common Security Advisory Framework (CSAF) samt Technischer Richtlinie TR-03191, um Sicherheitsmeldungen von Lieferanten automatisiert einzuholen, sowie die öffentliche Bereitstellung von Kontaktdaten für externe Sicherheitsforscher über eine security.txt nach RFC 9116 [5]. Praktisch funktioniert CVE-Monitoring nur, wenn es an ein aktuelles Asset-Inventar gekoppelt ist: Ohne eine belastbare Liste eingesetzter Softwareversionen und Geräte läuft selbst der beste Feed ins Leere, weil sich neue Schwachstellenmeldungen keiner konkreten Betroffenheit zuordnen lassen. Diese Kopplung ist auch der Punkt, an dem Abschnitt 6.10 explizit die Kompatibilität mit dem Änderungs- und Risikomanagement verlangt – Schwachstellenmonitoring ist kein isoliertes Werkzeug, sondern Teil desselben Datenbestands wie das übrige Sicherheitsmanagement.

Priorisierung nach Kritikalität: CVSS, EPSS und KEV kombinieren

Keines der gängigen Bewertungssysteme reicht für sich allein aus, um die von Abschnitt 6.6.1 geforderte „angemessene Frist“ sinnvoll zu operationalisieren. CVSS bewertet den theoretischen Schweregrad einer Schwachstelle, unabhängig davon, ob sie tatsächlich ausgenutzt wird. EPSS (Exploit Prediction Scoring System) schätzt dagegen die Wahrscheinlichkeit einer Ausnutzung in den nächsten 30 Tagen als Prozentwert. Der CISA-KEV-Katalog listet demgegenüber ausschließlich Schwachstellen, die nachweislich bereits aktiv ausgenutzt werden – aktuell über 1.100 Einträge [9]. Mehrere Analysen kommen übereinstimmend zu dem Ergebnis, dass nur etwa 2 bis 5 Prozent aller veröffentlichten Schwachstellen jemals tatsächlich aktiv ausgenutzt werden [9] – ein reiner CVSS-Ansatz führt damit zu massiver Überpriorisierung.

In der Praxis hat sich ein kombiniertes, vierstufiges Modell bewährt, das wir hier als Orientierung darstellen – es handelt sich um eine bewährte Praxisheuristik, nicht um eine regulatorische Vorgabe:

Priorität	Kriterium	Zielfrist
P1	Im KEV-Katalog gelistet, oder CVSS ≥9 und EPSS >0,5	24–48 Stunden
P2	CVSS ≥7 und EPSS >0,3, oder CVSS ≥9 und EPSS >0,1	7 Tage
P3	CVSS ≥7 mit niedrigerem EPSS, oder CVSS 4–6,9 mit EPSS >0,1	30 Tage
P4	CVSS <7 und EPSS <0,1	90 Tage

In der Praxis reduziert ein solches Modell eine Rohliste von etwa 200 Funden auf rund 15 bis 20 tatsächlich dringliche Prioritäten [9] – und liefert gleichzeitig die dokumentierte Begründung, die Abschnitt 6.6.1 für die Einhaltung der „angemessenen Frist“ verlangt.

Beispiel: Eine kritische Schwachstelle mit CVSS 9,8 in einer intern genutzten Webanwendung, für die noch kein aktiver Exploit bekannt ist (EPSS 0,08), fällt nach dem Modell in P2 – Behebung innerhalb von sieben Tagen, nicht innerhalb von 48 Stunden. Taucht dieselbe Schwachstelle wenige Tage später im CISA-KEV-Katalog auf, weil aktive Ausnutzung bestätigt wurde, springt sie automatisch auf P1. Diese Dynamik ist der Grund, warum ein einmaliger CVSS-Scan pro Quartal nicht ausreicht – die Einstufung muss laufend aktualisiert werden, sobald sich EPSS- oder KEV-Status ändern.

OT-Patch-Besonderheiten: Wenn Systeme nicht einfach abgeschaltet werden können

In Produktionsumgebungen lässt sich ein Patch selten so einspielen wie auf einem Büro-Laptop. Verfügbarkeitsanforderungen, Herstellerzertifizierungen und die physische Sicherheit angeschlossener Prozesse machen klassisches Patch-Management auf OT-Systemen oft unmöglich oder unverhältnismäßig riskant. Genau für diesen Fall bietet Abschnitt 6.6.2 der CIR den formalen Rahmen: Ein Patch darf zurückgehalten werden, wenn die Nachteile überwiegen – vorausgesetzt, die Entscheidung wird dokumentiert und begründet [3].

Das BSI empfiehlt für OT-Geräte, Sicherheitsscans außerhalb der Produktivumgebung durchzuführen und Netzwerksegmentierung als zentrale kompensierende Maßnahme einzusetzen, wenn ein Patch nicht sofort möglich ist [5]. Die US-Behörde CISA formuliert für Steuerungssysteme drei ergänzende Praxisregeln: risikobasierte Priorisierung unter Einbeziehung von Bedrohungsdaten wie dem KEV-Katalog statt reiner CVSS-Werte, ein verifiziertes Backup unmittelbar vor jeder Patch-Maßnahme, sowie umfangreiche Regressionstests, da Steuerungssysteme andere Verfügbarkeits- und Sicherheitsanforderungen haben als klassische IT [7]. Anders als in der IT, wo monatliche Patch-Zyklen üblich sind, richten sich Wartungsfenster in der Produktion oft nach jährlichen Stillstandsplanungen – ein struktureller Konflikt, den nur die Kombination aus Netzwerksegmentierung (als kompensierende Maßnahme außerhalb des eigentlichen Patch-Zyklus) und dokumentierter Ausnahme nach 6.6.2 rechtssicher auflöst.

Als praktische Prüffragen vor jeder OT-Ausnahmeentscheidung empfehlen sich: Lässt sich das Gerät netzwerktechnisch isolieren? Existiert ein Ablöseszenario oder ein Ersatzsystem? Ist die kompensierende Maßnahme dokumentiert und mit einem Termin für die erneute Bewertung versehen? Diese Fragen gehören in dieselbe Ausnahme-Dokumentation, die Abschnitt 6.6.2 ohnehin verlangt – OT-Patch-Management ist damit kein Sonderfall außerhalb von NIS2, sondern ein dokumentierter Anwendungsfall der bestehenden Ausnahmeregelung. Die zugrundeliegende sichere Entwicklungs- und Wartungslogik von Abschnitt 6 der CIR, zu dem 6.6 gehört, vertiefen wir in unserem Leitfaden zur sicheren Entwicklung nach NIS2.

BSI-Empfehlungen und Nachweisführung für die Prüfung

Das BSI ordnet Schwachstellenmanagement als strukturierten Prozess zur Früherkennung und Behebung von Sicherheitslücken ein und verlangt regelmäßiges Scannen von Systemen, Priorisierung nach Risiko und Einfluss auf Geschäftsprozesse sowie lückenlose Dokumentation aller gefundenen Schwachstellen und umgesetzten Maßnahmen [5]. Ergänzend steht mit dem IT-Grundschutz-Baustein OPS.1.1.3 ein etabliertes Modul bereit, das den Aufbau, die Kontrolle und die fortlaufende Optimierung eines Patch- und Änderungsmanagementprozesses beschreibt [6].

Für die Nachweisführung bei einer Prüfung sollten mindestens folgende Unterlagen vorliegen: Scan-Protokolle mit Zeitstempel, dokumentierte Priorisierungsentscheidungen, Patch-Nachweise inklusive Testprotokoll und Quellen-/Integritätsprüfung, die Ausnahme-Dokumentation nach Abschnitt 6.6.2 sowie das Offenlegungsverfahren nach Abschnitt 6.10. Diese Unterlagen sind kein Selbstzweck: Bei einer Kontrolle nach Art. 32 (wesentliche Einrichtungen) oder Art. 33 (wichtige Einrichtungen) ist genau diese lückenlose Kette aus Scan, Priorisierung, Umsetzung und Ausnahme der Nachweis, dass die Maßnahme aus Art. 21(2)(e) tatsächlich gelebt wird und nicht nur auf dem Papier existiert.

Bereich	Ist-Zustand (typisch)	Soll-Zustand nach NIS2	Aufwand
Scanning	Manuell, unregelmäßig	Regelmäßig, dokumentiert, inkl. OT	Mittel
Priorisierung	Nur CVSS	Kombiniert (CVSS + EPSS + KEV)	Niedrig
Ausnahmen	Ungeschrieben / mündlich	Dokumentiert nach 6.6.2	Niedrig
OT-Patching	Ad hoc, unklare Verantwortung	Segmentierung + dokumentierte Kompensation	Hoch

Bei nachgewiesenen Verstößen gegen Art. 21 – wozu auch ein fehlendes oder nicht dokumentiertes Patch- und Schwachstellenmanagement zählt – sieht Art. 34 NIS2 Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen vor, je nachdem, welcher Betrag höher ist; für wichtige Einrichtungen bis zu 7 Millionen Euro oder 1,4 % des Jahresumsatzes [10].

Häufige Fragen

Gibt NIS2 eine feste Frist für das Einspielen von Sicherheitspatches vor?
Nein. Abschnitt 6.6.1 der CIR verlangt eine „angemessene Frist“ ohne konkrete Zahl. In der Praxis orientieren sich Unternehmen an Kritikalitätsmodellen wie dem oben beschriebenen kombinierten CVSS/EPSS/KEV-Ansatz, um diese Frist nachvollziehbar zu definieren.

Muss jede gefundene Schwachstelle sofort behoben werden?
Nein. Abschnitt 6.6.2 erlaubt eine begründete Ausnahme, wenn die Nachteile der Patch-Anwendung die Sicherheitsvorteile überwiegen – vorausgesetzt, die Entscheidung wird dokumentiert.

Was ist der Unterschied zwischen CVE, der EUVD und dem BSI-Portal?
CVE/NVD ist der globale Referenzstandard für Schwachstellen-IDs. Die EUVD ist die seit Mai 2025 laufende EU-Datenbank mit CSIRT-Koordination und direktem NIS2-Bezug. Das BSI-Portal liefert die nationale Frühwarnung mit direktem Bezug zur deutschen Meldepflicht.

Gilt Abschnitt 6.6/6.10 der CIR direkt für mein Unternehmen?
Nur wenn Sie zu den in der CIR 2024/2690 genannten digitalen Infrastruktur- oder Dienstanbietern zählen (DNS, Cloud, Rechenzentren, CDN, MSP/MSSP, Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdiensteanbieter). Für alle anderen Sektoren ist Art. 21(2)(e) NIS2 die direkt bindende Rechtsgrundlage; die CIR dient dort als Auslegungshilfe, nicht als bindende Checkliste.

Was ändert sich beim Patch-Management für OT-Systeme, die nicht abgeschaltet werden können?
Nichts an der rechtlichen Pflicht – aber Abschnitt 6.6.2 erlaubt die dokumentierte Ausnahme mit kompensierenden Maßnahmen wie Netzwerksegmentierung, solange die Entscheidung nachvollziehbar begründet und regelmäßig neu bewertet wird.

Wie oft müssen dokumentierte Ausnahmen nach 6.6.2 neu bewertet werden?
Die CIR nennt kein festes Intervall. In der Praxis hat sich eine Kopplung an den ohnehin vorgeschriebenen Risikobewertungszyklus bewährt – mindestens jährlich, bei kritischen OT-Systemen häufiger, insbesondere sobald sich der KEV- oder EPSS-Status einer zugrunde liegenden Schwachstelle ändert.

Dieser Artikel bietet allgemeine Informationen und stellt keine Rechts- oder Compliance-Beratung dar. Anforderungen können je nach Rechtsraum und Unternehmenstyp variieren. Konsultieren Sie für eine auf Ihre Situation zugeschnittene Einschätzung eine qualifizierte Rechts- oder Compliance-Fachperson.

Quellen

• NIS-2-Richtlinie (EU) 2022/2555, Art. 21(2) – nis-2-directive.com
• NIS-2-Richtlinie (EU) 2022/2555, Art. 12 – nis-2-directive.com
• Durchführungsverordnung (EU) 2024/2690, Anhang Abschnitt 6.6 – nis2-umsetzung.com
• Durchführungsverordnung (EU) 2024/2690, Anhang Abschnitt 6.10 – nis2-umsetzung.com
• BSI: „#nis2know – Sicherheitsmaßnahmen und Schwachstellenmanagement“ – bsi.bund.de
• BSI IT-Grundschutz-Kompendium, Baustein OPS.1.1.3 „Patch- und Änderungsmanagement“ – bsi.bund.de
• CISA: „Recommended Practice for Patch Management of Control Systems“ (DHS Control Systems Security Program)
• „Enisa Launches European Vulnerability Database“ – cybersecuritynews.com (enisa-launches-euvd)
• „EPSS und CVSS: Schwachstellen richtig priorisieren“ – exposiq.ch
• NIS-2-Richtlinie (EU) 2022/2555, Art. 34 – nis-2-directive.com