Muster ✴️ Security Level Agreement (SecLA) Schwachstellen- und Patch‑Management

In vielen mittelständischen Unternehmen wird die IT-Sicherheit teilweise oder vollständig an externe Dienstleister ausgelagert.

Doch was passiert wenn der Dienstleister kritische Sicherheitslücken nicht rechtzeitig schließt? Wer haftet im Schadensfall sowie wie lässt sich nachweisen dass alle Beteiligten ihre Pflichten erfüllt haben?

Spätestens mit dem Inkrafttreten des NIS2-Umsetzungsgesetzes am 6. Dezember 2025 ist klar geworden: Die Geschäftsleitung trägt die persönliche Verantwortung für die Cybersicherheit des Unternehmens. Diese Verantwortung lässt sich nicht einfach auf einen IT-Dienstleister abwälzen. Vielmehr muss die Geschäftsführung sicherstellen dass externe Partner messbare Sicherheitsstandards einhalten sowie deren Einhaltung aktiv überwachen.

Warum reichen normale SLAs nicht aus?

Klassische Service Level Agreements (SLAs) regeln typischerweise Verfügbarkeit sowie Reaktionszeiten bei Störungen. Ein typischer SLA könnte festlegen dass der Dienstleister innerhalb von 4 Stunden auf ein Ticket reagiert oder dass die Systemverfügbarkeit 99,5% betragen muss. Diese Kennzahlen sind für den Betrieb wichtig, decken aber nur einen kleinen Ausschnitt der IT-Sicherheit ab.

Ein Security Level Agreement (SecLA) geht deutlich weiter. Es definiert konkrete sowie messbare Anforderungen für sicherheitskritische Prozesse wie:

• Wie schnell müssen kritische Sicherheitslücken geschlossen werden?

• Wer ist für das Monitoring von Schwachstellen verantwortlich?

• Welche Nachweise muss der Dienstleister erbringen?

• Was passiert bei wiederholten SLA-Verstößen?

Ohne ein professionelles SecLA fehlt Ihnen die vertragliche Grundlage um im Ernstfall nachzuweisen dass Sie Ihrer Sorgfaltspflicht nachgekommen sind. Im schlimmsten Fall haften Sie persönlich für Schäden die durch ungepatchte Systeme Ihres Dienstleisters entstanden sind.

Für wen ist ein SecLA relevant?

Ein SecLA zum Schwachstellen- sowie Patchmanagement ist insbesondere wichtig für:

• NIS-2-betroffene Einrichtungen die externe IT-Dienstleister beauftragen

• Unternehmen die unter die DSGVO fallen sowie personenbezogene Daten verarbeiten lassen

• Mittelständische Betriebe die ihre IT-Sicherheit an Managed Service Provider auslagern

• Organisationen mit kritischen Fachverfahren bei denen mehrere Ebenen (Betriebssystem, Middleware, Anwendung) von verschiedenen Parteien betreut werden

Was Sie in diesem Beitrag erwartet

Das folgende Muster-SecLA wurde auf Basis der Best-Practice-Empfehlungen von UP KRITIS sowie den Fachinformationen des LSI Bayern entwickelt. Es ist bewusst detailliert gehalten sowie deckt alle wesentlichen Aspekte eines professionellen Schwachstellen- sowie Patch-Management-Prozesses ab:

• Klare Definitionen von Begriffen wie Neutralisierung sowie Remediation

• Messbare Zeitvorgaben basierend auf CVSS-Scores

• Rollen sowie Verantwortlichkeiten (RACI-Matrix)

• Umgang mit Ausnahmen sowie Risikoakzeptanz

• Reporting sowie Audit-Anforderungen

• Eskalationsprozesse sowie optionale Service Credits

Sie können dieses Muster als Grundlage für Verhandlungen mit Ihrem IT-Dienstleister verwenden. Passen Sie die konkreten Zeitvorgaben sowie Rahmenbedingungen an Ihre spezifische Risikolage sowie Ihre Ressourcen an. Wichtig ist dass Sie die Anforderungen schriftlich festhalten sowie deren Einhaltung regelmäßig überprüfen.

 
Hinweis: Dieses Muster ersetzt keine individuelle Rechtsberatung. Lassen Sie wichtige Verträge vor Unterzeichnung durch einen auf IT-Recht spezialisierten Anwalt prüfen.


Quellen:

UP KRITIS: Best-Practice-Empfehlungen für Anforderungen an Lieferanten zur Gewährleistung der Informationssicherheit in Kritischen Infrastrukturen (Stand: November 2021). Abrufdatum: 27.12.2025
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/UPK/upk-anforderungen-lieferanten.pdf?__blob=publicationFile&v=14

LSI Bayern: Fachinformation T#08 Patchmanagement, Version 1.0 vom 04.08.2021. Abrufdatum: 27.12.2025
https://www.lsi.bayern.de/mam/aktuelles/lsi-info_t08_patchmanagement.pdf
 

---

Zwischen [Kunde] („Auftraggeber“) und [Dienstleister] („Auftragnehmer“)

Version: [v1.0]

Datum: [TT.MM.2025]

Geltungsbeginn: [TT.MM.2025]

Laufzeit: [12] Monate,

Verlängerung um jeweils [12] Monate,

Kündigungsfrist [3] Monate zum Laufzeitende

0. Zweck und Einordnung

Dieses SecLA regelt die Arbeitsprozesse, Leistungskennzahlen und Nachweise für:

• Vulnerability Monitoring, Bewertung, Priorisierung

• Neutralisierung (Workaround/Mitigation)

• Remediation (Patch/Update/Hotfix/Config‑Change)

• Dokumentation und Reporting

• Ausnahmen/Risikoakzeptanz

Dieses SecLA ergänzt den Hauptvertrag. Bei Widerspruch gilt die Rangfolge: Hauptvertrag → SecLA → Leistungsbeschreibung.

1. Begriffe und Definitionen

Schwachstelle (Vulnerability): Eine durch Hersteller/Community bekannte oder identifizierte Sicherheitslücke in Hard-/Software oder Konfiguration.

Patch: Herstellerbereitgestellter Fix (inkl. Hotfix, Security Update, Firmware Update) oder vom Dienstleister bereitgestellter Fix im Rahmen seiner Leistungspflichten.

Neutralisierung (Mitigation/Workaround): Maßnahme, die eine Ausnutzung verhindert oder erheblich erschwert, z. B. Deaktivierung einer Funktion, Block‑Regel, Konfigurationsänderung, Isolierung, virtuelle Patches (WAF/IPS), temporäre Abschaltung eines Dienstes.

Remediation: Dauerhafte Behebung durch Patch/Update oder eine gleichwertige, dokumentierte technische Lösung.

CVSS‑Score: Einstufung der Schwere einer Schwachstelle anhand CVSS [Version festlegen: v3.1 oder v4.0]. Maßgeblich ist der höchste der folgenden Werte:

1. Hersteller-/CVE‑Score,

2. Score aus dem eingesetzten Scanner/Threat‑Intel,

3. durch Auftragnehmer dokumentierte Neubewertung (nur mit Begründung und Freigabe durch Auftraggeber).

Active Exploitation: Schwachstelle wird nachweislich aktiv ausgenutzt (z. B. Herstellerwarnung, CERT/Behördenwarnung, KEV‑ähnliche Listen, beobachtete IOC/Telemetry im Kundenumfeld).

In‑Scope Systeme: Alle in Anlage A gelisteten Assets/Services (Endpoints, Server, Netzwerkkomponenten, Cloud‑Workloads, relevante SaaS‑Konfigurationen), inkl. Eigentums-/Betriebsmodell (on‑prem, IaaS, PaaS).

2. Geltungsbereich

2.1 In‑Scope

• Betriebssysteme: [Windows, Linux, macOS …]

• Standard‑Applikationen: [Browser, Office, PDF‑Reader, Java, VPN‑Clients …]

• Server‑Applikationen: [Webserver, Datenbanken …]

• Virtualisierung/Hypervisor: [VMware/Hyper‑V …]

• Netzwerk/Edge: [Firewall, VPN‑Gateway, Switches …]

• MDM/UEM/Endpoint‑Management: [Intune/NinjaOne/…]

• Vulnerability Scanner: [Tenable/Qualys/Rapid7/Defender VM …]

2.2 Out‑of‑Scope (Beispiele)

• Eigenentwicklungen ohne Wartungsvertrag, sofern nicht gesondert beauftragt

• Systeme ohne Netzwerkverbindung, sofern nicht in Anlage A enthalten

• OT/ICS/Medizinprodukte nur nach gesonderter Leistungsbeschreibung (siehe Ausnahmen)

3. Rollen, Verantwortlichkeiten und RACI

3.1 Rollen

• Kunde – SecLA‑Owner: [Name/Rolle]

• Dienstleister – SecLA‑Owner: [Name/Rolle]

• Change Manager (Kunde): [Name/Rolle]

• Patch Service Manager (DL): [Name/Rolle]

• Security Incident Lead: [Kunde/DL je nach Vertrag]

3.2 RACI (Kurz)

Aktivität	Kunde	Dienstleister
Asset‑Inventar (Anlage A) pflegen	A/R	C
Schwachstellenmonitoring/Advisory Intake	C	A/R
Priorisierung nach CVSS & Exposure	C	A/R
Test/Pilot (wenn möglich)	A/R	R
Rollout/Deployment	C	A/R
Verifikation/Compliance‑Messung	C	A/R
Ausnahmegenehmigung/Risikoakzeptanz	A/R	C
Reporting & Evidenzen	C	A/R

A = Accountable, R = Responsible, C = Consulted

4. Prozessanforderungen

4.1 Schwachstellenmonitoring (Pflicht des Dienstleisters)

Der Dienstleister betreibt ein kontinuierliches Monitoring von:

• Herstelleradvisories (relevante Hersteller gemäß Anlage A)

• CVE‑Feeds/Threat‑Intel nach Branchenstandard

• Scannerergebnissen im Kundenumfeld (sofern vereinbart)

4.2 Triage & Zuordnung

Innerhalb der vereinbarten Reaktionszeiten (siehe SLAs) muss der Dienstleister:

• betroffene Assets identifizieren,

• Exposure bewerten (internet‑facing, privilegierter Zugang, laterale Bewegung, Auth‑Bypass, RCE etc.),

• Maßnahmenplan erstellen (Patch vs. Workaround),

• Change‑Ticket anlegen und mit Evidenzen versehen.

4.3 Change- und Wartungsfenster

• Standard‑Wartungsfenster: [z. B. Di/Do 20:00–23:00]

• Für kritische Sicherheitslagen kann der Dienstleister ein Emergency Change auslösen (siehe 6.4).

5. Service Level Objectives (SLO) und Service Level Agreements (SLA)

5.1 Messbeginn („Start des SLA‑Timers“)

Der SLA‑Timer startet zum frühesten Zeitpunkt von:

1. Eingang einer Hersteller-/CERT‑Warnung beim Dienstleister und bestätigter Betroffenheit (In‑Scope), oder

2. Scanner findet Schwachstelle auf In‑Scope Asset, oder

3. Kunde meldet Schwachstelle mit Nachweis der Betroffenheit.

Zeitstempel und Nachweis sind im Ticket zu dokumentieren.

5.2 Zielkennzahlen (KPIs)

• Patch‑Compliance je Kritikalität (in %)

• SLA‑Einhaltung (in %)

• MTTA/MTTR für Security‑Changes

• Backlog alter Schwachstellen (Anzahl/Alter)

6. Verbindliche Fristen: Neutralisierung und Remediation

6.1 SLA 1 – Neutralisierung (Workaround/Mitigation)

Der Dienstleister verpflichtet sich zu folgenden Fristen zur Neutralisierung (mindestens eine wirksame Maßnahme, die Ausnutzung verhindert/erheblich erschwert):

Bedrohungsstufe (CVSS)	Neutralisierung spätestens innerhalb von
Kritisch (9.0–10.0)	3 Stunden
Hoch (7.0–8.9)	3 Tagen
Mittel (4.0–6.9)	1 Monat
Niedrig (0.1–3.9)	3 Monaten

 
Hinweis zur Erfüllung: Neutralisierung kann durch Patch oder Workaround erfolgen. Ist ein Patch verfügbar, ist eine Patch‑Strategie im Ticket zu dokumentieren.

Hinweis zur Kalibrierung der Fristen: Die oben genannten Zeitvorgaben basieren auf den Best-Practice-Empfehlungen von UP KRITIS für KRITIS-Betreiber sowie professionelle IT-Dienstleister. 

ℹ️ Sie stellen einen Idealzustand dar.

Für die konkrete Vertragsgestaltung sollten Sie die Fristen risikobasiert sowie an den Fähigkeiten Ihres Dienstleisters ausrichten:

Faktoren für die Anpassung:

- Verfügbarkeit (24/7 vs. Geschäftszeiten)
- Teamgröße sowie Expertise des Dienstleisters
- Kritikalität Ihrer Systeme (internet-facing vs. intern)
- Ihr Restrisiko-Appetit
- Kompensationsfähigkeit (z. B. eigene Firewall-Teams für schnelle Workarounds)

Beispiel für angepasste Fristen (mittelständischer Dienstleister ohne 24/7):

- Kritisch: 24 Stunden (Neutralisierung), 5 Tage (Remediation)
- Hoch: 5 Tage (Neutralisierung), 14 Tage (Remediation)

Wichtig: Die Fristen müssen für beide Seiten erreichbar sein. Ein SLA das strukturell nicht eingehalten werden kann wird zum wertlosen Papier sowie gefährdet im Schadensfall Ihre Nachweisführung.
 

6.2 SLA 2 – Remediation (Patch/Update) für kritische und hohe Risiken

Für die vollständige Installation von Patches/Updates gelten (sofern Patch verfügbar und technisch installierbar, siehe Ausnahmen):

Bedrohungsstufe	Remediation (Patch vollständig ausgerollt)
Kritisch (CVSS 9.0–10.0)	spätestens 3 Tage
Hoch (CVSS 7.0–8.9)	spätestens 5 Tage

Für Mittel/Niedrig wird vereinbart:

• Mittel: [z. B. 30 Tage]

• Niedrig: [z. B. 90 Tage](oder explizit „nach Wartungsplan“, wenn der Kunde dies so steuern will)

6.3 Verifikation (Pflicht)

Innerhalb von [24/48] Stunden nach Abschluss der Remediation liefert der Dienstleister Nachweise:

• Patch-/Versionstand je Asset (Report/Export),

• Ticketabschluss mit Zeitstempeln,

• ggf. Scanner‑Rescan (wenn vereinbart).

6.4 Sonderfall: Active Exploitation / Emergency

Bei Active Exploitation oder behördlicher/Hersteller‑Warnlage mit unmittelbarer Ausnutzbarkeit gilt:

• Sofortmaßnahmen unverzüglich (Containment/Workaround) nach Back‑up/Restore‑Fähigkeit, sofern erforderlich.

• Emergency‑Change darf außerhalb regulärer Wartungsfenster durchgeführt werden.

• Der Kunde benennt einen 24/7‑Freigabekontakt; wenn nicht erreichbar, gilt das im Hauptvertrag definierte Notfall‑Freigabeverfahren.

(Wenn Sie eine harte Zahl statt „unverzüglich“ möchten: ergänzen Sie z. B. „Initiale Containment‑Maßnahmen innerhalb von 2 Stunden“.)

7. Ausnahmen, Risikoakzeptanz und Nicht‑Patchbarkeit

7.1 Zulässige Ausnahmen (nur mit Dokumentation)

Eine Fristüberschreitung ist nur zulässig, wenn mindestens eine der Bedingungen erfüllt ist:

• Patch ist nicht verfügbar (Hersteller liefert keinen Fix),

• Patch ist verfügbar, aber nachweislich inkompatibel (Test belegt Regression/Produktionsrisiko),

• System ist OT/ICS/Legacy mit Herstellerbindung; Patch nur im Wartungsfenster des Herstellers möglich,

• technische Restriktion: Endpoint offline / keine Management‑Konnektivität (muss durch Kunde behoben werden).

7.2 Pflicht bei Ausnahmen

Bei Ausnahme muss der Dienstleister:

1. Neutralisierung gemäß SLA 1 sicherstellen (wenn technisch möglich),

2. Risiko/Rest‑Risiko beschreiben,

3. kompensierende Maßnahmen dokumentieren (Segmentierung, Abschottung, EDR‑Härtung etc.),

4. Re‑Plan (neuer Termin) setzen,

5. Risikoakzeptanz durch den Kunden einholen (Ticketfreigabe).

8. Reporting, Evidenzen, Audit

8.1 Regelreport (monatlich)

Der Dienstleister liefert monatlich:

• Patch‑Compliance nach Kritikalität,

• SLA‑Einhaltung (Neutralisierung/Remediation),

• Liste offener kritischer/hoher Findings inkl. Alter,

• durchgeführte Emergency‑Changes,

• Ausnahmen inkl. Risikoakzeptanzen.

8.2 Audit-Rechte

Der Kunde darf [quartalsweise] Stichproben durchführen (remote/on‑site), inkl. Einsicht in:

• Patch‑Reports,

• Change‑Tickets,

• Scanner‑Nachweise (falls vereinbart),

• Asset‑Inventar‑Abgleich Anlage A.

9. Eskalation, Service Credits und Sonderkündigungsrechte (optional aber praxiswirksam)

9.1 Eskalationsstufen

• Eskalation 1: SLA‑Verstoß kritisch/hoch → innerhalb 1 AT Management‑Call

• Eskalation 2: wiederholter SLA‑Verstoß (z. B. 2×/Quartal) → Root‑Cause‑Analyse + Maßnahmenplan

• Eskalation 3: systematischer Verstoß → Sonderkündigungsrecht / Vertragsstrafe (falls vereinbart)

9.2 Service Credits (Beispiel)

• Kritisch: pro SLA‑Verstoß [x]% Monatsfee für den betroffenen Service

• Hoch: pro SLA‑Verstoß [y]% MonatsfeeDeckelung: [z]% pro Monat

 
Zahlen sind Verhandlungssache; ohne ökonomische Konsequenz verlieren SLAs oft Wirkung. Die folgenden Werte dienen als Orientierung und sollten so kalibriert werden, dass sie für den Dienstleister wirtschaftlich spürbar sind:

Kritisch: pro SLA-Verstoß 15-25% der Monatsfee für den betroffenen Service
Hoch: pro SLA-Verstoß 10-15% der Monatsfee
Deckelung: maximal 50% der Monatsfee pro Monat

Alternative: Pauschale pro Verstoß (z. B. 500-2.000 EUR je nach Kritikalität)
Wichtig: Ohne wirtschaftlich relevante Konsequenzen verlieren SLAs ihre 

Steuerungswirkung. Die Höhe sollte sich am potenziellen Schaden sowie an der Auftragsgröße orientieren.
 

10. Anlagen (als Teil des SecLA)

• Anlage A: Asset‑Inventar / Scope‑Liste (Systeme, Owner, Kritikalität, Exposure, Wartungsfenster)

• Anlage B: Kontaktliste & 24/7‑Eskalation

• Anlage C: Tooling (UEM/Scanner), Zugriffskonzepte, Logging

• Anlage D: Change‑Prozess inkl. Emergency‑Change‑Flow

• Anlage E: Report‑Formate (CSV/PDF), Mindestinhalte, Aufbewahrungsfristen

11. Unterschriften

[Ort, Datum] [Kunde] ____________________ [Dienstleister] ____________________

Anpassungshinweise (damit es im Audit „hält“)

• SLA‑Startpunkt sauber definieren (sonst sind die Stunden faktisch nicht messbar).

• Neutralisierung ≠ Patch strikt trennen.

• Für OT/Legacy: Ausnahmen + kompensierende Maßnahmen verbindlich machen, sonst „Dauer‑Risikoakzeptanz“.

• Ohne Reporting/Evidenzpflicht ist SecLA kaum prüfbar.