Service-Level in SaaS-Verträgen: Verfügbarkeit, Support und Sanktionen

SLA als Steuerungsinstrument im SaaS-Vertrag

Ein Service Level Agreement (SLA) hält als Vertragsbestandteil oder als separates Vertragsdokument konkrete Leistungsmerkmale eines IT-Services fest – etwa Verfügbarkeit, Reaktionszeiten oder Störungsbehebungszeiten. Solche Merkmale sind Key Performance Indicators (KPI), mit denen sich die Qualität eines IT-Services messen lässt. SLAs sind in allen IT-Bereichen verbreitet, von Betriebsverträgen über SaaS-Lösungen bis zu klassischen IT-Outsourcing-Modellen. Bekannt wurden sie im IT-Bereich durch ITIL; sie gehören zum Service-Level-Management (SLM).

Bei SaaS-Verträgen wiegt das SLA schwerer, weil zwei Umstände zusammenkommen: SaaS-Produkte tragen regelmässig wichtige oder gar kritische Geschäftsprozesse, und die Kunden zahlen in der Regel monatlich eine Vergütung. Zu vereinbaren ist deshalb, welche qualitativen Standards das Produkt erfüllen soll, wann der Support erreichbar ist und innerhalb welcher Zeit eine Fehlerbehebung möglich sein muss. Das SLA macht die Leistung qualitativ messbar: Die Parteien erlangen Gewissheit, ob das Produkt den vereinbarten Standards entspricht – und damit, wann ein «Fehler» oder «Mangel» vorliegt. Daraus lässt sich abschätzen, ob und in welcher Höhe trotz Nichterfüllung der vereinbarten Standards gezahlt werden muss.

Häufig wird ein SLA gerade dann abgeschlossen, wenn die gesetzlichen Gewährleistungsregeln für den konkreten Fall nicht ausreichen oder unpassend sind. Fehlen klare SLA-Klauseln, bleiben Leistungsumfang, Haftung oder Eskalationsmechanismen offen – im Streitfall oft kostspielig. Ein SLA schafft die Grundlage, Leistungsinhalte genau zu definieren und Vertragsverstösse objektiv zu beurteilen.

Die Kehrseite: SLA-Klauseln sind in der Praxis oft ungenau oder unvollständig und decken die konkreten Bedürfnisse nicht ab. Meist wird das erst festgestellt, wenn die Leistung mangelhaft erbracht wird.

Verfügbarkeit: Referenzzeitraum, Messmethode und Wartungsfenster

Eine Verfügbarkeitszusage besteht aus drei Elementen, die der Vertrag je einzeln festlegen muss: dem Prozentwert, dem Bemessungs- oder Referenzzeitraum und der Messmethode. In der Praxis sind genau diese drei Elemente zuerst zu klären. Ein Ausfall wirkt sich je nach Bemessungszeitraum unterschiedlich aus – derselbe Unterbruch fällt in einem kurzen Fenster stärker ins Gewicht als in einem langen.

Wartungsfenster sind in der Regel von der vereinbarten Verfügbarkeit ausgenommen. Der Vertrag muss deshalb definieren, welche Aspekte unter ein Wartungsfenster fallen und welche Rahmenbedingungen gelten – etwa eine vorangehende Kommunikation an die Kunden oder klar definierte Zeiten, in denen Wartungsarbeiten stattfinden dürfen. Fehlen diese Rahmenbedingungen, lässt sich später nicht beurteilen, ob ein Unterbruch als geplante Wartung oder als Ausfall zählt.

Wie weit Zusage und Messung auseinanderliegen können, zeigt ein Schweizer Beispiel: Der Anbieter BESA QSys gibt zu seiner SaaS-Plattform RAI-System an, der Betreiber garantiere vertraglich eine Verfügbarkeit von 99%, während die aktuell gemessene Verfügbarkeit nahezu bei 100% liege. Daten und SaaS-Infrastruktur liegen nach denselben Angaben in einem Datacenter in der Umgebung von Zürich. Garantierter und gemessener Wert sind damit zwei verschiedene Grössen; welcher im Streitfall massgebend ist, ergibt sich nicht aus der Prozentzahl, sondern aus der vereinbarten Messmethode und dem Referenzzeitraum.

Vergleich von Verfügbarkeitszusagen und Messmethoden im SLA

Support: Reaktions-, Interventions- und Behebungszeiten

Ein SLA unterscheidet typischerweise drei Zeitbegriffe: die Reaktionszeit, die Interventionszeit und die Behebungszeit. Entscheidend sind nicht nur ihre Definitionen, sondern auch allfällige Differenzierungen. Häufig werden die Zeiten je nach Schwere eines Falles abgestuft festgelegt, in einem abgestuften Incident-Modell mit Severity Levels. Der Schweregrad bestimmt dann, welche Fristen gelten – eine Störung, die den Geschäftsbetrieb stilllegt, löst andere Fristen aus als eine Anfrage ohne Betriebsunterbruch.

Zentral ist die Frage, wann eine Reaktionszeit zu laufen beginnt: mit der Meldung durch den Kunden, mit deren Eingang in einem bestimmten System, mit der Bestätigung des Eingangs oder erst mit der Klassifizierung des Falls. Eine einfache Definition im SLA beantwortet diese Frage – ohne sie ist im Streitfall offen, ob eine Frist überhaupt verletzt wurde.

Mit den Zeitbegriffen verbunden ist die Support-Erreichbarkeit: Zu vereinbaren ist, wann der Support erreichbar ist und innerhalb welcher Zeit eine Fehlerbehebung erfolgen kann. In der Praxis wird zwischen Bürozeiten und einer durchgehend besetzten Stelle abgestuft; welche Variante passt, hängt davon ab, wie kritisch der Geschäftsprozess ist, der auf dem SaaS-Produkt läuft. Ein abgestuftes Incident-Modell verbindet beides: Es koppelt den Schweregrad an Erreichbarkeit und Fristen, statt für alle Fälle dieselbe Zeit zu setzen.

Definitionen und Ausschlüsse: Damit das SLA nicht zahnlos bleibt

Klare Definitionen sind der erste Prüfpunkt, auch wenn er wenig spektakulär wirkt. Zu beantworten sind Fragen wie: «Auf was bezieht sich die Verfügbarkeit?» und «Wann beginnt die Reaktionszeit zu laufen?» Die Antworten lassen sich verhältnismässig einfach als Definitionen im SLA festhalten. Dazu gehört auch, wie Fehler und Mängel umschrieben werden – erst über diese Definition lässt sich bestimmen, wann eine Abweichung vom vereinbarten Standard vorliegt und welche Rechte daraus entstehen.

Ausschlüsse legen fest, welche Ereignisse nicht SLA-relevant sein sollen. Typische Beispiele sind Abhängigkeiten von Dritten, DDoS-Angriffe und höhere Gewalt. Solche Ausschlüsse sind legitim, müssen aber eng umschrieben sein: Je offener die Formulierung, desto eher lässt sich ein Ausfall, den der Anbieter beeinflussen könnte, als ausgenommener Fall einordnen.

Unklare oder unvollständige Klauseln haben konkrete Folgen. SLAs sind in der Praxis nicht selten rudimentär und unklar festgehalten und können dadurch wirkungslos bleiben; die Schwachstellen zeigen sich regelmässig erst bei mangelnder Leistungserbringung, nicht beim Vertragsabschluss. Ein SLA, das nicht definiert, was ein Fehler, was ein Wartungsfenster und was ein ausgenommener Umstand ist, bietet im Streitfall keine Grundlage für eine objektive Beurteilung.

Messung, Reporting und Nachweis

Messmethoden und Referenzzeiträume sind der zweite Prüfpunkt: Wer misst was, wie und für welche Zeiträume? Ohne diese Festlegungen ist eine SLA-Zusage kaum objektiv beurteilbar, weil schon der Bezugszeitraum das Ergebnis verändert. Wer die Messung nicht regelt, überlässt die Beurteilung faktisch demjenigen, der die Zahlen liefert.

Zum Reporting gehört die Frage, in welcher Form und in welcher Periodizität der Anbieter über die gemessenen Werte berichtet und ob die Messpunkte oder Rohdaten mitgeliefert werden.

Für den Nachweis ist deshalb zu regeln, wer Einsicht in die Messdaten erhält und wie mit Messlücken umgegangen wird. Welche Zahl im Streit massgebend ist, ergibt sich nicht aus der Zusage, sondern aus den Messregeln – aus Messmethode, Referenzzeitraum und der Frage, wessen Messung als Referenz anerkannt wird.

Sanktionen und Konsequenzen bei SLA-Verstössen

Fehlt eine Regelung zu den Konsequenzen im Verletzungsfall, bleibt das SLA ein «zahnloser Tiger». Zusagen zu Verfügbarkeit und Reaktionszeiten bleiben unverbindlich, solange keine Rechtsfolge daran geknüpft ist; ohne klare Klauseln bleiben auch die Eskalationsmechanismen offen – im Streitfall kostspielig.

Als Konsequenzen werden in der Praxis häufig Gutschriften auf die wiederkehrende Vergütung diskutiert, ausserdem Eskalationsstufen von der ersten Ansprechstelle bis zur Geschäftsleitung sowie ausserordentliche Kündigungs- oder Rücktrittsrechte bei wiederholten oder schweren Verstössen. Welche Mechanismen greifen und ab welcher Schwelle, gehört in die Regelung zu den Konsequenzen; die Eskalation sollte dabei an dieselben Severity Levels anknüpfen, die für die Supportzeiten vereinbart wurden.

An die Sanktionen grenzt die Haftungsfrage. In SaaS-Verträgen gehören Regelungen zu Haftung, Gewährleistung und IP-Rechten zum üblichen Vertragsinhalt, und ein SLA wird gerade dann abgeschlossen, wenn die gesetzlichen Gewährleistungsregeln nicht ausreichen oder unpassend sind. Zu klären ist deshalb, wie SLA-Sanktionen und allgemeine Haftungsregeln zusammenwirken – insbesondere, ob eine Gutschrift die abschliessende Folge bleibt oder daneben weitergehende Ansprüche bestehen.

Einbettung in SaaS-Vertrag, AGB und Schweizer Praxis

Bei standardisierten SaaS-Modellen sollten SaaS-Vertrag, AGB, Service Levels, Auftragsbearbeitungsvertrag (DPA) und Datenschutzdokumentation aufeinander abgestimmt sein. Ebenso wichtig sind Fragen zu Datennutzung, Datenexport und Exit. SaaS- und Softwaremodelle benötigen zudem klare Regelungen zu Leistungsumfang, Verfügbarkeit, Nutzungsrechten, Updates, Support, Haftung und Beendigung (Lezzi Legal, Zürich). Nennt das SLA andere Werte als die AGB oder die Produktdokumentation, entsteht ein Widerspruch, der im Streitfall zuerst aufgelöst werden muss.

SaaS-Produkte werden iterativ weiterentwickelt; Funktionen, Preismodelle, Integrationen und technische Abhängigkeiten ändern sich laufend. Die rechtliche Dokumentation sollte deshalb mit dem Produkt wachsen können und nicht bei jeder technischen Anpassung neu aufgebaut werden müssen (Lezzi Legal). Für das SLA folgt daraus, dass Anpassungen von Messmethode, Wartungsfenstern und Supportzeiten einen geordneten Weg im Vertrag brauchen.

Für SaaS-Verträge in der Schweiz kann Hosting im Inland ein zweckmässiges Vertragselement sein. Der WEKA-Mustervertrag für SaaS nennt als Nutzen: garantierte Verfügbarkeit mit klar definierten SLA-Regelungen, Hosting in der Schweiz mit Back-ups, Kostentransparenz über klare Gebühren und ein nachvollziehbares Abrechnungsmodell, Regelungen zu Haftung, Gewährleistung und IP-Rechten sowie die Kontrolle über die eigenen Daten einschliesslich deren Herausgabe ohne Zurückbehaltungsrecht.

Der Zugriff lässt sich vertraglich konkretisieren: Der Anbieter BESA QSys gibt an, der Zugriff auf die SaaS-Lösung sei standardmässig über ein Geoblocking eingegrenzt bzw. könne beim Setup auf bestimmte Zugriffsorte beschränkt werden. Solche Angaben gehören mit dem SLA abgeglichen, weil eine Sperre beim Zugriff dieselben Verfügbarkeits- und Supportfristen auslösen kann.

Checkliste für die Vertragsverhandlung

Definitionen: Was ist ein Fehler, was ein Mangel, was eine Störung? Auf was bezieht sich die Verfügbarkeit? Wann beginnt eine Reaktionszeit zu laufen? Definitionen im SLA beantworten diese Fragen und sind die Voraussetzung dafür, dass das Dokument nicht wirkungslos bleibt.

Messung und Referenzzeiträume: Wer misst was, wie und für welche Zeiträume? Welcher Bemessungszeitraum gilt für die Verfügbarkeit, und welcher Messwert ist im Streitfall massgebend?

Supportzeiten: Reaktions-, Interventions- und Behebungszeiten separat festhalten und nach Schweregrad differenzieren (abgestuftes Incident-Modell mit Severity Levels); zusätzlich die Support-Erreichbarkeit regeln.

Wartungsfenster und Ausschlüsse: Definieren, welche Aspekte unter ein Wartungsfenster fallen und welche Rahmenbedingungen gelten (vorgängige Kommunikation, klar definierte Zeiten). Ausschlüsse eng fassen – typische Kandidaten sind Drittabhängigkeiten, DDoS-Angriffe und höhere Gewalt.

Konsequenzen und Abstimmung: Eine Regelung zu den Folgen von SLA-Verstössen samt Eskalationsmechanismen ist zwingend, sonst bleibt das SLA zahnlos. Abschliessend prüfen, ob Service Levels, SaaS-Vertrag, AGB, Auftragsbearbeitungsvertrag (DPA) und Datenschutzdokumentation aufeinander abgestimmt sind.

Checkliste für die Vertragsverhandlung von SLAs in SaaS-Verträgen