NIS2 Patch- und Schwachstellenmanagement: Anforderungen und Praxis

Ein Sicherheitspatch, der drei Monate ungetestet auf einem Produktivsystem liegt, ist unter NIS2 kein Kavaliersdelikt, sondern erklärungsbedürftig. Die EU-Durchführungsverordnung (CIR) 2024/2690 verlangt in Abschnitt 6.6, dass Sicherheitspatches „innerhalb einer angemessenen Frist nach ihrer Verfügbarmachung“ angewendet werden – und dass ein bewusster Verzicht auf das Einspielen ordnungsgemäß dokumentiert und begründet wird. Verbindlich ist das für die in der CIR genannten digitalen Anbieter; für alle anderen besonders wichtigen und wichtigen Einrichtungen ist es ein naheliegender Maßstab für § 30 BSIG. In beiden Fällen verschiebt sich der 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, stellt ein verbreitetes Priorisierungsmodell nach Kritikalität vor 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 gehört zu den zehn Mindestmaßnahmen des Risikomanagements nach Art. 21 Abs. 2 NIS2, die Deutschland in § 30 Abs. 2 BSIG umgesetzt hat. Die Pflicht gilt für alle besonders wichtigen und wichtigen Einrichtungen; Umfang und Tiefe der Maßnahmen richten sich nach dem Verhältnismäßigkeitsgrundsatz des § 30 Abs. 1 BSIG [10]. Die vollständige Übersicht aller zehn Maßnahmen finden Sie in unserem Leitfaden zu den NIS2-Anforderungen.

Auf EU-Ebene verankert ist die Pflicht in Art. 21 Abs. 2 Buchst. e NIS2: „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Management und Offenlegung von Schwachstellen“ [1]. In Deutschland ist die maßgebliche Norm § 30 Abs. 2 Satz 2 Nr. 5 BSIG: „Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen, einschließlich Management und Offenlegung von Schwachstellen“ [10]. 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 im Bereich der Cybersicherheit“ bilden einen eigenen, separaten Pflichtpunkt (Art. 21 Abs. 2 Buchst. g NIS2; in Deutschland § 30 Abs. 2 Satz 2 Nr. 7 BSIG) [1][10]. Beide Pflichten überschneiden sich inhaltlich stark; für die Dokumentation empfiehlt sich dennoch die Zuordnung zu § 30 Abs. 2 Satz 2 Nr. 5 BSIG bzw. Art. 21 Abs. 2 Buchst. e NIS2. 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 § 30 Abs. 2 Satz 2 Nr. 5 BSIG?
Besonders wichtige Einrichtung	Ja – Aufsicht nach § 61 BSIG (BSI kann u. a. Audits, Prüfungen oder Zertifizierungen anordnen)
Wichtige Einrichtung	Ja – Aufsicht nach § 62 BSIG, wenn Tatsachen die Annahme eines Verstoßes rechtfertigen

Der Katalog der Pflichtpunkte ist für beide Kategorien derselbe. Wie aufwendig die Umsetzung ausfällt, hängt nach § 30 Abs. 1 Satz 2 BSIG von Risikoexposition, Größe der Einrichtung, Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere möglicher Sicherheitsvorfälle ab; deutlich unterschiedlich ist zudem die Aufsichtsintensität [10].

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 die in Art. 1 CIR genannten Einrichtungsarten: DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing-Dienste, Rechenzentrumsdienste, Content Delivery Networks, Managed Service Provider, Managed Security Service Provider, Online-Marktplätze, Online-Suchmaschinen, Plattformen sozialer Netzwerke und Vertrauensdiensteanbieter. Für diese hat die CIR nach § 30 Abs. 3 BSIG Vorrang [10]. Für alle anderen Einrichtungen kann Abschnitt 6.6 als Orientierung dienen, ist dort aber nicht unmittelbar verbindlich. Abschnitt 6.6.1 verlangt Verfahren – abgestimmt auf Änderungs-, Schwachstellen- und Risikomanagement –, die sicherstellen, dass Sicherheitspatches a) innerhalb einer angemessenen Frist nach ihrer Verfügbarmachung angewendet, b) vor dem Einsatz in Produktionssystemen getestet werden, c) aus vertrauenswürdigen Quellen stammen und auf ihre Integrität geprüft werden und d) zusätzliche Maßnahmen umgesetzt und Restrisiken akzeptiert werden, wenn ein Patch nicht verfügbar ist oder nach 6.6.2 nicht angewendet wird [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 Abweichung von der Frist nach 6.6.1 Buchst. a: Einrichtungen können darauf verzichten, Sicherheitspatches anzuwenden, „wenn die Nachteile der Anwendung der Sicherheitspatches die Vorteile für die Cybersicherheit überwiegen“ – sie müssen dies 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 nennt in seinem #nis2know-Infopaket zu § 30 Abs. 2 Satz 2 Nr. 5 BSIG für das Patch- und Update-Management unter anderem diese Punkte: 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 über technische Schwachstellen erlangen, ihre Exposition bewerten und geeignete Maßnahmen ergreifen (6.10.1). Dazu gehören unter anderem das Verfolgen von Hinweisen von CSIRTs, Behörden und Anbietern, soweit angemessen Schwachstellen-Scans, die unverzügliche Behebung von Schwachstellen, die die Einrichtung als für ihren Betrieb kritisch eingestuft hat, sowie ein Verfahren für die Offenlegung von Schwachstellen im Einklang mit den nationalen Konzepten zur koordinierten Offenlegung (6.10.2). Rechtfertigen die möglichen Auswirkungen einer Schwachstelle es, ist ein Plan zu ihrer Minderung zu erstellen und umzusetzen – andernfalls ist zu dokumentieren und zu begründen, warum keine Abhilfemaßnahmen erforderlich sind (6.10.3) [4]. Die Behandlung von Schwachstellen muss mit Änderungs-, Patch-, Risiko- und Vorfallmanagement vereinbar sein (6.10.2 Buchst. d) [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 oder Anbieter; Schwachstellen müssen dem Koordinator auf Wunsch anonym gemeldet werden können [2]. In Deutschland ist das BSI nach § 5 Abs. 1 BSIG „der nationale Koordinator für die Zwecke einer koordinierten Offenlegung von Schwachstellen nach Artikel 12 Absatz 1 der NIS-2-Richtlinie“; Meldungen an das BSI können anonym erfolgen (§ 5 Abs. 2 BSIG) [10]. ENISA betreibt nach Art. 12 Abs. 2 NIS2 die Europäische Schwachstellendatenbank (EUVD), die seit dem 13. Mai 2025 in Betrieb ist und unter anderem Schwachstellenbeschreibung, betroffene Produkte samt Schweregrad sowie verfügbare Patches oder Gegenmaßnahmen bündelt [2][8]. Die EUVD ersetzt die etablierten CVE-Einträge nicht, sondern verknüpft öffentlich verfügbare Informationen aus mehreren Quellen, darunter CSIRTs, Hersteller und bestehende Datenbanken. ENISA ist zudem seit Januar 2024 selbst CVE Numbering Authority und kann CVE-IDs vergeben [8].

Quelle	Zweck
CVE / NVD	Globaler Referenzstandard für Schwachstellen-IDs
EUVD (ENISA)	EU-Datenbank nach Art. 12 Abs. 2 NIS2, seit 13.05.2025 in Betrieb; u. a. Ausnutzungsstatus und Patch-Hinweise
CERT-Bund (BSI) – Warn- und Informationsdienst (WID)	Nationale Sicherheitshinweise und Warnungen zu Schwachstellen

Auf nationaler Ebene empfiehlt das BSI den Einsatz des Common Security Advisory Framework (CSAF) für ein automatisiertes Schwachstellenmanagement; mit der Technischen Richtlinie TR-03191 können Einrichtungen Lieferanten vertraglich zur Bereitstellung von Sicherheitsinformationen nach CSAF verpflichten. Zudem empfiehlt das BSI sowie die öffentliche Bereitstellung von Kontaktdaten für externe Sicherheitsforschende, etwa ü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 ausdrücklich die Vereinbarkeit 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) von FIRST schätzt dagegen die Wahrscheinlichkeit, dass eine veröffentlichte CVE in den nächsten 30 Tagen ausgenutzt wird [11]. Der KEV-Katalog der US-Behörde CISA listet Schwachstellen, deren aktive Ausnutzung belegt ist – im Oktober 2026 rund 1.700 Einträge [12]. Nach Angaben von FIRST wird nur rund 5 Prozent aller Schwachstellen überhaupt jemals in freier Wildbahn ausgenutzt [11] – ein reiner CVSS-Ansatz führt damit leicht zu Überpriorisierung.

Verbreitet ist ein kombiniertes, vierstufiges Modell, das wir hier in Anlehnung an [9] als Orientierung darstellen – es handelt sich um eine Praxisheuristik, nicht um eine regulatorische Vorgabe; die Zielfristen sind Beispielwerte, keine gesetzlichen Fristen:

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

Ein solches Modell kann eine lange Rohliste von Scan-Funden auf eine deutlich kleinere Zahl tatsächlich dringlicher Fälle verdichten – und liefert gleichzeitig eine dokumentierte Begründung dafür, welche Frist im Einzelfall als „angemessen“ im Sinne von Abschnitt 6.6.1 gilt.

Beispiel: Eine kritische Schwachstelle mit CVSS 9,8 in einer intern genutzten Webanwendung, für die noch keine aktive Ausnutzung bekannt ist (EPSS 0,15), 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: Auf einen Patch kann verzichtet werden, wenn die Nachteile seiner Anwendung die Vorteile für die Cybersicherheit überwiegen – vorausgesetzt, die Entscheidung wird dokumentiert und begründet; nach 6.6.1 Buchst. d sind dann zusätzliche Maßnahmen umzusetzen und Restrisiken zu akzeptieren [3].

Nach dem BSI kann das Scannen von OT-Geräten auf bekannte Sicherheitslücken außerhalb der Produktionsumgebung erfolgen; Netzsegmentierung zur Begrenzung möglicher Schadensausbreitung führt das BSI als eigene Maßnahme auf [5]. In der Praxis ist sie die naheliegende zusätzliche Maßnahme im Sinne von 6.6.1 Buchst. d, wenn ein Patch nicht sofort eingespielt werden kann. Die Recommended Practice des US-Heimatschutzministeriums (DHS) zum Patch-Management von Steuerungssystemen von 2008, heute bei CISA abrufbar, empfiehlt unter anderem, vor dem Patchen ein Backup bzw. Archiv anzulegen und auf seine Integrität zu prüfen, Patches zunächst auf einem Standby-System zu testen und das gepatchte System danach eng zu überwachen – denn bei Steuerungssystemen haben Verfügbarkeit und Integrität typischerweise Vorrang vor Vertraulichkeit [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 in der Regel erst die Kombination aus Netzwerksegmentierung (als kompensierende Maßnahme außerhalb des eigentlichen Patch-Zyklus) und dokumentierter Ausnahme nach 6.6.2 nachvollziehbar 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 empfiehlt unter anderem regelmäßiges Scannen von Systemen, Priorisierung nach Risiko und Einfluss auf Geschäftsprozesse sowie die 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]. Der IT-Grundschutz ist allerdings ein BSI-Standard, kein Gesetz: Seine Anforderungen und etwaige Fristen werden für Einrichtungen nicht schon durch das BSIG verbindlich.

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 Prüfung durch das BSI nach § 61 BSIG (besonders wichtige Einrichtungen) oder § 62 BSIG (wichtige Einrichtungen) belegt genau diese lückenlose Kette aus Scan, Priorisierung, Umsetzung und Ausnahme, dass die Maßnahme nach § 30 Abs. 2 Satz 2 Nr. 5 BSIG tatsächlich gelebt wird und nicht nur auf dem Papier existiert. Zudem verlangt § 30 Abs. 1 Satz 3 BSIG ausdrücklich, die Einhaltung der Pflichten zu dokumentieren [10].

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

Wer Maßnahmen nach § 30 Abs. 1 Satz 1 BSIG nicht, nicht richtig, nicht vollständig oder nicht rechtzeitig ergreift oder ihre Einhaltung nicht dokumentiert, handelt ordnungswidrig (§ 65 Abs. 2 Nr. 2 und 3 BSIG) – dazu kann auch ein fehlendes oder nicht dokumentiertes Patch- und Schwachstellenmanagement zählen. Möglich sind Geldbußen bis zu 10 Millionen Euro für besonders wichtige und bis zu 7 Millionen Euro für wichtige Einrichtungen; nur bei einem weltweiten Gesamtumsatz von mehr als 500 Millionen Euro kann die Obergrenze stattdessen bis zu 2 % bzw. 1,4 % dieses Umsatzes betragen (§ 65 Abs. 5 bis 7 BSIG) [10].

Häufige Fragen

Gibt NIS2 eine feste Frist für das Einspielen von Sicherheitspatches vor?
Nein. Weder § 30 BSIG noch die CIR nennen eine feste Zahl: Abschnitt 6.6.1 der CIR verlangt eine „angemessene Frist“, Abschnitt 6.10.2 die unverzügliche Behebung von Schwachstellen, die die Einrichtung selbst als kritisch eingestuft hat. Pauschale Angaben wie „kritische Patches binnen 72 Stunden“ sind keine gesetzlichen Fristen. In der Praxis orientieren sich Einrichtungen 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?
Nicht in jedem Fall. Abschnitt 6.6.2 erlaubt eine begründete Ausnahme, wenn die Nachteile der Patch-Anwendung die Vorteile für die Cybersicherheit überwiegen – vorausgesetzt, die Entscheidung wird dokumentiert und begründet. Für Schwachstellen, die die Einrichtung als für ihren Betrieb kritisch eingestuft hat, verlangt Abschnitt 6.10.2 dagegen eine unverzügliche Behebung; wo ein Patch nicht möglich ist, sind zusätzliche Maßnahmen nötig (6.6.1 Buchst. d).

Was ist der Unterschied zwischen CVE, der EUVD und den Warnungen von CERT-Bund?
CVE/NVD ist der globale Referenzstandard für Schwachstellen-IDs. Die EUVD ist die seit Mai 2025 betriebene EU-Datenbank nach Art. 12 Abs. 2 NIS2, die Informationen aus CSIRTs, von Herstellern und aus bestehenden Datenbanken bündelt. Der Warn- und Informationsdienst (WID) von CERT-Bund liefert die nationalen Sicherheitshinweise des BSI [13]. Das BSI-Portal dient dagegen der Registrierung und der Meldung erheblicher Sicherheitsvorfälle, nicht als Schwachstellen-Feed.

Gilt Abschnitt 6.6/6.10 der CIR direkt für mein Unternehmen?
Unmittelbar verbindlich ist sie nur für die elf in Art. 1 CIR 2024/2690 genannten Einrichtungsarten (digitale Infrastruktur- und Diensteanbieter, siehe Liste oben); § 30 Abs. 3 BSIG gibt ihr für diese Vorrang. Für alle anderen Einrichtungen ist § 30 Abs. 2 Satz 2 Nr. 5 BSIG die maßgebliche Rechtsgrundlage; die CIR kann dort als Orientierung dienen, ist aber keine 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, verbunden mit zusätzlichen Maßnahmen nach 6.6.1 Buchst. d 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?
Weder die CIR noch das BSIG nennen ein festes Intervall. In der Praxis bietet sich eine Kopplung an den Zyklus der eigenen Risikobewertung an – etwa 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

• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), Art. 21 Abs. 2 – EUR-Lex
• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), Art. 12 – EUR-Lex
• Durchführungsverordnung (EU) 2024/2690, Art. 1 und Anhang Nr. 6.6 – EUR-Lex
• Durchführungsverordnung (EU) 2024/2690, Anhang Nr. 6.10 – EUR-Lex
• BSI: „#nis2know – Sicherheitsmaßnahmen und Schwachstellenmanagement“ – bsi.bund.de
• BSI IT-Grundschutz-Kompendium, Baustein OPS.1.1.3 „Patch- und Änderungsmanagement“ – bsi.bund.de
• DHS Control Systems Security Program: „Recommended Practice for Patch Management of Control Systems“, Dezember 2008 – cisa.gov
• ENISA: „Consult the European Vulnerability Database to enhance your digital security!“, Pressemitteilung vom 13.05.2025 – enisa.europa.eu
• „EPSS und CVSS: Schwachstellen richtig priorisieren“ – exposiq.ch
• BSI-Gesetz (BSIG) in der Fassung des NIS2UmsuCG, §§ 5, 30, 61, 62, 65 – gesetze-im-internet.de
• FIRST: Exploit Prediction Scoring System (EPSS) und „Probability, Percentiles, and Binning“ – first.org
• CISA: Known Exploited Vulnerabilities Catalog – cisa.gov
• CERT-Bund (BSI): Warn- und Informationsdienst (WID) – wid.cert-bund.de