NIS2
Patch- und Schwachstellenmanagement unter NIS2
NIS2 verlangt keinen Patch-Stichtag, sondern einen belegbaren Prozess: Schwachstellen erkennen, bewerten, behandeln, dokumentieren. Was das konkret bedeutet — und wie sich der Nachweis ohne manuelle Excel-Pflege erbringen lässt.
Was NIS2 beim Patchen wirklich verlangt
NIS2 enthält keinen Paragrafen, der ein bestimmtes Patch-Intervall festschreibt. Die Pflicht ergibt sich aus Art. 21: Betreiber müssen technische und organisatorische Maßnahmen treffen, um Risiken für ihre Netz- und Informationssysteme zu beherrschen. Dazu gehören ausdrücklich der Umgang mit Schwachstellen und deren Offenlegung sowie Konzepte zur Bewertung der Wirksamkeit dieser Maßnahmen.
Praktisch heißt das: Es zählt nicht der Stichtag, sondern der nachweisbare Prozess. Sie müssen zeigen können, dass Sie Schwachstellen systematisch erkennen, nach Risiko priorisieren, fristgerecht behandeln und das Ganze dokumentieren.
Die vier Stufen eines belastbaren Prozesses
- Erkennen. Vollständiger Asset-Bestand und kontinuierlicher Abgleich gegen bekannte Schwachstellen (CVE-Datenlage). Ohne lückenloses Inventar bleibt jeder Patch-Report unvollständig.
- Bewerten. Priorisierung nach Kritikalität des Systems und Schweregrad der Schwachstelle — nicht jede Lücke ist gleich dringlich, aber jede muss eingeordnet sein.
- Behandeln. Patch einspielen, wo möglich. Wo nicht: dokumentierte Alternative — Isolation, Härtung, kompensierende Kontrolle. Ein “geht nicht” ohne Begründung ist kein zulässiger Endzustand.
- Nachweisen. Lückenlose Historie über Status, Entscheidung und Zeitpunkt — jederzeit für Aufsicht und Geschäftsleitung abrufbar.
Wo es in der Praxis scheitert
Die meisten Organisationen patchen durchaus. Was fehlt, ist der Nachweis. Patch-Stände leben verteilt über mehrere Tools, der Asset-Bestand ist veraltet, und die Begründung für ungeplante Ausnahmen steht — wenn überhaupt — in einer E-Mail. Im Prüffall lässt sich daraus keine konsistente Risikobehandlung rekonstruieren.
Hinzu kommt das Spannungsfeld aus Geschwindigkeit und Stabilität: Schnell patchen erhöht die Sicherheit, riskiert aber Betriebsstörungen. Genau dieser Konflikt führt dazu, dass kritische Updates verschoben werden — und damit zur Lücke, die NIS2 schließen will.
Wie OneLog den Nachweis erzeugt
OneLog behandelt Patch-Management nicht als isolierte Funktion, sondern als Teil eines durchgängigen Schwachstellen-Workflows:
- Inventar als Grundlage. Jedes Asset ist erfasst und mit seinem Patch-Status verknüpft — die Basis für jeden NIS2-Report.
- Automatisierter Rollout. Updates werden über Zero-Touch-Patching ausgerollt, gestaffelt über Canary-Deployment, sodass Stabilität und Geschwindigkeit kein Entweder-oder sind.
- Risikobasierte Priorisierung. Offene Schwachstellen werden nach Kritikalität eingeordnet, statt als flache Liste.
- Autonome Remediation. Definierte Schwachstellen-Tickets arbeiten KI-Agenten Ende-zu-Ende ab — inklusive protokollierter Entscheidung.
- Prüffähige Historie. Jeder Schritt — Erkennung, Bewertung, Behandlung, Ausnahme — landet in einer durchgehenden, exportierbaren Dokumentation.
Das Ergebnis ist die eine Sache, die NIS2 im Kern verlangt: Sie können jederzeit belegen, in welchem Zustand Ihre Flotte ist und warum.
Souverän nachweisbar
OneLog wird in der STACKIT Sovereign Cloud betrieben, mit Sitz in Deutschland und ohne US-Cloud-Exposure. Für ein Werkzeug, das Patch- und Schwachstellendaten Ihrer gesamten Infrastruktur verarbeitet, ist das keine Nebensache, sondern Teil der NIS2-Anforderung an die Sicherheit der eingesetzten Systeme. Zertifiziert nach ISO 27001:2022, die TOM nach Art. 32 DSGVO sind öffentlich.
Häufige Fragen
- Schreibt NIS2 konkrete Patch-Fristen vor?
- Nein. NIS2 nennt keine festen Tage-Fristen für einzelne Patches. Art. 21 verlangt jedoch einen risikobasierten Prozess für den Umgang mit Schwachstellen sowie dessen Wirksamkeit und Dokumentation — Fristen leiten Sie aus der Kritikalität ab.
- Was muss ein NIS2-Patch-Management nachweisen können?
- Einen vollständigen Asset-Bestand, den Patch-Status je System, die Bewertung offener Schwachstellen nach Risiko, die ergriffene Behandlung sowie eine lückenlose Historie. Entscheidend ist die jederzeitige Belegbarkeit gegenüber Aufsicht und Leitung.
- Reicht reines Patchen für die NIS2-Schwachstellenpflicht aus?
- Nein. Wo ein Patch nicht verfügbar oder nicht einspielbar ist, verlangt NIS2 eine dokumentierte alternative Risikobehandlung — etwa Isolation, Härtung oder kompensierende Kontrollen. Dieser Umgang muss nachvollziehbar festgehalten sein.
- Gilt die Schwachstellenpflicht auch für die Lieferkette?
- Ja. Art. 21 bezieht die Sicherheit der Lieferkette ausdrücklich ein. Schwachstellen in eingesetzter Fremdsoftware und bei Dienstleistern müssen Sie ebenso erfassen und behandeln wie Ihre eigenen Systeme.
OneLog in Ihrer Umgebung sehen
Souveränes, NIS2-konformes RMM mit autonomer Remediation — EU-gehostet, kein US-Cloud-Exposure.