Service Level Agreement rechtssicher gestalten

Ein Service Level Agreement, kurz SLA, regelt die Qualität und Verfügbarkeit einer IT-Leistung zwischen Anbieter und Kunde. In der deutschen Vertragspraxis ist es selten ein eigenständiger Vertrag, sondern fast immer eine Anlage zum Cloud-, SaaS-, Wartungs- oder Outsourcing-Vertrag. Wer diese Anlage unterschätzt, riskiert intransparente Verfügbarkeitsmessungen, unwirksame Haftungsdeckel und im Streitfall einen Ausfall ohne Rechtsfolgen für den Anbieter. Bei größeren Managed-Services-Strukturen sollte der SLA deshalb zusammen mit dem IT-Outsourcing-Rahmenvertrag geprüft werden.

Dieser Ratgeber beantwortet drei Fragen:

• Was genau ist ein Service Level Agreement und wie grenzt es sich von operativer Leistungsvereinbarung, Wartungsvertrag, Auftragsverarbeitungsvertrag und Lizenzvertrag ab?
• Welche Pflichtinhalte muss ein SLA enthalten, damit es der deutschen AGB-Kontrolle nach §§ 305 ff. BGB standhält?
• Welche Besonderheiten gelten seit 2025 durch die neue regulatorische Landschaft aus DORA, NIS2 und EVB-IT Cloud?

Was ein Service Level Agreement ausmacht

Ein Service Level Agreement ist die vertragliche Vereinbarung über die Qualität einer IT-Dienstleistung, insbesondere über Verfügbarkeit, Reaktionszeiten und die Rechtsfolgen bei Unterschreitung dieser Ziele. In der Praxis besteht es aus einer Leistungsbeschreibung, messbaren Kennzahlen, einer Messmethode und einem Sanktionsmechanismus, meist in Form von Service Credits oder Sonderkündigungsrechten.

Diese Einordnung bestimmt, welche Haftungsregeln, Gewährleistungsfristen und Mitwirkungspflichten greifen.

Abgrenzung zu verwandten Vertragsdokumenten

Das SLA wird in der Praxis regelmäßig mit operativen Leistungsvereinbarungen, Wartungsverträgen, Lizenzverträgen oder Auftragsverarbeitungsverträgen verwechselt. Die Abgrenzung ist nicht nur terminologisch: Jede dieser Vertragsarten regelt einen eigenen Regelungsgegenstand, und derselbe Sachverhalt kann mehrere dieser Dokumente gleichzeitig erfordern.

Sie regelt, welche Abteilung oder welcher Unterauftragnehmer welche Teilleistung zu welchen Zeiten liefert. Ein Kunde sieht die OLA in der Regel nicht; sie ist aber die verletzliche Stelle jedes SLA. Wenn die interne OLA nur 99,5 Prozent Verfügbarkeit zusagt, kann der Anbieter dem Kunden über das SLA keine 99,9 Prozent garantieren, ohne die Differenz selbst zu tragen. Bei Cloud-Produkten sollte man deshalb parallel den SaaS-Vertrag prüfen lassen.

Wenn ein Managed-Services-Anbieter seinerseits Rechenzentrumsleistungen bei einem großen Hyperscaler bezieht, bildet dessen Standardvertrag den Underpinning Contract. Die Garantien des UC sind praktisch immer schwächer als das, was der Managed-Services-Anbieter dem Endkunden verspricht. Diese Lücke muss der Anbieter wirtschaftlich tragen oder im eigenen SLA gegenüber dem Endkunden offen begrenzen. Wenn der Drittanbieter zugleich klassische Lizenz- oder Pflegeleistungen schuldet, sollte man auch den Softwarevertrag prüfen lassen.

Er enthält häufig Reaktionszeiten, aber keine klassische Verfügbarkeitsgarantie. Ein Angebot mit der Formulierung “Premium-Support mit Reaktionszeit am nächsten Werktag” ist ein Wartungsvertrag, kein SLA, solange keine messbare Uptime-Kennzahl vereinbart ist. Für KI-gestützte Services müssen zudem Modellqualität, Output-Risiken und Verfügbarkeiten im KI-Vertrag abgebildet werden.

Der Lizenz- oder Nutzungsvertrag regelt den Umfang der eingeräumten Nutzungsrechte: wieviele Nutzer, welche Module, welche Nutzungszwecke sind erlaubt. Er sagt nichts über die Servicequalität aus. Widersprüche zwischen Lizenz und SLA, etwa wenn die Frontpage 99,5 Prozent Verfügbarkeit garantiert, das Kleingedruckte der Lizenz aber jede Verfügbarkeit ausschließt, werden nach § 305c Abs. 2 BGB regelmäßig zulasten des Verwenders ausgelegt.

Tiefer gehende Informationen zur Abgrenzung enthält unser Ratgeber zum Auftragsverarbeitungsvertrag.

Wie das deutsche Recht ein SLA einordnet

Ob ein SLA einklagbar und wirtschaftlich tragbar ist, hängt wesentlich davon ab, wie der übergeordnete Vertrag zivilrechtlich eingeordnet wird.

Warum SaaS und Cloud nach deutschem Recht Miete sind

Software-as-a-Service-Verträge sind nach der Rechtsprechung des Bundesgerichtshofs Mietverträge.

Auch frühere Vorgängerentscheidungen des Bundesgerichtshofs stützen das Ergebnis.

Wann Hosting als Werkvertrag eingeordnet wird

Die Abgrenzung ist subtiler als bei reinem Software-as-a-Service, aber für die Haftungslage entscheidend.

Das aktiviert die werkvertraglichen Gewährleistungsrechte nach §§ 634 ff. BGB inklusive Selbstvornahme und Minderung. In der SLA-Praxis heißt das: Wer eine Abrufbarkeitsgarantie gibt, muss auch die Mechanismen zur Nacherfüllung definieren.

Die Einordnung muss immer am Einzelfall geprüft werden; entscheidend ist der Schwerpunkt der Leistung.

Dienstvertrag für Support und Managed Services

In der Praxis sind viele Managed-Services-Verträge typengemischt.

Ein gut gestaltetes SLA bildet diese Aufteilung sauber ab und verhindert, dass streng mietrechtliche Gewährleistung auf milde dienstvertragliche Nebenleistungen durchschlägt.

Sonderfall Verbrauchervertrag

Bei Verträgen mit Verbrauchern über digitale Produkte greift seit dem 1. Januar 2022 ein eigenes Regime.

Für SLA sind zwei Normen besonders wichtig. § 327f BGB verpflichtet den Anbieter zu Aktualisierungen, insbesondere Sicherheitsupdates, während des Zeitraums, den der Verbraucher nach der Natur des Produkts erwarten darf; bei dauerhafter Bereitstellung während der gesamten Vertragslaufzeit. Und § 327k BGB kehrt die Beweislast um: Zeigt sich innerhalb eines Jahres ein Mangel, muss der Anbieter beweisen, dass das Produkt bei Bereitstellung mangelfrei war.

Trotzdem strahlen sie in die AGB-Kontrolle hinein: Abweichungen zum Nachteil des Unternehmenskunden werden nach § 307 BGB gemessen, und die Wertungen der Digitale-Produkte-Vorschriften fließen in die Angemessenheitsprüfung ein.

Warum die Einordnung die Haftungsschärfe bestimmt

Die Vertragstypisierung entscheidet über die gesetzliche Grundlinie. Je strenger der Vertragstyp, desto mehr muss ein SLA leisten, um die Risiken beherrschbar zu halten. Die Unterschiede im Überblick:

Anbieter, die beide Märkte bedienen, brauchen SLA-Varianten für beide Zielgruppen und dürfen auf keinen Fall ein einziges Template unverändert übernehmen.

Pflichtinhalte eines rechtssicheren SLA

Ein SLA, das vor deutschen Gerichten Bestand haben soll, braucht klar definierte Leistungskennzahlen, transparente Messmethoden und eine Sanktionslogik, die mit §§ 305 ff. BGB vereinbar ist. Die Mindeststruktur folgt einem einheitlichen Muster, das sich aus der Praxis großer Anwender, dem EVB-IT-Cloud-Standard und der Rechtsprechung zu AGB-Klauseln entwickelt hat.

Die folgende Übersicht fasst die wichtigsten Pflichtinhalte zusammen. Sie dient als Rahmen für eigene SLA-Entwürfe und als Prüfraster für Anbietervorlagen.

Zwischen diesen Bestandteilen bestehen wichtige Wechselwirkungen. Die Messmethode ist nur so gut wie ihr Messpunkt, und die Service Credits sind nur so wirksam wie die Haftungsklausel, die ihnen folgt. Die nächsten Abschnitte gehen auf die streitanfälligsten Pflichtinhalte im Detail ein.

Leistungsbeschreibung und Scope-Definition

Die Leistungsbeschreibung ist die Grundlage des gesamten SLA. Sie muss in nachvollziehbarer Form benennen, welche Services umfasst sind, welche Komponenten explizit ausgenommen werden und wer welche Mitwirkungspflichten trägt. Unklare Scope-Definitionen sind in der Praxis der häufigste Streitauslöser: Der Kunde meldet einen Vorfall, der Anbieter verneint die Zuständigkeit, und beide Seiten streiten darüber, ob ein Konfigurationsfehler, ein Netzwerkproblem des Kunden oder ein Plattformfehler vorliegt.

Eine belastbare Leistungsbeschreibung listet Systeme, Schnittstellen und Bestandteile einzeln auf. Sie benennt auch abgrenzbare Sonderfälle: Dritte Komponenten, die der Kunde selbst stellt, sind ausdrücklich vom Scope auszunehmen, ebenso wie individuelle Konfigurationen oder Customizings, für die der Anbieter keine Qualität garantieren kann.

Verfügbarkeit, Messpunkt und Wartungsfenster

Verfügbarkeit ist die wichtigste Kennzahl eines SLA und gleichzeitig die am häufigsten intransparent formulierte. Die Standardformel nach ISO/IEC 20000 lautet: Verfügbarkeit in Prozent gleich der Differenz aus Gesamtservicezeit und Ausfallzeit, geteilt durch die Gesamtservicezeit, multipliziert mit hundert. Was harmlos wirkt, birgt drei Fallen.

Erstens: der Messpunkt. Wird am Internet-Uplink des Rechenzentrums gemessen, am Load-Balancer des Anbieters oder am Endgerät des Anwenders? Zwischen diesen Messpunkten liegen oft mehrere Prozentpunkte. Ein SLA ohne klare Messpunktdefinition verfehlt das Transparenzgebot.

Zweitens: das Wartungsfenster.

Drittens: die Definition der Ausfallzeit. Zählt eine deutliche Verlangsamung, also eine Performance-Degradation, bereits als Ausfall oder nur der Vollausfall?

Zur Einordnung der Zahlen hilft eine Benchmark-Übersicht.

Die Sprunghöhe zwischen den Stufen ist wirtschaftlich erheblich.

Kunden, die höhere Verfügbarkeiten verlangen, müssen die damit einhergehenden Mehrkosten im Vertrag akzeptieren.

Reaktions- und Lösungszeiten nach Priorität

Beide Kennzahlen sind nur dann aussagekräftig, wenn sie nach Prioritätsstufen differenziert und an klare Kriterien gebunden sind.

Ein belastbares Prioritätsschema arbeitet mit drei bis vier Stufen.

Sonst wird der “Bekannte Fehler” zum Missbrauchsinstrument: Der Anbieter stuft einen wiederkehrenden Mangel dauerhaft als niedrige Priorität ein und entzieht ihn so der eigenen Reaktionspflicht.

Service Credits als pauschalierter Schadensersatz

Service Credits sind der zentrale Sanktionsmechanismus moderner SLA.

Das heißt: Statt den konkreten Schaden im Einzelfall zu berechnen, einigen sich die Parteien vorab auf eine feste Gutschrift bei Unterschreitung der vereinbarten Kennzahl. Das spart Streit, birgt aber AGB-rechtliche Risiken.

Im B2B-Bereich ist § 309 Nr.

Haftungsbegrenzung und Kardinalpflichten

Die Haftungsklausel ist in jedem SLA die Stelle mit dem höchsten Streitwert. Der Anbieter versucht, sein Risiko zu deckeln; der Kunde will im Ernstfall nicht mit einer faktischen Nullhaftung dastehen. Das deutsche AGB-Recht zieht hier enge Grenzen.

Auch im B2B-Bereich, in dem § 309 Nr.

Praxistaugliche Haftungsklauseln kombinieren deshalb drei Elemente: einen betragsmäßigen Deckel für leichte Fahrlässigkeit, die Ausnahme von Vorsatz und grober Fahrlässigkeit sowie eine separate Regelung für die Verletzung von Kardinalpflichten. Oft wird die Haftung summenmäßig an das Jahresvolumen oder eine feste Vielfache der monatlichen Vergütung gekoppelt.

Incident-Meldeketten und die 72-Stunden-Frist

Sicherheitsvorfälle werfen zwei parallele Fragen auf: Wie wird der Kunde informiert, und wie werden regulatorische Meldefristen eingehalten? Die DSGVO gibt hier den engsten Zeitrahmen vor.

Die Meldekette muss außerdem einen technischen Kanal, einen Eskalationsweg und einen Mindestinhalt definieren, damit die Meldung rechtlich verwertbar ist.

Exit-Klausel und Datenexport

Das Ende eines Vertrags ist der Moment, in dem der Kunde seine größte Verhandlungsschwäche hat: Er braucht den Anbieter noch einmal für den reibungslosen Übergang. Ohne Exit-Klausel riskiert er einen Vendor-Lock-in, der ihn entweder zum Verbleib zwingt oder teure Migrationsprojekte erfordert.

Eine belastbare Exit-Klausel regelt drei Punkte. Sie benennt ein offenes Exportformat (etwa CSV, JSON oder einen offenen Standard); sie legt eine Frist fest, innerhalb derer der Export nach Vertragsende bereitzustellen ist (typisch 30 Tage, bei kritischen Services auch länger); und sie definiert die Kosten, zu denen der Export erfolgt. Ohne alle drei Elemente bleibt die Exit-Klausel wirkungslos.

Das deutsche Wettbewerbsrecht strahlt in diese Regelung hinein.

Unterauftragnehmer und Subprozessoren

Moderne IT-Dienstleistungen basieren fast immer auf Lieferketten. Ein SaaS-Anbieter nutzt Cloud-Infrastruktur eines Hyperscaler, dessen Rechenzentrum wiederum Netzbetreiber einbindet. Das SLA muss diese Kette transparent machen. Fehlt die Transparenz, kann der Kunde weder Verfügbarkeit prüfen noch DSGVO-konforme Auftragsverarbeitung sicherstellen.

Das SLA sollte deshalb eine Liste der eingesetzten Subprozessoren enthalten, einen Mechanismus für Aktualisierungen dieser Liste und ein Widerspruchsrecht des Kunden bei wesentlichen Änderungen. Ein Widerspruch darf dabei nicht voraussetzungslos zu einem Sonderkündigungsrecht führen, sonst wird der Anbieter unbeweglich. Gängige Praxis ist, dass der Kunde innerhalb einer angemessenen Frist widersprechen kann und der Anbieter dann entweder auf den neuen Subprozessor verzichtet oder dem Kunden eine Sonderkündigung gegen Erstattung von Restposten einräumt.

AGB-Kontrolle und typische Fallen in SLA-Klauseln

Die praktische Konsequenz: Viele marktübliche Klauseln halten einer gerichtlichen Prüfung nicht stand. Kunden, die in einen Streit geraten, entdecken oft erst dann, dass zentrale Bestimmungen unwirksam sind und das gesetzliche Regelregime greift. Umgekehrt riskieren Anbieter, die ihre Standardklauseln nicht auf AGB-Festigkeit prüfen, höhere Haftungsrisiken als kalkuliert.

Wann SLA-Klauseln überhaupt AGB sind

Der entscheidende Unterschied liegt in der Frage, ob eine Klausel verhandelt oder ausgehandelt wurde. § 305 Abs. 1 S.

Im Enterprise-Geschäft werden einzelne Kernklauseln, etwa Haftungsdeckel oder Service Credits, durchaus individuell ausgehandelt. Der Rest des Vertrags bleibt aber AGB.

Service Credits als Exklusivrechtsbehelf

Eine der riskantesten Klauseln in SLA ist der Versuch, Service Credits als abschließenden Rechtsbehelf zu etablieren.

Die herrschende Literaturmeinung und die Instanzrechtsprechung halten einen solchen Exklusivausschluss im B2B nur dann für haltbar, wenn er tatsächlich individuell ausgehandelt wurde oder wenn Service Credits den typischen Schaden vollständig abdecken, was bei Cloud-Ausfällen praktisch nie der Fall ist.

Einseitige Änderungsvorbehalte

Ein weiterer Klassiker ist die einseitige Änderungsklausel: Der Anbieter behält sich das Recht vor, Leistungsinhalte, Preise oder Service-Level einseitig zu verändern.

Haftungsdeckel und ihre Grenzen

Intransparente Verfügbarkeitsdefinition

Das Transparenzgebot des § 307 Abs. 1 S.

Das trifft besonders bei englischsprachigen Vorlagen, die eine detaillierte Messmethodik voraussetzen, die der deutsche Text nicht enthält.

Typische Fallen aus ausländischen Vorlagen

Viele Anbieter übernehmen US-Templates unverändert. Das erzeugt mehrere Probleme.

Sie verzichten regelmäßig auf die Ausnahme für Kardinalpflichten.

Wer US-Templates einsetzt, muss sie mindestens in drei Punkten überarbeiten: Streichung des Exklusivausschlusses weiterer Rechtsbehelfe, ausdrückliche Ausnahme für Vorsatz, grobe Fahrlässigkeit und Kardinalpflichten sowie transparente Definition von Messmethode, Messpunkt und Wartungsfenster.

Regulatorische Sonderanforderungen ab 2025

Die regulatorische Landschaft hat sich seit Anfang 2025 deutlich verschoben. Finanzdienstleister und ihre IT-Lieferanten unterliegen neuen europäischen Resilienzvorgaben, kritische Infrastrukturen der neuen Cybersicherheitsrichtlinie, und öffentliche Auftraggeber nutzen das überarbeitete EVB-IT-Regelwerk. Wer diese Regime ignoriert, bekommt im Ausschreibungsprozess Probleme oder im Aufsichtsverfahren.

Anforderungen für Finanzdienstleister und IKT-Provider

Das hat zwei Konsequenzen für die SLA-Gestaltung. Erstens: Standard-SLA großer Anbieter reichen regelmäßig nicht aus, wenn Finanzkunden betroffen sind. Zweitens: IT-Dienstleister, die Finanzkunden bedienen, müssen ihr Vertragswerk spezifisch für diese Kundengruppe ertüchtigen. Wer im Finanzsektor tätig werden will, ohne dort jemals Kunde zu sein, kann die Anforderungen indirekt über seine Endkunden in die Pflicht bekommen.

Lieferketten-SLA bei kritischen Infrastrukturen

Für SLA bedeutet das konkret, dass Anforderungen an technische und organisatorische Maßnahmen, Meldepflichten und Auditrechte nicht mehr optional sind, sondern regulatorisch unterlegt.

SLA mit Incident-Meldeklauseln müssen diese Fristen abbilden und der Verantwortlichkeitszuordnung Raum geben.

Standardwerk für die öffentliche Hand

Der IT-Planungsrat hat mit den Ergänzenden Vertragsbedingungen für die IT-Beschaffung, kurz EVB-IT, Standardverträge geschaffen, die Bundes- und Landesbehörden im Regelfall verbindlich nutzen müssen. Für SLA besonders relevant sind die Vertragstypen EVB-IT Cloud, EVB-IT Dienstvertrag und EVB-IT Pflege.

Anbieter, die Ausschreibungen der öffentlichen Hand gewinnen wollen, müssen ihre SLA auf EVB-IT-Kompatibilität prüfen. Das betrifft insbesondere die Verfügbarkeitsmessung, die Audit- und Prüfrechte des Auftraggebers, die Eskalationsstufen und das Exit-Management. Abweichungen vom EVB-IT-Standard sind zulässig, müssen aber begründet und dokumentiert sein.

Unabhängige Prüfung durch Audit-Standards

Der C5-Kriterienkatalog des Bundesamts für Sicherheit in der Informationstechnik hat sich über den öffentlichen Sektor hinaus als Marktstandard für Cloud-Compliance in Deutschland etabliert. Viele private Unternehmen verlangen C5-Testate ihrer Cloud-Anbieter, teils als Ausschlusskriterium bei der Ausschreibung.

Für SLA ist der C5-Standard in zweifacher Hinsicht relevant. Erstens: Anforderungen an die Messung und das Reporting der Verfügbarkeit lassen sich gut an C5-Testate koppeln. Zweitens: Auditrechte des Kunden müssen in den Vertrag integriert werden. Anbieter, die Testate vorlegen, sollten dies im SLA dokumentieren und den Aktualisierungszyklus der Testate festlegen. Einen breiteren Überblick zum passenden Vorgehen bietet der Ratgeber Datenschutz-Audit.

Praxis-Tipps für die SLA-Verhandlung

Ein rechtssicheres SLA entsteht nicht durch das Kopieren von Vorlagen, sondern durch systematische Prüfung der eigenen Situation. Die folgenden Hinweise fassen die wichtigsten Verhandlungshebel für Kunden und Anbieter zusammen.

Prüfraster für Kundeneinkäufer

Kunden, die ein SLA bewerten, sollten die folgenden Punkte in der vorgegebenen Reihenfolge prüfen. Die Liste ist nicht abschließend, deckt aber die häufigsten Schwachstellen marktüblicher Anbieter-SLA ab.

• Service-Scope klar abgegrenzt - alle eingeschlossenen Komponenten sind namentlich benannt, Ausnahmen ausdrücklich markiert.
• Verfügbarkeit eindeutig definiert - Prozentsatz, Messmethode, Messpunkt und Wartungsfenster sind ohne Spielraum formuliert.
• Reaktions- und Lösungszeiten differenziert - klare Prioritätsstufen mit objektiven Einordnungskriterien, keine Ermessensklauseln.
• Service Credits angemessen gestaffelt - die Pauschalen decken den typischen Schaden ab und lassen weiteren Schadensersatz ausdrücklich zu.
• Haftungsdeckel realistisch - Kardinalpflichten sind ausgenommen, der Deckel korrespondiert mit dem Vertragsvolumen.
• Incident-Meldefristen unter 24 Stunden - kürzer, wenn personenbezogene Daten verarbeitet werden.
• Exit-Regelung vollständig - Exportformat, Frist und Kosten sind benannt; der Zugriff auf die Daten bleibt bis zum Abschluss der Migration sichergestellt.
• Auditrechte durchsetzbar - nicht bloß formal zugesagt, sondern mit Häufigkeit, Vorlauf und Kostenregelung unterlegt.
• Subprozessoren transparent - aktuelle Liste, Aktualisierungsmechanismus und Widerspruchsrecht sind vorgesehen.
• Sonderkündigungsrechte bei wiederholten Verstößen - ab einer definierten Schwelle (typisch drei Verstöße pro Jahr oder ein schwerwiegender Vorfall) ohne weitere Abmahnung.

Prüfraster für Anbieter

Anbieter sollten ihr Standard-SLA regelmäßig auf die folgenden Risiken prüfen und im Zweifel anpassen.

• AGB-Festigkeit aller Kernklauseln - mindestens die Klauseln zu Haftung, Service Credits, Änderungsvorbehalten und Verfügbarkeit werden durch eine juristische Prüfung gegen die aktuelle Rechtsprechung validiert.
• OLA-Stabilität prüfen - die internen und externen Lieferketten können das nach außen versprochene SLA halten; andernfalls wird das externe Versprechen reduziert.
• Incident-Prozess probeweise durchlaufen - die Meldefristen des SLA sind im Ernstfall technisch erreichbar, einschließlich der 24-Stunden-Grenze bei personenbezogenen Daten.
• Finanzielle Rückstellungen - für Service Credits und Schadensersatz werden ausreichende Rückstellungen gebildet, insbesondere bei Eintritt einer systemischen Störung.
• Regulatorische Abdeckung - das Vertragswerk passt auf die Kundensegmente; Finanzkunden brauchen DORA-Konformität, öffentliche Kunden EVB-IT-Kompatibilität.
• Deutsche Umlaute und Vertragssprache - Vertragswerke, die nur in englischer Sprache vorliegen, sind für deutsche Gerichte gültig, können aber im Streitfall durch Übersetzungsbedarf zeitlich und inhaltlich schwierig werden.
• Transparente Berichtsformate - Verfügbarkeitsreports werden automatisch und nachvollziehbar erzeugt; im Streitfall steht eine belastbare Datenbasis bereit.

Häufige Fehler im Verhandlungsprozess

Unabhängig von der Seite gibt es wiederkehrende Fehler, die SLA-Verhandlungen aufwändig und teuer machen. Die folgende Liste hebt besonders kostspielige Irrtümer hervor.

Wann anwaltliche Beratung sinnvoll ist

Nicht jedes SLA erfordert eine juristische Vollprüfung. Bei Standard-Cloud-Diensten mit geringem Volumen reicht oft die interne Qualitätssicherung. In drei Konstellationen ist anwaltliche Beratung aber regelmäßig ratsam.

Erstens bei Enterprise-Ausschreibungen mit hohen Volumina oder kritischer Funktion. Zweitens bei Verträgen im regulierten Umfeld, insbesondere Finanzdienstleister, kritische Infrastrukturen und öffentliche Hand. Drittens bei internationalen Verträgen mit ausländischem Recht, bei denen die deutsche Partei ihre Rechtslage aktiv durchsetzen will.

In diesen Fällen lohnt es sich, ein SLA nicht nur formal auf Vollständigkeit, sondern inhaltlich auf Belastbarkeit und Durchsetzbarkeit zu prüfen. Wir begleiten diese Prüfung in unserer Kanzlei als Teil der Beratung im IT-Recht und arbeiten dabei eng mit den Themen aus dem Ratgeber DSGVO-Compliance, dem Überblick zum Auftragsverarbeitungsvertrag und dem Ratgeber zum Digital Services Act zusammen.

Fazit

Ein Service Level Agreement ist weit mehr als ein technisches Anhangdokument. Es bestimmt, welche Qualität ein IT-Dienst tatsächlich liefert, wie Störungen behandelt werden und wer am Ende für Ausfälle einsteht. Die deutsche Rechtslage setzt an vielen Stellen Grenzen, die englischsprachige Vorlagen oder internationale Marktstandards nicht automatisch abbilden.

Wer als Kunde ein SLA verhandelt, sollte den Scope klar eingrenzen, die Verfügbarkeit messbar definieren, Service Credits und Haftungsdeckel auf ihre Angemessenheit prüfen und einen belastbaren Exit-Plan sicherstellen. Anbieter sollten ihr Standard-SLA regelmäßig auf Klauselfestigkeit prüfen und die aktuelle regulatorische Landschaft mit ihren verschärften Anforderungen an Finanzdienstleister und kritische Infrastrukturen in ihre Vorlagen integrieren.

In komplexen Vertragskonstellationen, insbesondere im regulierten Umfeld oder bei hohen Vertragsvolumina, ist eine juristische Prüfung des gesamten Vertragsgefüges aus Hauptvertrag, SLA, Wartungsvereinbarung und Auftragsverarbeitungsvertrag der wirksamste Schutz gegen unerwartete Haftungsrisiken und unwirksame Klauseln. Eine früh angesetzte Prüfung rechnet sich regelmäßig schon beim ersten Störfall.