SLA richtig lesen: Was Ihr IT-Dienstleister wirklich garantieren muss

Der oft unterschätzte Vertragstext, der im Ernstfall über Existenz entscheidet

Sie wechseln zu einem neuen Managed-IT-Anbieter. Der Vertriebler spricht von „24/7-Support”, „schneller Reaktion bei Störungen” und „hochverfügbarer Infrastruktur”. Das klingt gut. Aber was passiert, wenn der Server um 3 Uhr nachmittags ausfällt, ein Angreifer Ihre Datenbank verschlüsselt oder ein kritischer Service für acht Stunden stillsteht?

Genau dann zahlt sich die genaue Lektüre des Service Level Agreement (SLA) aus — oder ihr Fehlen. Ein SLA ist keine Werbeversprechen-Sammlung. Es ist die vertragliche Vereinbarung, die festlegt, wie schnell Ihr Dienstleister reagieren muss, welche Verfügbarkeit zugesichert wird und was passiert, wenn diese Werte nicht erreicht werden.

Für viele Mittelständler ist das SLA eine Blackbox. Es wird unterschrieben, ohne dass jemand genau gelesen hat, ob „Reaktionszeit 4 Stunden” bedeutet, dass innerhalb von vier Stunden ein Techniker dran sitzt — oder nur, dass Sie innerhalb dieser Zeit zurückgerufen bekommen. Im Schadensfall zeigt sich der Unterschied schmerzhaft: Ein falsch formuliertes SLA kann dazu führen, dass Sie zwar einen Anspruch haben, diesen aber nicht durchsetzen können.

Dieser Artikel erklärt, worauf Sie im SLA Ihres IT-Dienstleisters achten müssen — verständlich, konkret und ohne Juristen-Jargon. Wir zeigen, welche KPIs verbindlich definiert sein müssen, wie Reaktionszeiten gemessen werden und welche Sanktionen bei Nichteinhaltung greifen. Einen Überblick über unser Leistungsspektrum bietet der Bereich Managed IT.

Was ist ein SLA überhaupt? (und was nicht)

Ein Service Level Agreement (SLA) ist eine vertragliche Vereinbarung zwischen einem IT-Dienstleister und seinem Klienten über die Qualität der zu erbringenden Dienstleistung. Im deutschen Recht ist das SLA kein eigener Vertragstyp, sondern fast immer eine Anlage zum übergeordneten Managed-IT-, Wartungs- oder Cloud-Vertrag.

Ein SLA besteht aus vier Kernelementen:

1. Leistungsbeschreibung: Welche Services werden erbracht? (z.B. Server-Monitoring, Backup-Management, Patch-Administration)
2. **Messbare Kennzahlen **(KPIs): Wie wird Qualität quantifiziert? (z.B. 99,5 % monatliche Verfügbarkeit, max. 4 Stunden Reaktionszeit bei P3-Tickets)
3. Messmethode: Wann gilt ein Wert als erreicht oder verfehlt? (z.B. Verfügbarkeitsmessung alle 5 Minuten via Heartbeat-Check)
4. Sanktionsmechanismus: Was passiert bei Nichteinhaltung? (z.B. Service-Guthaben von 10 % des Monatspreises pro verfehltem Prozentpunkt Verfügbarkeit, Sonderkündigungsrecht nach drei aufeinanderfolgenden Verstößen)

Wichtig: Ein SLA ist kein **Auftragsverarbeitungsvertrag **(AVV). Der AVV gemäß DSGVO Art. 28 regelt den Umgang mit personenbezogenen Daten (Zugriffsrechte, Löschfristen, Subunternehmer). Das SLA regelt die Servicequalität (Verfügbarkeit, Reaktionszeit, Kompensation). Beide Dokumente sind bei IT-Outsourcing Pflicht — und sie ergänzen sich, ersetzen aber nicht.

Die fünf wichtigsten KPIs im IT-SLA

1. Verfügbarkeit — und wie sie gemessen wird

Die Verfügbarkeit gibt an, in welchem Zeitraum ein Service zur Nutzung bereitsteht. Typische Formulierungen im SLA:

• „Monatliche Systemverfügbarkeit von ≥ 99,5 %”
• „Jahresverfügbarkeit von ≥ 99,8 Prozent”

Problem: Die Messmethode ist entscheidend. Verfügbartkeit, gemessen via einmaligem täglichem Ping, bedeutet etwas anderes als Verfügbarkeit, gemessen alle fünf Minuten via Heartbeat-Probe am kritischen Punkt (z.B. Datenbank-Endpoint).

Worauf Sie achten:

• Messintervall: Alle 5 Minuten oder öfter ist Standard für geschäftskritische Dienste.
• Ausnahme-Katalog: Welche Wartungsfenster werden von der Verfügbarkeitsberechnung ausgeschlossen? (z.B. geplante Updates an Sonntagen zwischen 2:00 und 4:00 Uhr). Diese sollten vorab angemeldet sein — nicht nachträglich als „geplante Wartung” deklariert werden, wenn der Server seit drei Tagen down ist.
• Wer misst? Die Messung sollte technisch automatisiert und für beide Parteien transparent sein (z.B. im Customer-Portal einsehbar).

2. Reaktionszeit — nicht zu verwechseln mit Lösungszeit

Die Reaktionszeit gibt an, innerhalb welcher Frist der Dienstleister nach Ticket-Eingang reagiert. Das bedeutet: Ein Techniker schaut sich den Fall an, bestätigt den Erhalt und beginnt mit der Diagnose. Die Reaktionszeit ist nicht die Zeit bis zur vollständigen Problemlösung (Resolution Time).

Typische Stufen im SLA:

Wichtig zu wissen: Viele Anbieter werben mit „15 Minuten Reaktionszeit” — damit ist oft nur die automatisierte Ticket-Bestätigung gemeint, nicht die echte Aufnahme der Bearbeitung durch einen menschlichen Techniker. Ein SLA sollte klar definieren: „Reaktionszeit = Zeit bis zur manuellen Zuweisung eines qualifizierten Engineers”.

3. Wiederherstellungszeit (RTO) — besonders bei Notfällen

Die **Recovery Time Objective **(RTO) gibt an, wie schnell ein Dienst nach einem Ausfall wieder herstellbar sein muss. Diese Kennzahl wird häufig im Kontext von Disaster-Recovery-Verträgen und Backup-Services verwendet.

Beispiel: „Im Falle eines Totalausfalls der Produktionsumgebung garantiert smetrics eine Wiederherstellung innerhalb von vier Stunden ab Vorfall-Erkennung.”

Worauf Sie achten:

• Der RTO bezieht sich auf den Erstbeginn der Wiederherstellungsmaßnahmen, nicht auf die vollständige Funktionsfähigkeit aller Systeme.
• Der Wert sollte für verschiedene Szenarien definiert sein (Server-Ausfall, Datenkorruption, Ransomware-Vorfall).

4. Fehlerquote und First Response Time

Die First Response Time ist eng mit der Reaktionszeit verbunden, aber anders: Sie gibt an, wie schnell die erste qualitative Antwort auf eine Anfrage kommt — also nicht nur „Ticket erhalten”, sondern „ich habe Ihren Fall geprüft, hier sind meine ersten Feststellungen”.

Die Fehlerquote (Error Rate) misst, wie häufig ein Service pro Zeiteinheit fehlschlägt. Beispiel: „API-Antwortzeit unter 200 ms in ≥ 95 % der Aufrufe”.

5. Eskalationspflichten und Ansprechpartner

Ein gutes SLA definiert nicht nur die technischen KPIs, sondern auch den Eskalationsweg:

• Wer ist der primäre Ansprechpartner im Normalfall?
• An wen eskaliere ich nach X Minuten ohne Reaktion? (z.B. „Nach 60 Minuten bei P1-Eskalation an Technischen Leiter”)
• Gibt es dedizierte Ansprechpartner für bestimmte Kunden-Segmente?

Die Fallstricke: Woran Sie ein schlecht formuliertes SLA erkennen

1. Vage Begriffe statt messbarer Werte

❌ Schlecht: „Der Dienstleister bemüht sich um schnelle Reaktion bei Störungen.” ✅ Gut: „Reaktionszeit für P3-Tickets beträgt maximal 4 Stunden während Geschäftszeiten, gemessen ab Ticket-Eingang im Service-Desk-System.”

2. Ausnahmen die alle Ausnahmen sind

Ein SLA mit vielen unklaren Ausnahme-Klauseln schützt Sie nicht. Achten Sie auf:

• Keine pauschalen „Force Majeure”-Klauseln ohne Definition
• Geplante Wartungsfenster müssen mindestens 72 Stunden vorher angekündigt werden (außer bei akuten Sicherheits-Patches)
• Drittanbieter-Ausfälle (z.B. Cloud-Provider outage) dürfen den eigenen Verzug nicht pausieren — der Haupt-Dienstleister ist für die Koordination verantwortlich

3. Fehlende Sanktionen oder nur „Service Credits”

Ein SLA ohne Sanktionsmechanismus ist eine Empfehlung, kein Vertrag. Typische Modelle:

• Service-Guthaben: Pro verfehltem Prozentpunkt monatlicher Verfügbarkeit erhält der Kunde X % des Monatspreises als nächster Monat gutgeschrieben
• Staffelung: 95–99 % = 10 % Gutschrift, <95 % = 25 %, <90 % = Sonderkündigungsrecht

Achtung: Service Credits sind steuerlich oft problematisch. Ein direkt abziehbarer Teil des Monatspreises bei Verfehlung ist besser für Sie als Kunde.

4. Reaktionszeiten ohne Prioritäts-Definition

Ohne klar definierte Stufen (P1–P4) bleibt unklar, was „schnelle Reaktion” bedeutet. Ein guter Dienstleister hat mindestens drei Prioritäten: kritisch, hoch, normal.

NIS2 verändert die SLA-Anforderungen für Mittelständler

Das **NIS2-Umsetzungsgesetz **(NIS2UmsuCG) trat am 6. Dezember 2025 in Kraft und verpflichtet betroffene Unternehmen zur Meldepflicht bedeutender Sicherheitsvorfälle innerhalb von 24 Stunden an das BSI (BSI-Gesetz §14a).

Für Ihr SLA bedeutet das:

• Wenn Sie IT-Outsourcing betreiben, muss im Vertrag geregelt sein, wer die Meldung vornimmt und wann.
• Der Dienstleister verpflichtet sich zur Vorfall-Erkennung innerhalb von maximal 24 Stunden nach Einbruch.
• Eskalationspfade müssen so definiert sein, dass Ihr **beauftragter Datenschutzbeauftragter **(DSB) oder Geschäftsführer zeitnah informiert wird — nicht erst drei Tage später im Quartals-Report.

Für das SLA heißt das konkret: Eine Klausel wie „Sicherheitsvorfälle werden im Monatsturnus dokumentiert” ist nach NIS2 nicht mehr ausreichend. Sie brauchen eine Eskalationskette mit Uhrzeit-Garantie.

Praxischeck: So lesen Sie Ihr aktuelles (oder zukünftiges) SLA

Nutzen Sie diese Checkliste, bevor Sie einen Managed-IT-Vertrag unterschreiben:

Verfügbarkeit

• Ist das Messintervall definiert? (Alle 5 Minuten oder öfter?)
• Gibt es eine klare Definition von „Ausfall”? (Kein Heartbeat, keine API-Antwort, kompletter Dienstausfall)
• Sind Wartungsfenster vorher angemeindet und begrenzt?

Reaktionszeiten

• Gibt es eine Prioritätenmatrix P1–P4 mit konkretem Zeitrahmen?
• Wird „Reaktion” definiert als manuelle Übernahme durch Techniker oder nur automatisiertes Ticket-Acknowledgment?
• Welche Support-Zeiten gelten welche Tage (24/7 vs. Geschäftszeit)?

Eskalation

• Gibt es einen definierten Eskalationsweg mit Zeitstufen? (z.B. nach 60 Minuten an Technischen Leiter)
• Sind dedizierte Ansprechpartner für bestimmte Incident-Typen genannt?

Sanktionen

• Was passiert, wenn der Dienstleister die garantierte Verfügbarkeit verfehlt?
• Gibt es ein Sonderkündigungsrecht nach wiederholten Verstößen? (z.B. drei aufeinanderfolgende Monate <95 % oder fünf Verstöße innerhalb von 12 Monaten)

NIS2-konforme Incident-Eskalation

• Ist eine Meldepflicht bei Sicherheitsvorfällen innerhalb von 24 Stunden definiert?
• Wer meldet an das BSI (Sie oder der Dienstleister)?
• Wann wird Ihr DSB über gravierende Vorfälle informiert?

Fazit: Ein SLA ist nur so gut wie seine Durchsetzbarkeit

Das beste SLA bringt Ihnen nichts, wenn es nicht durchsetzbar ist. Achten Sie bei der Auswahl eines IT-Dienstleisters nicht nur auf die versprochenen Zeiten („Wir reagieren in 15 Minuten!”), sondern darauf, wie diese gemessen werden und was passiert, wenn sie verfehlt werden.

Ein gutes SLA:

• Vermisst statt vager Beschreibungen
• Definiert Ausnahmen klar und begrenzt
• Hat echte Sanktionen (kein nur „Service Credits”)
• Passt zur kritischen Infrastruktur Ihres Unternehmens — besonders seit NIS2

Wenn Sie aktuell kein ausgehandeltes SLA haben oder unsicher sind, ob Ihr bestehender Vertrag Ihre Anforderungen erfüllt: Fragen Sie Ihren Dienstleister nach den aktuellen Service-Zahlen des letzten Quartals. Eine transparente Firma wird diese einsehen lassen — ohne dass Sie sich als Misstrauisch verstecken müssen.

Sind Sie sich sicher, wie schnell Ihr IT-Dienstleister im Ernstfall wirklich reagiert? Transparente Reaktionszeiten sind Kern unseres Service-Desk & IT-Supports. Wir unterstützen Unternehmen dabei, SLAs zu analysieren und Notfallszenarien durchzuspielen — inklusive Prüfung auf NIS2-Konformität. Eine kostenlose Erstberatung klärt Ihren konkreten Einzelfall.

Quellen & weiterführende Hinweise

• Primärquelle: BSI – Empfehlungen zur NIS-2-Umsetzung (Dezember 2025): https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Empfehlungen-nach-Angriffszielen/NIS-2-Umsetzung/nis-2-umsetzung_node.html
• Weiterführende Fachbeiträge (Sekundärquellen, Branchenpraxis): Windweiss – „Service Level Agreement rechtssicher gestalten”; ProAct – „Service Level Agreement erklärt”.

Die in diesem Artikel genannten SLA-Klauseln und KPI-Beispiele geben gängige Branchenpraxis wieder und sind als Orientierung zu verstehen, nicht als rechtsverbindliche Vorgabe.

Checkliste SLA-Selbsttest (zum Mitnehmen)

Hier eine Kurzfassung der wichtigsten Punkte für den schnellen Überblick:

Verfügbarkeit: ✅ Messintervall ≤ 5 Minuten definiert ✅ Wartungsfenster angekündigt und limitiert ✅ Keine pauschalen Force-Majeure-Klauseln

Reaktionszeiten: ✅ P1–P4 Prioritätenmatrix mit Zeitrahmen vorhanden ✅ „Reaktion” = manuelle Übernahme durch Tech (nicht nur Ticket-Bestätigung)

Sanktionen: ✅ Service-Guthaben oder Preisnachlass bei Verfehlung ✅ Sonderkündigungsrecht nach wiederholten Verstößen

NIS2-konform: ✅ Meldepflicht innerhalb 24 Stunden definiert ✅ Eskalationspfade mit Zeitstufen für gravierende Incidents

Dieser Artikel dient der Information und ersetzt keine Rechtsberatung. Für eine verbindliche Einschätzung Ihres individuellen Falls empfehlen wir, einen Fachanwalt für IT-Recht hinzuzuziehen.