SLAs zur Schwachstellenbehebung für NIS2 und DORA

Um 08:17 Uhr an einem Dienstagmorgen Anfang 2026 erhält Anna, Chief Information Security Officer (CISO) eines schnell wachsenden Fintechs, die erste Nachricht, noch bevor ihr Kaffee ausgetrunken ist.

Das SOC hat Hinweise auf aktive Diskussionen zur Ausnutzung einer Schwachstelle in einem kundenbezogenen API-Gateway markiert. Engineering bestätigt, dass der Patch verfügbar, aber riskant ist, weil das Gateway einem Zahlungsprozess vorgeschaltet ist. Der Compliance-Manager leitet eine formelle Anfrage einer nationalen zuständigen Behörde weiter, die Nachweise zur „Schwachstellenbehandlung und Offenlegung“ sowie den Nachweis verlangt, dass der Prozess in den vergangenen 12 Monaten wirksam war. Die Beschaffung ergänzt ein drittes Problem: Das Gateway wird von einem MSP verwaltet, und der Vertrag besagt lediglich, dass der Anbieter „Sicherheitsupdates zeitnah“ einspielt.

Um 09:00 Uhr ist dies nicht mehr nur ein Patching-Thema. Es ist ein Nachweisthema nach ISO/IEC 27001:2022, ein NIS2-Thema der Cyberhygiene, ein DORA-Thema des IKT-Risikomanagements, ein Thema der Lieferanten-Governance und potenziell ein Thema der Vorfallmeldung, wenn die Ausnutzung die Servicekontinuität oder personenbezogene Daten betrifft.

Das ist die praktische Compliance-Lücke, mit der viele Organisationen 2026 konfrontiert sein werden. Sie verfügen über Scanner, Dashboards, Tickets und Patch-Werkzeuge, können die Auditfragen aber nicht klar beantworten:

• Wer hat das SLA zur Behebung genehmigt?
• Wie ist das SLA risikobasiert ausgestaltet?
• Was passiert, wenn ein kritischer Patch die Frist verfehlt?
• Wie werden aus dem Internet erreichbare Assets priorisiert?
• Wie werden Lieferanten an dieselben Fristen gebunden?
• Wo befindet sich die Aufzeichnung zur Risikoakzeptanz für ein ungepatchtes System?
• Welche Nachweise belegen, dass die Kontrolle betrieben wurde und nicht nur existierte?

Die Antwort ist keine weitere Tabelle mit Fälligkeitsterminen. SLAs zur Schwachstellenbehebung müssen als lebendes Kontrollsystem gesteuert werden, das Asset-Verantwortung, Schwachstellenbewertung, Bedrohungsinformationen, Änderungsmanagement, Lieferanten-SLAs, Ausnahmebehandlung, Überwachung, Vorfallreaktion und Managementbewertung miteinander verbindet.

Genau hier werden Clarysecs Enterprise-Richtlinie zum Schwachstellen- und Patch-Management (VPMP), die KMU-Richtlinie zum Schwachstellen- und Patch-Management (VPMP-SME), die Richtlinie zur Sicherheit von Lieferanten und Drittparteien für KMU (TPSSP-SME), Zenith Blueprint (ZB) und Zenith Controls (ZC) nützlich. Zusammen machen sie aus „schneller patchen“ einen belastbaren Governance-Prozess, der einer Auditprüfung nach ISO, NIS2, DORA, GDPR, NIST und im ISACA-Stil standhält.

Warum SLAs zur Schwachstellenbehebung zu Nachweisen auf Leitungsebene wurden

Schwachstellenbehebung wurde früher als IT-Hygienekennzahl behandelt. 2026 ist sie eher eine regulierte Verpflichtung zur operativen Resilienz.

NIS2 macht Cybersicherheit zu einer Frage der Rechenschaftspflicht des Managements. Wesentliche und wichtige Einrichtungen müssen sicherstellen, dass ihre Leitungsorgane Maßnahmen zum Cybersicherheitsrisikomanagement genehmigen, deren Umsetzung überwachen und Schulungen erhalten, damit sie Risiken und die Auswirkungen von Sicherheitspraktiken auf Services verstehen. NIS2 Artikel 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Lieferkettensicherheit, sicherer Beschaffung und Wartung, Schwachstellenbehandlung und Offenlegung, Cyberhygiene, Schulung, Zugriffskontrolle, Asset-Management und Authentifizierung.

Für Finanzunternehmen ist DORA das spezialisierte Regelwerk für operative Resilienz. Es verlangt Governance- und Kontrollvorkehrungen für IKT-Risiken, wobei das Leitungsorgan das IKT-Risikomanagement definiert, genehmigt, überwacht und dafür verantwortlich bleibt. Außerdem verlangt DORA die Identifizierung von IKT-Assets und Abhängigkeiten, Schutz- und Präventionskontrollen wie Patching und Änderungsmanagement, Management IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz und Management von IKT-Drittparteienrisiken.

Die praktische Auswirkung ist erheblich. Eine verfehlte Patch-Frist kann auf ein Versagen hinweisen bei:

• Governance, wenn das Management keine risikobasierten SLAs genehmigt hat
• Asset-Management, wenn der betroffene Systemverantwortliche unbekannt ist
• Änderungsmanagement, wenn Notfall-Patching nicht kontrolliert wird
• Lieferantenmanagement, wenn die Fristen des Anbieters vage sind
• Vorfallreaktion, wenn Anzeichen einer Ausnutzung nicht triagiert werden
• Nachweismanagement, wenn Tickets und Protokolle den Abschluss nicht belegen können
• Risikobehandlung, wenn Ausnahmen nicht genehmigt und überprüft werden

ISO/IEC 27001:2022 bildet das Rückgrat des Managementsystems. Die Abschnitte 4.1 bis 4.3 verlangen, dass Organisationen interne und externe Themen, Anforderungen interessierter Parteien, rechtliche und vertragliche Verpflichtungen sowie Schnittstellen zu anderen Organisationen verstehen. Die Abschnitte 6.1.1 bis 6.1.3 verlangen Risikobeurteilung, Risikobehandlung, eine Erklärung zur Anwendbarkeit und die Genehmigung des Restrisikos durch den Risikoverantwortlichen. Die Abschnitte 9.1, 9.2, 9.3, 10.1 und 10.2 verlangen Überwachung, internes Audit, Managementbewertung, kontinuierliche Verbesserung, Korrekturmaßnahmen und aufbewahrte Nachweise.

Kurz gesagt: Wenn SLAs zur Schwachstellenbehebung auditbereit sein sollen, müssen sie Teil des ISMS sein und nicht nur eine DevOps-Kennzahl.

Das SLA-Modell, das Auditoren erwarten

Ein SLA zur Schwachstellenbehebung sollte drei Fragen beantworten:

1. Wie schnell müssen wir handeln?
2. Wer ist rechenschaftspflichtig?
3. Welche Nachweise belegen das Ergebnis?

Die Richtlinie zum Schwachstellen- und Patch-Management definiert einen praktischen Ausgangspunkt für risikobasierte Behebungsfristen:

Die Organisation muss alle erkannten Schwachstellen anhand einer standardisierten Methodik klassifizieren (z. B. CVSS v3.x) und Behebungsfristen anwenden, die an der geschäftlichen Kritikalität ausgerichtet sind: 5.2.1 Kritisch (CVSS 9.0-10.0): sofortige Prüfung; Patch-Frist von maximal 72 Stunden. 5.2.2 Hoch (7.0-8.9): Reaktion innerhalb von 48 Stunden; Patch-Frist von 7 Kalendertagen. 5.2.3 Mittel (4.0-6.9): Reaktion innerhalb von 5 Tagen; Patch-Frist von 30 Kalendertagen. 5.2.4 Niedrig (<4.0): Reaktion innerhalb von 10 Tagen; Patch-Frist von 60 Kalendertagen.

Diese Klausel ist wirkungsvoll, weil sie Reaktionszeit und Patch-Frist voneinander trennt. Eine hohe Schwachstelle darf nicht sechs Tage unbemerkt liegen bleiben und dann am siebten Tag gepatcht werden. Die Reaktionszeit bestätigt Triage, Verantwortlichkeit, Auswirkungsbewertung und Behebungsplanung. Die Patch-Frist bestätigt den technischen Abschluss oder eine genehmigte Ausnahme.

Für kleinere Organisationen verwendet die Richtlinie zum Schwachstellen- und Patch-Management für KMU eine einfachere, aber weiterhin auditierbare Formulierung:

Kritische Patches müssen innerhalb von 3 Tagen nach Veröffentlichung eingespielt werden, insbesondere bei aus dem Internet erreichbaren Systemen

Und für den breiteren Patch-Bestand:

Alle anderen Patches müssen innerhalb von 30 Tagen eingespielt werden, sofern keine gültige Ausnahme dokumentiert ist

Es geht nicht darum, dass jede Organisation identische Fristen verwenden muss. ISO/IEC 27001:2022, NIS2 und DORA unterstützen alle den Grundsatz der Verhältnismäßigkeit. Entscheidend ist, dass SLAs zur Behebung definiert, genehmigt, risikobasiert, überwacht und nachgewiesen werden.

An dieser Stelle scheitern viele Unternehmen. Sie definieren das SLA, aber nicht die Nachweise. Aus Sicht eines Auditors ist eine Richtlinie ohne operative Aufzeichnungen ein Versprechen, keine Kontrolle.

Asset-Verantwortung ist die verborgene Abhängigkeit

Ein Scanner kann Ihnen mitteilen, dass eine CVE auf einem Server existiert. Er kann Ihnen nicht sagen, ob der Server einen kritischen Zahlungsprozess unterstützt, besondere Kategorien personenbezogener Daten speichert, mit einem Abwicklungsanbieter verbunden ist oder zur Außerbetriebnahme vorgesehen ist.

Dieser Kontext ergibt sich aus Asset-Management, Datenklassifizierung, Lieferanteninventar und Risikobeurteilung.

ISO/IEC 27001:2022 Anhang-A-Maßnahme 8.8, Management technischer Schwachstellen, ist zentral, funktioniert aber nicht isoliert. Die Maßnahme hängt stark von Konfigurationsmanagement, Änderungsmanagement, Lieferantenüberwachung, Cloud-Governance, Protokollierung, Überwachung und Risikobehandlung ab.

NIST CSF 2.0 beschreibt dasselbe Problem in Ergebnislogik. Die GOVERN-Funktion erwartet, dass rechtliche, regulatorische und vertragliche Cybersicherheitsanforderungen verstanden und gesteuert werden, Risikobereitschaft und -toleranz dokumentiert sind, Rollen und Ressourcen zugewiesen werden und Cybersicherheitsrichtlinien festgelegt, angewendet, überprüft und aktualisiert werden. IDENTIFY-Ergebnisse umfassen Inventare für Hardware, Software, Services, Systeme, Daten und Lebenszyklen sowie Schwachstellenidentifizierung, Risikoanalyse, Ausnahmemanagement und Prozesse zur Offenlegung von Schwachstellen.

In Annas Dienstagmorgen-Szenario lautet die erste technische Frage: „Wo befindet sich die verwundbare Komponente?“ Die erste Governance-Frage lautet: „Welchen Service und welches Risiko betrifft sie?“

Der Zenith Blueprint, Phase Risikomanagement, Schritt 13: Risikobehandlungsplanung und Erklärung zur Anwendbarkeit, adressiert dies, indem Risiken mit Kontrollen, Verantwortlichen und Zeitplänen verknüpft werden:

Weisen Sie außerdem jeder Maßnahme einen Verantwortlichen und einen Zeitplan zu (möglicherweise in einer separaten Spalte oder in den Kommentaren). Beispiel: „Verantwortlicher: IT-Manager, Zeitplan: bis Q3 2025.“ Dadurch wird daraus ein echter Plan.

Genau das erfordert Schwachstellenbehebung. Eine Feststellung ohne Verantwortlichen wird zu Backlog-Rauschen. Eine Feststellung mit Verantwortlichem, Zeitplan, Risikobehandlungsentscheidung und Nachweispfad wird zu einer auditierbaren Kontrolle.

Wie Zenith Controls die Kontrollbeziehungen abbildet

Zenith Controls behandelt ISO/IEC 27002:2022 Maßnahme 8.8, Management technischer Schwachstellen, als präventive Kontrolle zur Unterstützung von Vertraulichkeit, Integrität und Verfügbarkeit. Sie ist mit den Cybersicherheitskonzepten Identify und Protect, der operativen Fähigkeit für Bedrohungs- und Schwachstellenmanagement sowie den Sicherheitsdomänen Governance, Ökosystem, Schutz und Verteidigung verbunden.

Das ist wichtig, weil SLAs zur Behebung nicht nur ein Schutzmechanismus sind. Sie sind auch ein Governance-Mechanismus und ein Ökosystemmechanismus. Ihre Exposition wird durch Lieferanten, Cloud-Plattformen, Managed Services, Open-Source-Komponenten und aus dem Internet erreichbare Abhängigkeiten geprägt.

Zenith Controls ordnet 8.8 mehreren unterstützenden Kontrollen zu:

Zenith Controls verknüpft Schwachstellenmanagement außerdem mit ISO/IEC 27005:2024, insbesondere mit der Identifizierung von Schwachstellen und Risikoszenarien zu ungepatchten Systemen. Dies stärkt das Argument, dass Patch-Fristen risikobasiert und nicht willkürlich sein sollten. Zudem wird Lieferantenüberwachung mit ISO/IEC 27036-4:2016 für Sicherheitsniveaus in Cloud-Servicevereinbarungen und mit ISO/IEC 20000-1:2018 für Servicebereitstellungsplanung und Änderungsmanagement verbunden.

Diese standardübergreifende Struktur ist im Audit relevant. Wenn eine Organisation sagt: „Kritische Schwachstellen werden innerhalb von 72 Stunden gepatcht“, wird der Auditor prüfen, ob diese Aussage durch Risikobeurteilung, Asset-Klassifizierung, Lieferantenverpflichtungen, Änderungsaufzeichnungen und Überwachungsnachweise gestützt wird.

NIS2-Cyberhygiene: von Schwachstellenbehandlung zu Korrekturmaßnahmen

NIS2 Artikel 21 verlangt einen Allgefahrenansatz für Netz- und Informationssysteme. Für SLAs zur Schwachstellenbehebung sind mehrere Elemente aus Artikel 21 unmittelbar relevant:

• Risikoanalyse und Sicherheitsrichtlinien für Informationssysteme
• Behandlung von Sicherheitsvorfällen
• Aufrechterhaltung des Geschäftsbetriebs und Krisenmanagement
• Lieferkettensicherheit
• Sichere Beschaffung, Entwicklung und Wartung, einschließlich Schwachstellenbehandlung und Offenlegung
• Verfahren zur Bewertung der Wirksamkeit der Cybersicherheit
• Grundlegende Cyberhygiene und Schulung
• Zugriffskontrolle und Asset-Management
• Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung, soweit angemessen

NIS2 Artikel 20 macht Leitungsorgane dafür rechenschaftspflichtig, Maßnahmen zum Cybersicherheitsrisikomanagement zu genehmigen und zu überwachen. Das bedeutet, dass Kennzahlen zur Schwachstellenbehebung nicht nur in einem Engineering-Dashboard verbleiben dürfen. Sie sollten in Managementberichten, Unterlagen für Risikoausschüsse oder Aufzeichnungen zur ISMS-Managementbewertung erscheinen.

Artikel 21 erwartet außerdem, dass Einrichtungen, die eine Nichteinhaltung erforderlicher Maßnahmen feststellen, ohne unangemessene Verzögerung Korrekturmaßnahmen ergreifen. Diese Formulierung ist wesentlich. Wenn Ihr Dashboard überfällige kritische Schwachstellen zeigt, dürfen die Nachweise der Einhaltung nicht bei „wir wissen davon“ enden. Sie müssen Eskalation, Risikoüberprüfung, Sichtbarkeit für das Management, Korrekturmaßnahmen und Neubewertung zeigen.

NIS2 Artikel 23 ergänzt eine weitere Dimension. Wenn die Ausnutzung einer ungepatchten Schwachstelle eine schwerwiegende Betriebsstörung, einen finanziellen Verlust oder Schäden für andere Personen verursacht oder verursachen kann, kann daraus ein erheblicher Vorfall werden. Der Meldelebenszyklus umfasst eine Frühwarnung innerhalb von 24 Stunden nach Kenntnis des erheblichen Vorfalls, eine Vorfallmeldung innerhalb von 72 Stunden, Zwischenberichte auf Anforderung und einen Abschlussbericht innerhalb eines Monats nach der Vorfallmeldung. Dieser Abschlussbericht sollte Schweregrad, Auswirkungen, wahrscheinliche Ursache, Minderungsmaßnahmen und gegebenenfalls grenzüberschreitende Auswirkungen enthalten.

Der SLA-Prozess muss daher mit der Vorfallreaktion verbunden sein. Eine kritische Schwachstelle mit Nachweisen aktiver Ausnutzung muss Sicherheits-Triage, Überwachung, Beweissicherung und eine Bewertung der Meldepflicht auslösen, nicht nur ein routinemäßiges Patch-Ticket.

DORA-IKT-Risiko: Behebungsfristen als Resilienznachweis

Für Finanzunternehmen gilt DORA seit dem 17. Januar 2025 und schafft einheitliche Anforderungen an IKT-Risikomanagement, Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operationalen Resilienz, Informationsaustausch und Management von IKT-Drittparteienrisiken. DORA gilt als sektorspezifischer EU-Rechtsakt für erfasste Finanzunternehmen, die nach nationalen NIS2-Regeln identifiziert werden.

Das Betriebsmodell von DORA ähnelt einem integrierten ISMS. Artikel 5 und 6 verlangen Governance, Richtlinien, Verfahren, Werkzeuge, jährliche oder periodische Überprüfung, Audit, Behebung kritischer Audit-Feststellungen und eine Strategie für digitale operationale Resilienz. Artikel 8 verlangt die Identifizierung und Inventarisierung von IKT-unterstützten Geschäftsfunktionen, Informations-Assets, IKT-Assets, Abhängigkeiten, Drittparteiprozessen und Risiken aus Legacy-IKT. Artikel 9 verlangt Schutz- und Präventionskontrollen, einschließlich Patching und Änderungsmanagement. Artikel 11 und 12 verlangen Kontinuität, Reaktion, Wiederherstellung, Backup, Wiederanlauf und Wiederherstellungsziele.

DORA Artikel 17 bis 19 verlangen einen Prozess für das Management IKT-bezogener Vorfälle, der sichere Betriebsabläufe erkennt, steuert, aufzeichnet, klassifiziert, eskaliert, meldet, kommuniziert, Ursachen analysiert und die Wiederherstellung unterstützt. Artikel 24 bis 26 verlangen Tests der digitalen operationalen Resilienz, einschließlich angemessener Tests von IKT-Werkzeugen und -Systemen, Schwachstellenbewertungen, Netzwerksicherheitsbewertungen, Gap-Analysen, Quellcodeprüfungen soweit möglich, Penetrationstests und bedrohungsgeleitete Penetrationstests für bestimmte Finanzunternehmen. Artikel 28 und 30 verlangen Management von IKT-Drittparteienrisiken, Register für IKT-Serviceverträge, gebotene Sorgfalt, Audit- und Inspektionsrechte, Service Levels, Unterstützung des Anbieters bei Vorfällen, Kündigungsrechte und Exit-Regelungen.

Für SLAs zur Behebung verändert DORA die Nachweiserwartungen in drei Punkten.

Erstens müssen Schwachstellenfeststellungen aus Tests in einen priorisierten Behebungsprozess einfließen. Ein Scanbericht reicht nicht aus.

Zweitens muss die Behebung kritischer Feststellungen über Governance und Audit nachverfolgt werden. DORA erwartet bei Nicht-Kleinstunternehmen die formale Behebung kritischer Audit-Feststellungen.

Drittens müssen IKT-Drittdienstleister an messbare Verpflichtungen gebunden werden. Wenn Ihr Cloud-, SaaS- oder MSP-Anbieter das Patch-Fenster kontrolliert, müssen Ihr Vertrag und Register zeigen, wie dessen Behebungsfristen Ihre Resilienzverpflichtungen unterstützen.

Die Richtlinie zum Schwachstellen- und Patch-Management adressiert dies direkt:

Patching durch Dritte und SaaS-Risikoaufsicht 6.6.1 Alle Drittparteiensysteme (SaaS, PaaS, durch MSP verwaltet) müssen angemessene Kontrollen für Schwachstellen- und Patch-Management nachweisen. 6.6.2 Lieferanten-SLAs müssen Behebungsfristen enthalten, die den intern definierten, nach Kritikalität gestaffelten Schwellenwerten entsprechen.

Diese Klausel ist häufig die fehlende Brücke zwischen internen ISO-Nachweisen und der DORA-Lieferantenaufsicht.

GDPR: wenn Patch-Verzögerungen zu Versäumnissen bei der Rechenschaftspflicht für personenbezogene Daten werden

GDPR ist kein Standard für Schwachstellenmanagement, verändert aber die Folgen eines Patch-Versagens.

GDPR Artikel 5 verlangt, dass personenbezogene Daten sicher verarbeitet werden, und verlangt vom Verantwortlichen, die Einhaltung nachweisen zu können. Artikel 32 verlangt geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Sicherheitsniveau zu gewährleisten. Wenn ungepatchte Systeme personenbezogene Daten verarbeiten, insbesondere Identitätsdaten, Finanzdaten, biometrische Daten, Gesundheitsdaten, Beschäftigtendaten oder KYC-Informationen, werden SLAs zur Behebung Teil der Rechenschaftspflicht für die Sicherheit der Verarbeitung.

Ein verzögerter Patch kann vertretbar sein, wenn das Risiko bewertet, kompensierende Kontrollen angewendet und das Restrisiko von der richtigen Person akzeptiert wurde. Deutlich schwerer zu verteidigen ist dies, wenn die Schwachstelle überfällig, aus dem Internet erreichbar und ohne Verantwortlichen war.

Zenith Controls ordnet Schwachstellenmanagement GDPR Artikel 32 und 5(1)(f) zu, weil zeitnahes Patching Risiken für Vertraulichkeit und Integrität personenbezogener Daten reduziert. Außerdem wird Änderungsmanagement GDPR Artikel 24 und Artikel 32 zugeordnet, weil Änderungen an Systemen, die personenbezogene Daten verarbeiten, risikobewertet, genehmigt, dokumentiert und überprüft werden sollten.

Die Compliance-Lehre ist eindeutig: Wenn personenbezogene Daten betroffen sind, sollten Ihre Patch-Nachweise den Datenkontext enthalten. Auditoren und Aufsichtsbehörden werden nicht nur fragen: „Wurde gepatcht?“, sondern auch: „Welche Daten waren wie lange einem Risiko ausgesetzt und welche Kontrollen haben dieses Risiko reduziert?“

Ein praktischer Clarysec-Workflow für auditbereite SLA-Nachweise

Ein reifer Prozess zur Schwachstellenbehebung beginnt nicht erst, wenn ein Auditor Aufzeichnungen anfordert. Er ist so gestaltet, dass er jeden Monat Aufzeichnungen erzeugt.

Schritt 1: SLA-Richtlinie genehmigen

Beginnen Sie mit der Richtlinie zum Schwachstellen- und Patch-Management oder der Richtlinie zum Schwachstellen- und Patch-Management für KMU, abhängig von Ihrem Betriebsmodell. Passen Sie SLA-Schwellenwerte an Ihre Risikobereitschaft, Ihren regulatorischen Geltungsbereich, die Servicekritikalität, Datensensitivität und technischen Einschränkungen an. Stellen Sie die Genehmigung durch den CISO, den Risikoausschuss oder das Leitungsorgan sicher.

Verwenden Sie in Unternehmensumgebungen CVSS, Asset-Kritikalität, Ausnutzbarkeit, Internetexposition, Datensensitivität und geschäftliche Auswirkungen. Für KMU sollte das Modell einfach, aber eindeutig bleiben: kritische Patches innerhalb von drei Tagen, sonstige Patches innerhalb von 30 Tagen, sofern keine gültige Ausnahme besteht.

Schritt 2: Assets Verantwortlichen und kritischen Services zuordnen

Jede Schwachstellenfeststellung sollte auf Folgendes auflösbar sein:

• Asset-Name und eindeutige Kennung
• Geschäftsservice oder Anwendung
• Systemverantwortlicher
• Technischer Verantwortlicher
• Datenklassifizierung
• Internetexposition
• Lieferantenabhängigkeit, falls zutreffend
• Kritikalität der unterstützten Funktion

Dies unterstützt Risikoverantwortung nach ISO/IEC 27001:2022, NIS2-Asset-Management, DORA-Inventare für IKT-Assets und Abhängigkeiten sowie NIST CSF IDENTIFY-Ergebnisse.

Schritt 3: Schwachstelle triagieren

Erstellen Sie für jede Feststellung oder zusammengefasste Gruppe von Feststellungen ein Ticket. Fügen Sie CVSS-Wert, Quellscanner, betroffenes Asset, Ausnutzungsstatus, Bedrohungsinformationen, geschäftliche Kritikalität und das erforderliche SLA hinzu. Wenn eine Ausnutzung vermutet wird, verknüpfen Sie das Ticket mit einer Vorfallsbewertung.

Schritt 4: Umsetzung über Änderungsmanagement

Patching ist eine Änderung. Verwenden Sie Standardänderungen für routinemäßige Aktualisierungen und Notfalländerungen für kritische, ausgenutzte Schwachstellen. Fügen Sie Testnachweise, Genehmigung, Implementierungszeitstempel, Rollback-Plan und Validierung nach der Änderung hinzu.

Dies entspricht der in Zenith Controls beschriebenen Beziehung zwischen 8.8 und 8.32, wonach das Einspielen von Patches über Änderungsmanagement gesteuert wird, um Dringlichkeit und Betriebsstabilität auszubalancieren.

Schritt 5: Abschluss validieren

Schließen Sie Tickets nicht allein auf Grundlage von „Patch installiert“. Verlangen Sie eine Validierung durch erneutes Scannen, Versionsbestätigung, Konfigurationsprüfung oder Bestätigung kompensierender Kontrollen. Wenn der Patch nicht angewendet werden kann, ist eine Ausnahme zu eröffnen.

Schritt 6: Ausnahmen und Restrisiko aufzeichnen

Die Richtlinie zum Schwachstellen- und Patch-Management definiert die erforderlichen Inhalte eines Ausnahmeantrags:

Ausnahmeanträge müssen enthalten: 7.2.1 Geschäftliche Begründung für die Verzögerung oder Nichtbehebung 7.2.2 Risikobeurteilung (basierend auf CVSS, Asset-Kritikalität, Bedrohungsinformationen) 7.2.3 Vorgeschlagene kompensierende Kontrollen 7.2.4 Zeitplan für Behebung oder Neubewertung

Sie definiert außerdem Genehmigung und Überprüfung:

Ausnahmen müssen vom CISO oder einem delegierten Risikoausschuss genehmigt und im ISMS-Ausnahmeregister aufgezeichnet werden; das Überprüfungsintervall darf 90 Tage nicht überschreiten.

Dieses Ausnahmeregister wird zu einem wesentlichen Nachweis für ISO/IEC 27001:2022 Abschnitt 6.1.3 Risikobehandlung und Restrisikoakzeptanz sowie für die Managementbewertung.

Diese Aufzeichnung zeigt, dass die Organisation die Schwachstelle nicht ignoriert hat. Sie hat das Risiko bewertet, kompensierende Kontrollen angewendet, das Restrisiko genehmigt und ein Überprüfungsdatum festgelegt.

Schritt 7: Monatliches Nachweispaket erstellen

Ihr monatliches Nachweispaket zur Schwachstellenbehebung sollte Folgendes enthalten:

Für KMU kann der Nachweisumfang schlanker sein, muss aber konsistent bleiben. Die Richtlinie zum Schwachstellen- und Patch-Management für KMU verlangt Patch-Protokolle mit Nachvollziehbarkeit:

Protokolle müssen den Gerätenamen, die eingespielte Aktualisierung, das Patch-Datum und den Grund für jede Verzögerung enthalten

Diese einzelne Klausel ist für Audits besonders wertvoll. Sie macht aus Patching eine Aufzeichnung statt einer Behauptung.

Lieferanten-Patching: Der Vertrag muss zu Ihrem SLA passen

Wenn ein MSP, SaaS-Anbieter, PaaS-Anbieter oder Cloud-Service-Provider die Patch-Bereitstellung kontrolliert, sind interne SLAs wirkungslos, sofern die Lieferantenverpflichtungen nicht zu ihnen passen.

Die Richtlinie zur Sicherheit von Lieferanten und Drittparteien für KMU enthält Informationssicherheitsverpflichtungen als Governance-Anforderung. Für die Schwachstellenbehebung sollten diese Verpflichtungen in messbare Vertragssprache überführt werden:

• Meldefenster für kritische Schwachstellen
• Behebungsfristen für kritische, hohe, mittlere und niedrige Schwachstellen
• Prozess für Notfalländerungen
• Anforderungen an die Kundengenehmigung bei Ausfallzeiten
• Nachweisformat für den Patch-Abschluss
• Prozess zur Offenlegung von Schwachstellen
• Unterstützungspflichten bei Vorfällen
• Auditrechte oder Recht auf Erhalt von Assurance-Berichten
• Patch-Verpflichtungen von Unterauftragsverarbeitern oder Subunternehmern
• Exit- und Übergangsunterstützung für kritische Services

Der Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 20, Maßnahme 8.21 Sicherheit von Netzwerkdiensten, formuliert das Prinzip klar:

Wenn Services extern bereitgestellt werden, einschließlich ISPs, SD-WAN-Anbieter oder Private-Cloud-Anbieter, müssen Sicherheitsanforderungen in Verträgen und SLAs verankert werden. Dazu gehören Verfügbarkeitszusagen, Reaktionszeiten bei Vorfällen, Verpflichtungen zum Patchen oder zur Minderung von Schwachstellen sowie klare Grenzen für den Datenumgang. Sie sollten niemals annehmen, dass ein Anbieter Ihre Erwartungen erfüllt, wenn dies nicht schriftlich, messbar und auditierbar festgelegt ist.

DORA macht dies für Finanzunternehmen besonders wichtig. IKT-Drittparteienvereinbarungen müssen Service Levels, Unterstützung des Anbieters bei IKT-Vorfällen, Zugriff auf und Wiederherstellung von Daten, Zusammenarbeit mit Behörden, Kündigungsrechte und stärkere Regelungen für kritische oder wichtige Funktionen enthalten, einschließlich Überwachung, Auditrechte, Notfallpläne und Sicherheitsmaßnahmen.

NIST CSF 2.0 formuliert dies über Ergebnisse zum Lieferkettenrisiko ebenso: Lieferanten sollten bekannt, nach Kritikalität priorisiert, vor Beauftragung bewertet, durch vertragliche Anforderungen gesteuert, während der gesamten Beziehung überwacht, in die Vorfallsplanung einbezogen und bei Beendigung gemanagt werden.

Was Auditoren tatsächlich fragen werden

Das Auditgespräch ändert sich je nach Hintergrund des Auditors.

Ein ISO/IEC 27001:2022-Auditor beginnt mit dem ISMS. Er wird prüfen, ob Schwachstellenmanagement in der Erklärung zur Anwendbarkeit enthalten ist, ob die Risikobeurteilung ungepatchte Systeme als Risiko identifiziert, ob Risikobehandlungspläne Verantwortliche und Zeitpläne enthalten, ob Anhang-A-Maßnahme 8.8 implementiert ist, ob Nachweise aufbewahrt werden und ob internes Audit und Managementbewertung die Leistung bewerten.

Der Zenith Blueprint, Phase Kontrollen in der Praxis, Schritt 19, macht die Auditerwartung ausdrücklich:

Dies ist eine hochpriorisierte Kontrolle für Auditoren, und sie werden in der Regel tief einsteigen. Rechnen Sie mit Fragen dazu, wie häufig Systeme gepatcht werden, welchem Prozess Sie folgen, wenn ein Zero-Day angekündigt wird, und welche Systeme am schwierigsten zu patchen sind.

Er fährt mit praktischen Nachweiserwartungen fort:

Auditoren werden wahrscheinlich Ergebnisse von Schwachstellenscans anfordern. Wenn Tools wie Nessus, OpenVAS oder Qualys verwendet werden, exportieren Sie einen Bericht, der kürzlich erkannte Schwachstellen und deren Behandlung zeigt. Idealerweise sollte dieser Risikobewertungen (CVSS) und Behebungsfristen enthalten.

Ein NIS2-fokussierter Auditor oder eine zuständige Behörde wird auf Genehmigung durch das Leitungsorgan, Verhältnismäßigkeit, Cyberhygiene, Schwachstellenbehandlung, Lieferantensicherheit, Behandlung von Sicherheitsvorfällen, Wirksamkeitsbewertung, Korrekturmaßnahmen ohne unangemessene Verzögerung und Aufzeichnungen zu Meldeentscheidungen achten, wenn Ausnutzung erhebliche Auswirkungen verursacht hat.

Eine DORA-Aufsicht wird prüfen, ob Schwachstellenfeststellungen in IKT-Risikomanagement, Tests der digitalen operationalen Resilienz, Vorfallklassifizierung, Ursachenanalyse, Drittparteienregister, vertragliche Verpflichtungen, Auditrechte und Behebung kritischer Feststellungen integriert sind.

Ein NIST CSF-Assessor wird die Überprüfung voraussichtlich entlang von GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND und RECOVER strukturieren. Er wird fragen, ob rechtliche und vertragliche Anforderungen verstanden werden, ob Risikotoleranz dokumentiert ist, ob Schwachstellen identifiziert und priorisiert werden, ob Ausnahmen gesteuert werden, ob Überwachung Ausnutzung erkennt und ob Reaktions- und Wiederherstellungsmaßnahmen koordiniert sind.

Ein Auditor nach COBIT 2019 oder im ISACA-Stil wird sich auf Governance-Ziele, Prozessfähigkeit, Managementpraktiken, Kennzahlen, Verantwortung, Kontrolldesign, Kontrollbetrieb und ausreichende Nachweise konzentrieren. Er wird fragen, ob Schwachstellenbehebung wiederholbar, gemessen, eskaliert, verbessert und an Unternehmenszielen sowie Risikobereitschaft ausgerichtet ist.

Eskalation und Kennzahlen: Wie Sie belegen, dass das SLA gesteuert wird

Ein SLA ohne Eskalation ist nur ein Zielwert. Ein belastbares Programm zur Schwachstellenbehebung benötigt Eskalation vor dem Verstoß, beim Verstoß und nach wiederholtem Versagen.

Clarysec empfiehlt ein vierstufiges Eskalationsmodell:

1. Operative Eskalation: Ticketverantwortlicher und technischer Leiter werden vor einem Verstoß benachrichtigt.
2. Risikoeskalation: Asset-Verantwortlicher und Risikoverantwortlicher prüfen die Auswirkungen, wenn ein Verstoß wahrscheinlich ist.
3. Eskalation an die Sicherheits-Governance: CISO oder Risikoausschuss genehmigt eine Ausnahme oder Notfallmaßnahme.
4. Managementeskalation: Wiederholte oder kritische SLA-Verstöße werden mit Korrekturmaßnahmen in der Managementbewertung berichtet.

Die Richtlinie zum Schwachstellen- und Patch-Management verstärkt diese Auditerwartung:

Periodische Audits müssen durch internes Audit oder eine unabhängige dritte Partei durchgeführt werden, um zu überprüfen: 5.6.1 Einhaltung der SLAs 5.6.2 Nachweise risikobasierter Priorisierung 5.6.3 Wirksamkeit der bereitgestellten Patches 5.6.4 Kontrollen über ungepatchte Systeme

Kennzahlen sollten Entscheidungen unterstützen, nicht Dashboards dekorieren. Zu den stärksten Kennzahlen für 2026 gehören:

• Prozentsatz der Einhaltung kritischer SLAs
• Prozentsatz der Einhaltung hoher SLAs
• Mittlere Zeit bis zur Triage
• Mittlere Zeit bis zur Behebung nach Asset-Klasse
• Anzahl überfälliger kritischer Schwachstellen
• Anzahl akzeptierter Ausnahmen nach Alter
• Ausnahmen über 90 Tage
• Anzahl aus dem Internet erreichbarer kritischer Expositionen
• SLA-Verstöße von Lieferanten
• Nach Validierung wiedereröffnete Schwachstellen
• Notfalländerungen aufgrund ausgenutzter Schwachstellen
• Patch-Fehler nach Plattform oder Geschäftseinheit

Verknüpfen Sie diese Kennzahlen mit ISO/IEC 27001:2022 Abschnitt 9.3 Managementbewertung, DORA-Governance-Berichterstattung und NIS2-Managementaufsicht. Für NIST CSF 2.0 verwenden Sie sie zur Aktualisierung von Ist- und Zielprofilen, Gap-Analyse und Maßnahmenplänen.

Die Clarysec-Checkliste für SLAs zur Behebung

Verwenden Sie diese Checkliste, um Ihr aktuelles Programm zu bewerten:

• Gibt es eine genehmigte Richtlinie zum Schwachstellen- und Patch-Management?
• Sind SLAs zur Behebung nach Schweregrad und geschäftlicher Kritikalität definiert?
• Werden aus dem Internet erreichbare und ausgenutzte Schwachstellen beschleunigt behandelt?
• Sind Assets Verantwortlichen, Services, Daten und Lieferanten zugeordnet?
• Werden Scanner-Feststellungen in zugewiesene Tickets überführt?
• Werden Patches über Änderungsmanagement umgesetzt?
• Werden Notfalländerungen dokumentiert und überprüft?
• Werden Behebungsergebnisse durch erneute Scans oder Versionsprüfungen validiert?
• Werden Ausnahmen risikobeurteilt, genehmigt und mindestens alle 90 Tage überprüft?
• Sind kompensierende Kontrollen für nicht patchbare Systeme dokumentiert?
• Sind Lieferantenverträge an interne Behebungsschwellen angepasst?
• Sind Patch-Protokolle vollständig genug, um zu belegen, was wann passiert ist?
• Werden SLA-Verstöße eskaliert und korrigiert?
• Werden Kennzahlen vom Management überprüft?
• Werden Vorfälle und Bewertungen zu Datenschutzverletzungen ausgelöst, wenn eine Ausnutzung vermutet wird?

Wenn mehrere Antworten „nein“ lauten, ist das Problem nicht das Werkzeug. Es ist das Kontrolldesign.

Nächste Schritte: Patch-Fristen in auditbereite Resilienz umwandeln

SLAs zur Schwachstellenbehebung müssen 2026 mehr leisten, als ein Scanner-Dashboard zufriedenzustellen. Sie müssen nachweisen, dass Ihre Organisation Exposition identifizieren, Risiken priorisieren, innerhalb genehmigter Fristen handeln, Ausnahmen steuern, Lieferanten überwachen und Entscheidungen über die Auditerwartungen von ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019 hinweg belegen kann.

Clarysec kann Sie dabei unterstützen, von fragmentierten Patch-Tickets zu einem integrierten, nachweisgestützten Programm zur Schwachstellenbehebung zu wechseln, und zwar mit:

• Richtlinie zum Schwachstellen- und Patch-Management
• Richtlinie zum Schwachstellen- und Patch-Management für KMU
• Richtlinie zur Sicherheit von Lieferanten und Drittparteien für KMU
• Zenith Blueprint: 30-Schritte-Roadmap für Auditoren
• Zenith Controls: Der Cross-Compliance-Leitfaden

Beginnen Sie mit einem Hochrisiko-Service. Ordnen Sie dessen Assets, Lieferanten, Schwachstellen, Tickets, Änderungen, Ausnahmen und Nachweise zu. Führen Sie anschließend die Auditfragen dagegen aus. Wenn Sie das SLA von der Erkennung bis zum Abschluss nicht belegen können, ist dies Ihr erstes Behebungsprojekt.

Das Ziel ist nicht perfektes Patching. Das Ziel ist gesteuerte, risikobasierte, messbare und auditierbare Behebung. Laden Sie die Clarysec-Richtlinienvorlagen herunter, führen Sie eine gezielte Gap-Analyse durch oder buchen Sie eine Clarysec-Demo, um Schwachstellenbehebung von Auditdruck in operative Resilienz zu verwandeln.