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 in einem separaten Vertragsdokument konkrete Leistungsmerkmale eines IT-Services fest: Verfügbarkeit, Reaktionszeiten, Störungsbehebungszeiten. Diese 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 klassischem IT-Outsourcing. Bekannt wurden sie im IT-Bereich durch ITIL; sie gehören zum Service-Level-Management (SLM).

SaaS-Produkte reichen von Kollaborationstools wie Microsoft 365 und Google Workspace über CRM-Systeme bis zu generativer KI. Je nach Anwendung fällt die Kritikalität der Geschäftsprozesse und damit die nötige Schärfe des SLA anders aus.

In SaaS-Verträgen bündelt sich das SLA in drei Bereichen: Verfügbarkeit, Support und Sanktionen. Jeder Bereich verlangt eigene Angaben – Prozentwert, Referenzzeitraum und Messmethode bei der Verfügbarkeit; Erreichbarkeit sowie Reaktions-, Interventions- und Behebungszeiten beim Support; Rechtsfolgen, Schwellen und Zuständigkeiten bei den Sanktionen.

Bei SaaS-Verträgen wiegt das SLA schwerer, weil zwei Umstände zusammenkommen: SaaS-Produkte tragen regelmässig wichtige oder kritische Geschäftsprozesse, und 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 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.

Ein SLA schafft klare Richtlinien und Vorgaben: Es verschafft den Parteien einen Überblick über den Leistungsinhalt sowie die konkreten Rechte und Pflichten und lässt das Risiko bei Ausfällen vorab abschätzen. Für Unternehmen bedeutet das mehr Rechtssicherheit und weniger Graubereiche.

Bei SaaS-Produkten sind zeitnaher Support und schnelle Fehlerbehebung wichtig. Deshalb gehören spezielle Regelungen zu Rechten und Pflichten bei Problemen und Leistungsstörungen in den Vertrag; die Hauptleistungspflichten sind so präzise wie möglich zu beschreiben. Fehlt eine ausdrückliche Regelung, gelten die gesetzlichen Vorschriften, die für den konkreten Fall oft nachteilig ausfallen.

Vorteile und Risiken von SLA-Klauseln in SaaS-Verträgen

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 je nach Bemessungszeitraum unterschiedlich: 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 für Wartungsarbeiten. Fehlen diese Rahmenbedingungen, lässt sich später nicht beurteilen, ob ein Unterbruch als geplante Wartung oder als Ausfall zählt.

Beim SaaS-Modell übernimmt der Betreiber Wartungsarbeiten und Softwareaktualisierungen. Solche Eingriffe sind die typischen Inhalte eines Wartungsfensters und gehören mit Vorlauf, Kommunikationsweg und klar definierten Zeiten in den Vertrag.

Für die Messung folgt daraus, dass geplante Wartungsarbeiten nicht in die Verfügbarkeitsberechnung einfliessen dürfen. Sonst zählt jede ordentlich angekündigte Wartung als Ausfall und drückt den gemessenen Wert.

Ein Schweizer Beispiel zeigt, wie weit Zusage und Messung auseinanderliegen können: 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.

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, 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.

Ein Beispiel für ein Bürozeiten-Modell: WEKA nennt für seinen telefonischen Kundendienst Mo–Fr 08:00–12:00 Uhr und 13:30–16:30 Uhr; schriftliche Anfragen werden je nach Verfügbarkeit auch ausserhalb der Telefonzeiten beantwortet. Wer Support nur zu Bürozeiten zusagt, weist diese Zeiten im SLA aus und hält fest, wie Meldungen ausserhalb angenommen werden.

Die drei Zeitbegriffe sind zugleich die Bezugsgrössen der Sanktionen. Eine verpasste Frist liefert den messbaren Nachweis, an den eine Gutschrift oder eine Eskalationsstufe anknüpft.

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.

Definitionen wirken in allen drei Bereichen: Sie entscheiden, welcher Unterbruch als Ausfall zählt, wann eine Supportfrist zu laufen beginnt und ob eine Sanktion ausgelöst wird. Fehler, Mangel, Störung, Reaktionsbeginn, Wartungsfenster und Ausschluss gehören deshalb ausdrücklich in den Vertrag.

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.

Das Reporting ist die Brücke zu den Sanktionen: Ohne ausgewiesene Messwerte lässt sich eine Unterschreitung nicht belegen. Form, Periodizität und Einsichtsrechte gehören deshalb zusammen mit der Gutschrift geregelt.

Regelmässige Überprüfungen zum Schutz vor unerlaubten Zugriffen sind kein Nachweis der Verfügbarkeit. BESA QSys gibt für das RAI-System solche Prüfungen an; für das SLA zählen die gemessenen Werte und deren Dokumentation.

Schritte zur sicheren Umsetzung eines SLA im SaaS-Vertrag

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.

Sanktionen knüpfen an die gemessenen Werte an. Ohne geregelte Messung fehlt die Grundlage, um einen Verstoss festzustellen und eine Gutschrift auszulösen.

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.

Vier Angaben machen eine Sanktionsklausel prüfbar: die Schwelle, ab der sie greift, die Höhe der Gutschrift als Anteil der wiederkehrenden Vergütung, eine allfällige Obergrenze und die Zahl der Wiederholungen, ab der ein ausserordentliches Kündigungsrecht greift. Erst mit diesen Angaben lässt sich im Streitfall rechnen.

Gutschriften, Eskalationsstufen und Kündigungsrechte wirken nur, wenn Schwellen und Zuständigkeiten benannt sind. Ohne diese Angaben bleibt jede Sanktion eine Absichtserklärung.

An die Sanktionen grenzt die Haftungsfrage. In SaaS-Verträgen gehören Regelungen zu Haftung, Gewährleistung und IP-Rechten zum üblichen Vertragsinhalt. 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 sowie Kostentransparenz über klare Gebühren und ein nachvollziehbares Abrechnungsmodell.

Hinzu kommen 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.

Zur Abstimmung gehören weitere Punkte: Regelungen zu Urheberrecht und IP, zu Haftung und Gewährleistung sowie dazu, was nach Vertragsende mit den Daten geschieht. Bei Verträgen mit deutschem Recht sind vorformulierte AGB an den §§ 305 bis 310 BGB zu messen. Bei Verträgen mit internationalem Bezug, insbesondere bei Cloud-Diensten, ist zusätzlicher Prüfbedarf angezeigt.

Checkliste für die Vertragsverhandlung

Die Checkliste prüft die drei Bereiche des SLA in dieser Reihenfolge: Verfügbarkeit, Support, Sanktionen. Jeder Punkt ist erst erfüllt, wenn der Vertrag eine überprüfbare Angabe enthält – einen Wert, einen Zeitraum, eine Frist oder eine Schwelle.

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 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.

Nachweis: Form und Periodizität des Reportings festhalten, Einsichtsrechte in die Messdaten regeln, den Umgang mit Messlücken klären und bestimmen, wessen Messung als Referenz anerkannt wird.

Haftung: Prüfen, wie SLA-Sanktionen und allgemeine Haftungsregeln zusammenwirken – insbesondere, ob eine Gutschrift abschliessend bleibt oder daneben weitergehende Ansprüche bestehen.

Vertragsende: Regeln, was nach Vertragsende mit den Daten geschieht, und die IP- sowie Urheberrechtslage klären.

Prüfliste für SLA-Vertragsverhandlungen