SLA in SaaS-Verträgen – Verfügbarkeit, Reaktionszeit, RTO, RPO und Service-Credits
Teilen
Von Mallbutiken · Fakten geprüft am 30. September 2026 · Ca. 8 Minuten Lesezeit
Ein SLA macht das Servicelevel des SaaS-Anbieters messbar. Es sollte definieren, was Verfügbarkeit bedeutet, wie sie berechnet wird, wie Vorfälle priorisiert werden, welche Reaktionszeiten gelten, welche Wiederherstellungsziele relevant sind und was der Kunde erhält, wenn das Servicelevel nicht erreicht wird.
Was ist ein SLA in einem SaaS-Vertrag?
SLA steht für Service Level Agreement und ist oft ein Anhang zum Hauptvertrag. Der Hauptvertrag beschreibt die kommerzielle Beziehung, während das SLA die messbaren Qualitätsniveaus des laufenden Dienstes präzisiert.
Ein gutes SLA sollte sowohl im Normalbetrieb als auch bei Störungen anwendbar sein. Wenn die Parteien erst im Falle eines Vorfalls zu diskutieren beginnen, was „kritische Störung“ oder „99,9 Prozent Verfügbarkeit“ bedeuten, ist der Vertrag zu unklar.
Siehe auch den Hauptleitfaden zu den Inhalten eines SaaS-Vertrags.
Verfügbarkeit – die Prozentzahl ist nur der Anfang
Ein Verfügbarkeitswert, z. B. 99,9 Prozent, sagt ohne Messregeln wenig aus. Geben Sie daher Folgendes an:
- welcher Dienst oder welche Komponenten umfasst sind,
- Messzeitraum, z. B. Kalendermonat,
- welche Datenquelle verwendet wird,
- wann Ausfallzeiten beginnen und enden,
- ob geplante Wartungsarbeiten herausgerechnet werden,
- wie vom Kunden verursachte Fehler oder höhere Gewalt behandelt werden,
- ob Leistungsbeeinträchtigungen als Nichtverfügbarkeit gewertet werden können.
Der Unterschied zwischen 99,9 und 99,99 Prozent kann kommerziell groß sein. Die Anforderung sollte daher darauf basieren, wie geschäftskritisch der Dienst ist und was die technische Architektur des Anbieters tatsächlich leisten kann.
| Messpunkt | Zu beantwortende Frage |
|---|---|
| Verfügbarkeit | Welcher Prozentsatz, Zeitraum und welche Komponente gelten? |
| P1/P2/P3 | Wie werden kritische, hohe und normale Vorfälle definiert? |
| Reaktionszeit | Wann muss der Anbieter mit der qualifizierten Bearbeitung begonnen haben? |
| Wiederherstellung | Gibt es Ziele für die Wiederherstellung von Dienst und Daten? |
| Kommunikation | Wie oft soll der Kunde Status-Updates erhalten? |
| Sanktion | Wann greifen Service-Credits oder andere Rechte? |
Vorfallsklassen und Reaktionszeit
Die Klassifizierung von Vorfällen sollte auf der Auswirkung basieren, nicht nur auf der Art des technischen Fehlers. Ein Fehler kann technisch begrenzt, aber geschäftskritisch sein, wenn er beispielsweise Zahlungen oder den Zugriff auf einen zentralen Prozess blockiert.
Für jede Prioritätsstufe kann das SLA die Erst-Reaktionszeit, das Ziel für einen Workaround oder die Wiederherstellung, die Update-Frequenz und die Eskalationsstufe festlegen. Achten Sie auf den Unterschied zwischen Reaktionszeit und Lösungszeit. Eine Antwort innerhalb von 30 Minuten bedeutet nicht automatisch, dass der Fehler innerhalb von 30 Minuten behoben sein muss.
Support-Zeiten müssen zum Betrieb passen
Eine P1-Reaktionszeit von 30 Minuten ist für einen Betrieb, der rund um die Uhr läuft, wertlos, wenn der Support des Anbieters nur werktags von 09–17 Uhr geöffnet ist. Geben Sie an, welche Niveaus außerhalb der regulären Supportzeiten gelten und wie kritische Vorfälle gemeldet werden.
RTO und RPO – zwei verschiedene Wiederherstellungsziele
RTO (Recovery Time Objective) wird als Ziel verwendet, wie schnell ein Dienst oder Prozess nach einer Unterbrechung wiederhergestellt werden muss. RPO (Recovery Point Objective) wird als Ziel verwendet, welcher Datenverlust rückwirkend in einer Wiederherstellungssituation toleriert werden kann.
Diese sollten im IT-Vertrag nicht isoliert betrachtet werden. Eine BIA (Business Impact Analysis) kann zeigen, wie lange der Betrieb eine Unterbrechung tatsächlich verkraften kann und welcher Datenverlust akzeptabel ist. Lesen Sie den Ratgeber zur Business Impact Analysis und das praktische BIA-Beispiel.
Überprüfen Sie auch, was der Anbieter mit seinen Werten meint. Ist die RTO ein Ziel, eine Garantie oder nur ein internes Designprinzip? Gilt das RPO für alle Datentypen? Wie oft wird die Wiederherstellung getestet?
Service-Credits – Kompensation oder einzige Sanktion?
Service-Credits können einen automatischen finanziellen Anreiz schaffen, wenn das Servicelevel unterschritten wird. Eine Staffelung kann beispielsweise höhere Credits vorsehen, je weiter der Dienst unter dem Zielniveau liegt.
Prüfen Sie jedoch, ob der Vertrag besagt, dass Service-Credits die einzige Sanktion für den Kunden darstellen. Bei schwerwiegenden oder wiederholten Mängeln benötigt der Kunde möglicherweise andere Rechte, wie z. B. das Recht auf einen Maßnahmenplan, eine gesonderte Eskalation oder die Kündigung. Stimmen Sie das SLA mit den Haftungsbeschränkungen und Kündigungsregeln des Hauptvertrags ab.
Geplante Wartung und andere Ausnahmen
Der Anbieter muss den Dienst normalerweise warten können, aber eine zu weit gefasste Ausnahme kann das Verfügbarkeitsziel irreführend machen. Regeln Sie, wie weit im Voraus Wartungsarbeiten angekündigt werden müssen, welche Zeitfenster genutzt werden dürfen und ob akute Sicherheitswartungen anders gehandhabt werden.
Seien Sie auch bei Ausnahmen für Dienste Dritter vorsichtig. Wenn der Anbieter selbst einen kritischen Cloud- oder Infrastrukturanbieter gewählt hat, sollte der Vertrag verdeutlichen, wie sich diese Abhängigkeit auf das SLA und die Haftung auswirkt.
Checkliste für ein nützliches SLA
- Ist der gemessene Dienst klar definiert?
- Gibt es eine eindeutige Formel für die Verfügbarkeit?
- Sind geplante Wartungsarbeiten abgegrenzt?
- Sind die Vorfallsklassen mit den geschäftlichen Auswirkungen verknüpft?
- Unterscheidet der Vertrag zwischen Reaktion, Workaround und Lösung?
- Funktioniert der Support während Ihrer kritischen Betriebszeiten?
- Sind RTO/RPO mit echten Kontinuitätsanforderungen verknüpft?
- Gibt es Anforderungen an Status-Updates während P1-Vorfällen?
- Sind Service-Credits und andere Sanktionen klar?
- Gibt es das Recht, bei wiederholten SLA-Verstößen zu handeln?

Benötigen Sie Hauptvertrag und SLA in derselben Struktur?
Der SaaS-Vertrag von Mallbutiken enthält den Hauptvertrag und sechs Anhänge, unter anderem für die Leistungsspezifikation, SLA, AVV/GDPR, Sicherheit, Exit und Preis. Word und PDF. Preis im Shop: 149 kr.
Zum SaaS-VertragHäufig gestellte Fragen
Ist 99,9 Prozent immer ein gutes SLA?
Nein. Das richtige Niveau hängt von der Kritikalität des Dienstes, der Messmethode, Ausnahmen und den Kosten für eine höhere Redundanz ab. Die Prozentzahl muss in ihren Kontext gesetzt werden.
Ist RTO dasselbe wie SLA-Verfügbarkeit?
Nein. Verfügbarkeit misst normalerweise den Betrieb über einen Zeitraum. Die RTO betrifft das Ziel der Wiederherstellung nach einer Unterbrechung.
Sollte ein Service-Credit die einzige Sanktion sein?
Das ist eine Vertragsfrage, aber der Kunde sollte bewusst beurteilen, ob Credits allein bei schwerwiegenden oder wiederholten Mängeln ausreichen.
Weiterführende Informationen
Lesen Sie den SaaS-Vertragsratgeber, NIS2 und Lieferantensicherheit sowie den Ratgeber zur Kontinuitätsplanung.
Quellen und weiterführende Lektüre
Der Ratgeber bietet allgemeine Informationen. SLA-Niveaus sollten an die Architektur des Dienstes, die geschäftliche Kritikalität und die übrigen Vertragsbedingungen angepasst werden.