NIS2 Schwachstellenmanagement: Patches und Scans als Pflicht
Letzte Aktualisierung: 23. März 2026
NIS2 verpflichtet Unternehmen gemäß Art. 21 Abs. 2 zu Schwachstellenmanagement. Gemeint sind nicht nur einzelne Sicherheitsscans, sondern ein belastbarer Prozess aus Erkennung, Bewertung, Priorisierung, Patch-Steuerung, Wirksamkeitskontrolle und koordinierter Offenlegung von Schwachstellen. Seit dem 6. Dezember 2025 ist diese Logik in Deutschland zudem über § 30 BSIG für besonders wichtige und wichtige Einrichtungen ausdrücklich in nationales Recht umgesetzt.
Die operative Kernaussage lautet deshalb: Wer Schwachstellen nur sammelt, aber nicht risikobasiert priorisiert, fristgerecht behandelt und nachprüfbar nachtestet, erfüllt die NIS2-Anforderungen nicht. Für die angrenzenden Themen Incident Handling, Lieferkette und Governance sind auch unser Beitrag zum NIS2 Incident Response Plan, die Analyse zur NIS2 Lieferkettensicherheit und der Glossarbegriff Informationssicherheit relevant.
Was § 30 BSIG zu Schwachstellen fordert
§ 30 BSIG verpflichtet besonders wichtige und wichtige Einrichtungen zu angemessenen, verhältnismäßigen und wirksamen technischen, operativen und organisatorischen Risikomanagementmaßnahmen. Für das Thema Schwachstellenmanagement ist entscheidend, dass die Norm Sicherheitsmaßnahmen bei Erwerb, Entwicklung und Wartung von informationstechnischen Systemen, Komponenten und Prozessen ausdrücklich einschließlich Management und Offenlegung von Schwachstellen nennt.
Die deutsche Rechtslage ist damit seit dem 6. Dezember 2025 klarer als in vielen älteren NIS2-Leitfäden. Schwachstellenmanagement ist nicht bloß ein Unterpunkt allgemeiner Cyberhygiene, sondern ein eigenständiger Compliance-Baustein mit Prüf- und Nachweiserwartung. Unternehmen müssen also darlegen können, wie sie Schwachstellen erkennen, wie sie Risiken bewerten, wer über Fristen entscheidet, wann Patches ausgerollt werden und wie Ausnahmen freigegeben werden.
Art. 21 NIS2 liefert dazu die europäische Grundlage. Besonders relevant sind die Anforderungen an technische und organisatorische Maßnahmen, an die Sicherheit entlang von Entwicklung und Wartung sowie an Verfahren zur Bewertung der Wirksamkeit von Schutzmaßnahmen. Die oft genannte Kombination aus Art. 21 Abs. 2 Buchst. e und g beschreibt dabei den Kern der Praxis: Unternehmen brauchen sowohl operative Sicherheitsmaßnahmen als auch dokumentierte Verfahren, um zu prüfen, ob diese Maßnahmen tatsächlich wirken.
Für Audits und Managementberichte ist wichtig, dass NIS2 keine perfekte Fehlerfreiheit fordert. Gefordert wird ein nachvollziehbar gesteuerter Prozess. Eine Organisation darf Schwachstellen haben. Sie darf aber nicht planlos sein. Genau hier entsteht die Grenze zwischen technischer Schwäche und Compliance-Verstoß.
Vulnerability Scanning: Tools und Prozesse
Vulnerability Scanning ist unter NIS2 kein Selbstzweck, sondern der Eingangskanal für belastbare Risikosteuerung. Ein Scan ist erst dann regulatorisch nützlich, wenn klar ist, welche Assets er abdeckt, wie häufig er durchgeführt wird, wer die Ergebnisse bewertet und wie Falschmeldungen, Ausnahmen und Remediation dokumentiert werden.
In der Praxis sollten Unternehmen mindestens vier Scan-Perspektiven abdecken:
- Netz- und Systemscans für Server, Clients, Netzwerkgeräte und exponierte Dienste.
- Web- und Anwendungsscans für kundennahe Portale, APIs und Authentisierungsstrecken.
- Dependency- und Container-Scans für Bibliotheken, Images und Build-Artefakte.
- Cloud- und Konfigurationsprüfungen für Fehlkonfigurationen, unnötige Expositionen und Rechtefehler.
Die Durchführungsverordnung (EU) 2024/2690 konkretisiert für bestimmte NIS2-relevante Sektoren, dass Risikoanalyse, Schwachstellenbehandlung, Sicherheitsüberwachung, Training und Wirksamkeitsmessung in überprüfbare Verfahren übersetzt werden müssen. Daraus folgt kein einziges vorgeschriebenes Produkt, wohl aber die Pflicht, Scans in ein methodisches System einzubetten. OpenVAS, Nessus, Qualys, Rapid7, Dependabot oder SBOM-basierte Scanner können alle sinnvoll sein, wenn Scope, Bewertung und Nachverfolgung sauber definiert sind.
Die richtige Frequenz ist risikobasiert. Ein öffentlich erreichbares Kundenportal braucht typischerweise häufigere Scans als ein isoliertes internes Testsystem. Für viele mittelständische Unternehmen ist diese Staffelung praktikabel:
| Bereich | Mindestpraxis | Ziel unter höherem Risiko |
|---|---|---|
| Externe Angriffsfläche | monatlich | wöchentlich oder kontinuierlich |
| Interne Server und Clients | monatlich bis quartalsweise | monatlich |
| Web-Anwendungen und APIs | vor Releases und regelmäßig | pro Release plus laufende Scans |
| Abhängigkeiten und Container | bei jedem Build | kontinuierlich in CI/CD |
Der kritische Fehler liegt fast immer nicht beim Tool, sondern beim Scope. Wenn Shadow-IT, Alt-Systeme, OT-nahe Komponenten, externe SaaS-Abhängigkeiten oder Entwickler-Assets nicht im Inventar stehen, tauchen sie im Schwachstellenmanagement ebenfalls nicht auf. Deshalb hängt gutes Scanning immer von einem gepflegten Asset-Inventar ab. Für die Abgrenzung zu tiefergehenden Prüfungen lohnt ergänzend der Blick auf Penetrationstests unter NIS2 und auf den Beitrag zu Compliance-Software im Mittelstand.
Patch-Management: Fristen und Priorisierung (CVSS)
NIS2 schreibt keine festen Patch-Fristen in Tagen vor, verlangt aber eine risikobasierte, dokumentierte und wirksame Behandlung festgestellter Schwachstellen. Genau deshalb arbeiten viele Unternehmen mit CVSS, Exploit-Informationen, Asset-Kritikalität und Geschäftsbezug in einer kombinierten Priorisierung statt mit einem starren Einheits-SLA.
CVSS ist dabei nützlich, aber allein nicht ausreichend. Eine Schwachstelle mit hohem Score auf einem abgeschotteten Testsystem ist oft weniger dringend als eine mittel bewertete Lücke auf einem öffentlich erreichbaren VPN-Gateway mit aktiver Ausnutzung. Die sinnvolle Priorisierung verbindet deshalb mindestens vier Faktoren:
- Technische Schwere, etwa per CVSS.
- Tatsächliche Ausnutzbarkeit, etwa bekannte Exploits oder aktive Kampagnen.
- Kritikalität des betroffenen Assets für Betrieb, Sicherheit und Meldepflichten.
- Verfügbarkeit eines Patches oder belastbarer Kompensationsmaßnahmen.
Für die Praxis hat sich eine klare Steuerungslogik bewährt:
| Priorität | Typische Kriterien | Praktisches Ziel |
|---|---|---|
| Kritisch | CVSS 9+, aktiv ausgenutzt oder internetexponiert | sofortige Triage, kurzfristiges Patching |
| Hoch | CVSS 7,0 bis 8,9 mit relevantem Geschäftsbezug | Behebung im kurzen Regelzyklus |
| Mittel | CVSS 4,0 bis 6,9 ohne akute Ausnutzung | geplanter Patch im Wartungsfenster |
| Niedrig | geringe Auswirkung oder schwer ausnutzbar | dokumentierte Restlaufzeit oder Akzeptanz |
Wichtig ist die Governance hinter der Tabelle. Jede Frist braucht einen Eigentümer, einen Eskalationsweg und eine Ausnahmeentscheidung. Wenn ein Patch nicht eingespielt werden kann, etwa wegen OT-Abhängigkeiten, Validierungsaufwand oder Herstellerrestriktionen, endet der Prozess nicht mit „nicht möglich“. NIS2-konform wird die Lage erst durch dokumentierte Kompensationsmaßnahmen wie Segmentierung, Deaktivierung gefährdeter Funktionen, engmaschigeres Monitoring oder temporäre Zugriffsbeschränkungen.
Patch-Management ist außerdem nur dann vollständig, wenn nach der Installation ein Retest erfolgt. Ohne erneute Prüfung wissen Sie nicht, ob der Patch wirksam war, ob er auf allen betroffenen Systemen angekommen ist oder ob Nebenpfade offen geblieben sind. Genau deshalb ist Retesting kein Komfortmerkmal, sondern Teil des Nachweises zur Wirksamkeit. Wer diese Wirksamkeitslogik im Gesamtzusammenhang verstehen will, sollte zusätzlich den Beitrag zu CRA SBOM und Komponenten-Transparenz lesen.
Coordinated Vulnerability Disclosure nach NIS2
Art. 12 NIS2 verpflichtet die Mitgliedstaaten, Verfahren zur koordinierten Offenlegung von Schwachstellen aufzubauen. Das bedeutet praktisch: Sicherheitsforscher, betroffene Hersteller, Betreiber und Behörden sollen Schwachstellen nicht ungeordnet oder zufällig veröffentlichen, sondern über einen geregelten Prozess mit Ansprechpartnern, Zeitfenstern und Schutz für Meldende koordinieren.
Der Mechanismus ist gerade für regulierte Unternehmen wichtig, weil Schwachstellen heute oft nicht nur intern entdeckt werden. Hinweise kommen von Security-Teams, Kundinnen und Kunden, Bug-Bounty-Plattformen, Lieferanten oder externen Forschenden. Ein Unternehmen braucht daher eine veröffentlichte und intern verankerte Vulnerability-Disclosure-Policy mit klaren Meldekanälen, Reaktionszeiten und Zuständigkeiten.
Für Deutschland ist das BSI im NIS2-Kontext zentral, weil Schwachstellen und Vorfälle über das BSI-Portal gemeldet werden können und dort auch anonyme Schwachstellenmeldungen vorgesehen sind. ENISA ergänzt diese nationale Logik auf europäischer Ebene über die European Vulnerability Database (EUVD), die seit dem 13. Mai 2025 operativ ist und öffentlich zugängliche Informationen zu Schwachstellen, Ausnutzungsstatus, Patches und Mitigationsmaßnahmen bündelt.
Unternehmen sollten daraus drei konkrete Konsequenzen ziehen:
- Eine verantwortliche Kontaktadresse und einen veröffentlichten Offenlegungsprozess einrichten.
- Externe Meldungen wie interne Funde in denselben Bewertungs- und Patch-Prozess überführen.
- Entscheidungen zu Veröffentlichungszeitpunkt, Remediation und Kommunikation dokumentieren.
Wer Schwachstellenmeldungen ignoriert oder nur informell per Zufall bearbeitet, riskiert nicht nur technische Schäden, sondern auch Governance-Probleme. Für die operative Vertiefung sind unser Beitrag zu Vulnerability Disclosure in Deutschland, der Artikel zu Bug-Bounty-Programmen in Deutschland und der Glossarbegriff Cyber-Resilienz sinnvoll.
Schwachstellenmanagement-Prozess in 6 Schritten
NIS2-konformes Schwachstellenmanagement lässt sich für den Mittelstand auf sechs belastbare Schritte herunterbrechen. Entscheidend ist, dass jeder Schritt einen klaren Output erzeugt und nicht nur als Überschrift in einer Richtlinie steht.
1. Assets und Verantwortlichkeiten festlegen
Ein wirksamer Prozess beginnt mit einem vollständigen Inventar kritischer Systeme, Anwendungen, Schnittstellen, Cloud-Dienste und Abhängigkeiten. Zu jedem Asset gehören Owner, Kritikalität, Exposition und idealerweise Wartungsfenster. Ohne dieses Fundament bleiben Scans lückenhaft und Patch-Entscheidungen zufällig.
2. Schwachstellen systematisch erkennen
Schwachstellen müssen aus mehreren Quellen zusammengeführt werden: Scanner, Herstellerwarnungen, SIEM, Pentests, Bug-Bounty-Hinweise, externe Forschende und Lieferantenmeldungen. Wichtig ist ein zentraler Intake statt einzelner Postfächer oder Excel-Listen in Silos.
3. Risiken bewerten und priorisieren
Nach der Erkennung folgt die Bewertung. CVSS ist ein Startpunkt, aber zusätzlich müssen Exposition, Geschäftsrelevanz, bekannte Exploits und vorhandene Schutzschichten einfließen. Am Ende steht keine reine Kennzahl, sondern eine geschäftsfähige Priorität mit Frist und Verantwortlichen.
4. Beheben oder kompensieren
Der vierte Schritt ist die eigentliche Remediation. Das kann ein Patch, ein Konfigurationsfix, ein Upgrade, ein Rollback, das Entfernen einer Komponente oder eine kompensierende Maßnahme sein. Wichtig ist, dass jede offene Schwachstelle einen dokumentierten Behandlungsstatus erhält und nicht aus dem Blick verschwindet.
5. Wirksamkeit nachtesten
Nach der Umsetzung braucht es einen Retest. Nur so wird aus „Maßnahme durchgeführt“ die Aussage „Risiko tatsächlich reduziert“. Retests sollten automatisiert oder mindestens planbar in denselben Prozess integriert sein wie die Erstprüfung.
6. Berichten und verbessern
Der letzte Schritt ist Management-Reporting und Prozessverbesserung. Sinnvolle Kennzahlen sind etwa offene kritische Schwachstellen, durchschnittliche Behebungsdauer, Ausnahmequoten, Wiederöffnungen und Anteil erfolgreich getesteter Patches. Genau diese Sicht macht Schwachstellenmanagement zu Governance statt zu rein operativer Technik.
Typische Fehler bei der Umsetzung
Die häufigsten NIS2-Lücken entstehen nicht, weil Unternehmen keinen Scanner besitzen, sondern weil Prozess und Verantwortung fehlen. Typisch sind isolierte Tool-Landschaften, fehlende Asset-Owner, keine verbindlichen Patch-SLAs, ungeprüfte Ausnahmen und fehlende Retests.
Ebenso problematisch ist die Trennung zwischen IT-Betrieb, Entwicklung, Security und Management. Schwachstellenmanagement scheitert regelmäßig dort, wo niemand entscheiden darf, welches System Vorrang hat, wann ein Notfall-Patch ein Change-Fenster durchbrechen darf oder welche Rest-Risiken formal akzeptiert werden. Genau deshalb gehört das Thema in ein Compliance-Management-System und nicht nur in die Administratorenrunde.
FAQ zu NIS2 Schwachstellenmanagement
Ist Schwachstellenmanagement Pflicht unter NIS2?
Ja. NIS2 verlangt risikobasierte Cybersicherheitsmaßnahmen, und § 30 BSIG nennt seit dem 6. Dezember 2025 ausdrücklich das Management und die Offenlegung von Schwachstellen. Unternehmen brauchen daher einen dokumentierten Prozess, nicht nur einzelne Sicherheitsmaßnahmen.
Wie implementiere ich Schwachstellenmanagement für NIS2-Compliance?
Beginnen Sie mit einem Asset-Inventar, führen Sie regelmäßige Scans ein, priorisieren Sie nach Risiko, steuern Sie Patches verbindlich, definieren Sie Ausnahmewege und etablieren Sie Retests. Entscheidend ist die Nachvollziehbarkeit vom Fund bis zur wirksamen Behebung.
Reicht monatliches Vulnerability Scanning aus?
Nicht pauschal. Für manche internen Systeme kann ein monatlicher Rhythmus genügen, für internetexponierte Dienste oder stark veränderte Anwendungen ist das oft zu wenig. NIS2 erwartet eine risikobasierte Frequenz, keine pauschale Kalenderlösung.
Muss mein Unternehmen CVSS verwenden?
NIS2 schreibt CVSS nicht ausdrücklich vor. CVSS ist aber ein sehr verbreiteter Standard zur technischen Schwerebewertung und in der Praxis sinnvoll, wenn er um Geschäftsrelevanz, Exposition und Exploit-Informationen ergänzt wird.
Was tun, wenn kein Patch verfügbar ist?
Dann braucht es dokumentierte Kompensationsmaßnahmen. Typisch sind Segmentierung, Zugriffsbeschränkung, härteres Monitoring, temporäre Deaktivierung betroffener Funktionen und eine formale Risikoentscheidung mit Nachverfolgung bis zur endgültigen Behebung.
Ist Coordinated Vulnerability Disclosure auch für den Mittelstand relevant?
Ja. Auch mittelständische Unternehmen erhalten heute externe Schwachstellenmeldungen, betreiben Web-Anwendungen oder liefern Software und Dienste in regulierte Lieferketten. Ein geregelter Offenlegungsprozess reduziert Haftungs-, Reputations- und Eskalationsrisiken deutlich.
Fazit: NIS2 verlangt Steuerung statt Ad-hoc-Patching
NIS2 Schwachstellenmanagement bedeutet nicht, jeden Scanner-Befund sofort hektisch zu patchen. Gefordert ist ein steuerbarer Gesamtprozess aus Scans, Priorisierung, Patch-Management, Ausnahmen, Retests und Offenlegung. Seit dem 6. Dezember 2025 ist diese Pflicht in Deutschland über § 30 BSIG zusätzlich ausdrücklich verankert.
Wenn Sie Schwachstellenmanagement nicht nur technisch, sondern auditfähig aufsetzen wollen, ist jetzt der richtige Zeitpunkt für ein verbindliches Betriebsmodell. Die pragmatischsten nächsten Schritte sind ein sauberes Asset-Inventar, klare Prioritätsregeln, dokumentierte Patch-Fristen und ein veröffentlichter Offenlegungsprozess. Wenn Sie Verantwortliche aus IT, Compliance und Management dazu auf einen gemeinsamen Stand bringen wollen, ist unsere NIS2-Schulung der passende nächste Schritt; für die operative Umsetzung lohnt sich zusätzlich ein Beratungsgespräch über die bestehende Security-Governance.