Montagmorgen, kurz nach Arbeitsbeginn. Das ERP ist nicht erreichbar, die Telefonie hakt, der Zugriff auf die Cloud läuft ins Leere. Vertrieb, Buchhaltung und Produktion melden gleichzeitig Störungen. Der externe IT-Dienstleister ist zwar bekannt, aber niemand kann auf Anhieb sagen, wer jetzt zuständig ist, welche Reaktionszeit vereinbart wurde und ab wann aus einem Problem ein Vertragsverstoß wird.
Genau in solchen Momenten zeigt sich, ob ein Unternehmen nur einen IT-Vertrag hat oder ein belastbares Service Level Agreement. Ohne klare Servicezusagen wird aus einem technischen Vorfall schnell ein Führungsproblem. Die Geschäftsführung fragt nach Verbindlichkeit. Die IT fragt nach Zuständigkeiten. Der Dienstleister fragt nach Priorisierung. Und alle verlieren Zeit.
Viele KMU behandeln das Thema noch immer als Vertragsanhang. Das ist zu kurz gedacht. Ein gutes SLA regelt nicht nur, was ein Dienstleister leisten soll. Es schützt den laufenden Betrieb, schafft Nachweisbarkeit für Audits und macht externe IT-Leistungen steuerbar.
Wer heute mit Cloud-Diensten, ausgelagertem Support oder sicherheitskritischen Systemen arbeitet, braucht kein allgemeines Leistungsversprechen, sondern ein präzises Regelwerk. Gerade bei NIS-2, ISO 27001 und steigenden Anforderungen an Dokumentation und Verantwortlichkeit wird das SLA zum operativen Werkzeug des Managements.
Einleitung Wenn die IT stillsteht und das Geschäft leidet
Der kritische Fehler in vielen Unternehmen passiert nicht beim Einkauf der IT-Leistung, sondern bei der Erwartungshaltung danach. Man geht davon aus, dass “Support” schon irgendwie funktioniert. Solange alles läuft, fällt das nicht auf. Beim ersten ernsten Ausfall wird die Lücke sichtbar.
In der Praxis sehe ich immer wieder dasselbe Muster. Der Dienstleister reagiert grundsätzlich, aber die Reaktion ist nicht sauber definiert. Es gibt vielleicht einen Ansprechpartner, aber keine Eskalationsstufe. Es gibt vielleicht eine Verfügbarkeitsaussage, aber keine klare Regel, wie sie gemessen wird. Dann diskutieren beide Seiten nicht über die Lösung, sondern über die Auslegung.
Ein SLA ist dann gut, wenn es im Störungsfall keine Interpretationsdebatte auslöst.
Für Geschäftsführer ist das vor allem ein Risiko für den Betrieb. Für IT-Leiter ist es zusätzlich ein Risiko für Steuerbarkeit und Compliance. Wenn externe Leistungen geschäftskritische Prozesse tragen, darf niemand auf Zuruf arbeiten.
Dazu kommt ein zweiter Punkt, der häufig unterschätzt wird. Ein technischer Ausfall ist selten nur ein IT-Problem. Er wirkt in Kundenservice, Logistik, Rechnungsstellung, Produktion und Kommunikation hinein. Das SLA ist deshalb kein Papier für Juristen allein, sondern ein Führungsinstrument für die Schnittstelle zwischen Geschäft und IT.
Woran Unternehmen ohne SLA scheitern
- Unklare Prioritäten: Ein Ausfall im Shop, ein Druckerproblem und ein Benutzerkonto landen im selben Topf.
- Fehlende Nachweise: Bei Monatsgesprächen gibt es Meinungen, aber keine belastbaren Messwerte.
- Schwache Eskalation: Niemand weiß, wann der Vorfall vom Helpdesk zur technischen Leitung wandert.
- Verwischte Verantwortung: Der Anbieter wartet auf Informationen, der Kunde glaubt, alles sei bereits gemeldet.
Ein brauchbares Service Level Agreement schafft hier Ordnung. Es definiert Leistungen, Reaktionswege, Messgrößen, Sanktionen und Mitwirkungspflichten. Vor allem aber sorgt es dafür, dass im Ernstfall nicht improvisiert werden muss.
Was ist ein Service Level Agreement wirklich
Ein Service Level Agreement ist kein freundliches Qualitätsversprechen. Es ist eine verbindliche Vereinbarung zwischen Kunde und Dienstleister darüber, welcher Service in welcher Qualität erbracht wird und wie diese Qualität messbar gemacht wird.
Ein einfaches Bild hilft. Nehmen Sie einen Reinigungsvertrag für ein Büro. Entscheidend ist nicht nur, dass “gereinigt” wird. Entscheidend ist, welche Flächen dazugehören, wie oft gereinigt wird, welche Zeiten gelten, was als Mangel zählt und wie nachgebessert werden muss. Genau so funktioniert ein SLA in der IT.
Der Kern eines SLA
Ein SLA beantwortet vier einfache, aber geschäftskritische Fragen:
- Was wird geliefert
- Wie wird die Leistung gemessen
- Was passiert bei Abweichungen
- Wer muss auf welcher Seite mitwirken
Damit wird aus einem allgemeinen IT-Vertrag ein steuerbares Betriebsmodell. Für viele Unternehmen ist das der Punkt, an dem Outsourcing, Managed Services oder Cloud-Betrieb erst wirklich beherrschbar werden.
Wer das Thema tiefer im Kontext des laufenden IT-Betriebs einordnen will, findet bei Managing Services und der Rolle standardisierter IT-Leistungen eine sinnvolle Ergänzung.
Was ein SLA nicht ist
Ein SLA wird oft mit anderen Begriffen vermischt. Das führt später fast immer zu Missverständnissen.
| Begriff | Bedeutung | Typischer Einsatz |
|---|---|---|
| SLA | Vereinbarung zwischen Kunde und Dienstleister | Externe Servicequalität |
| OLA | Interne Vereinbarung zwischen Teams | Zusammenarbeit etwa zwischen Helpdesk und Infrastruktur |
| UC | Vertrag mit Unterlieferanten | Absicherung externer Vorleistungen |
Der Unterschied ist praktisch wichtig. Wenn Ihr IT-Dienstleister Ihnen eine kurze Reaktionszeit verspricht, selbst aber auf einen Cloud-, Netz- oder Security-Zulieferer angewiesen ist, dann muss diese Kette intern und vertraglich abgesichert sein. Sonst steht im SLA etwas, das operativ gar nicht zuverlässig eingehalten werden kann.
Praxisregel: Ein externes SLA ist nur dann belastbar, wenn interne Abläufe und Vorlieferanten dieselbe Logik tragen.
Viele schlechte SLAs scheitern nicht an der Formulierung, sondern daran, dass sie von der Realität des Servicebetriebs entkoppelt sind. Deshalb sollte jede Zusage immer auf Umsetzbarkeit geprüft werden, nicht nur auf sprachliche Sauberkeit.
Die zentralen Bestandteile eines wasserdichten SLAs
Ein gutes SLA verhindert Streit, bevor er entsteht. Genau daran erkennt man in der Praxis den Unterschied zwischen einer formalen Anlage zum Vertrag und einem Steuerungsinstrument, mit dem Geschäftsführung, IT-Leitung und Dienstleister denselben Service gleich verstehen.
Leistungsbeschreibung und Geltungsbereich
Viele SLAs scheitern an einer zu groben Beschreibung des Leistungsumfangs. Formulierungen wie „Betreuung der Serverlandschaft“ oder „Support für Cloud-Systeme“ klingen ordentlich, lassen aber im Ernstfall zu viel offen.
Ein wasserdichtes SLA benennt konkret, welche Systeme, Anwendungen, Standorte und Benutzergruppen erfasst sind. Es regelt Betriebszeiten, Supportkanäle, Wartungsfenster, technische und organisatorische Schnittstellen sowie klare Ausschlüsse. Gerade für KMU ist dieser Punkt strategisch relevant. Wer im Rahmen von NIS-2 oder ISO 27001 Verantwortlichkeiten nachweisen muss, braucht hier keine Marketingformeln, sondern belastbare Abgrenzungen.
Service Levels und Messlogik
Leistungszusagen müssen messbar und nachvollziehbar sein. Bei der Verfügbarkeit ist das besonders wichtig. Eine Verfügbarkeit von 99,9 Prozent entspricht rechnerisch rund 8,76 Stunden maximaler Ausfallzeit pro Jahr, wenn auf Jahresbasis gerechnet wird (Einordnung und Rechenbeispiel bei IBM).
Entscheidend ist aber nicht nur der Prozentwert. Entscheidend ist die Messregel dahinter. Wird monatlich oder jährlich gemessen? Sind geplante Wartungsfenster ausgenommen? Zählen Teilausfälle, etwa ein gestörter Remote-Zugang oder eine ausgefallene Multifaktor-Authentifizierung, als SLA-relevante Störung? Ohne diese Präzisierung bleibt eine Kennzahl im Vertrag oft nur eine Zahl ohne Beweiskraft.
Rollen und Mitwirkungspflichten
In vielen Verträgen ist sauber geregelt, was der Dienstleister leisten soll. Die Mitwirkung des Kunden bleibt dagegen auffällig vage. Genau das führt später zu Diskussionen über verpasste Fristen, unvollständige Meldungen oder fehlende Freigaben.
Ein sauberes SLA legt deshalb fest:
- wer Störungen melden und priorisieren darf
- welche Informationen bei einer Meldung vorliegen müssen
- wer auf Kundenseite Entscheidungen, Tests oder Freigaben übernimmt
- welche Verzögerungen außerhalb des Einflussbereichs des Dienstleisters liegen
Diese Punkte sind auch aus Compliance-Sicht relevant. NIS-2 verlangt keine schönen Tabellen, sondern nachvollziehbare Zuständigkeiten, Eskalationswege und dokumentierte Reaktion auf Vorfälle.
Ein SLA ohne geregelte Mitwirkungspflichten erzeugt keine Klarheit, sondern neue Interpretationsspielräume.
Reporting und Service-Reviews
Ein SLA wirkt nur, wenn seine Einhaltung regelmäßig geprüft wird. Sonst bleibt es ein Dokument für die Vertragsakte.
Sinnvoll sind feste Berichtszyklen und klar definierte Inhalte. Dazu gehören Ticketvolumen, Prioritätsverteilung, Fristeinhaltung, wiederkehrende Störungsursachen, bekannte Risiken und offene Maßnahmen. In gut geführten KMU-Umgebungen wird daraus mehr als ein Reporting. Es wird ein Führungsinstrument, das zeigt, ob der Dienstleister nur Tickets schließt oder ob der Betrieb tatsächlich stabiler wird.
Eskalation und Folgen bei Verstößen
Jedes SLA braucht einen geregelten Ausnahmefall. Nicht jede Störung ist kritisch. Manche sind es aber sehr schnell, etwa wenn ein ERP-System ausfällt, ein Security Incident nicht sauber bearbeitet wird oder ein externer Dienst trotz mehrfacher Tickets nicht wiederhergestellt wird.
Darum sollte das SLA drei Ebenen trennen:
- Operative Eskalation bei drohender Überschreitung vereinbarter Zeiten
- Management-Eskalation bei wiederholten, schwerwiegenden oder geschäftskritischen Verstößen
- Vertragliche Folgen wie Service Credits, Sonderkündigungsrechte oder definierte Nachbesserungspflichten
Hier zeigt sich die Qualität eines Vertrags besonders deutlich. Ein Eskalationsmodell ohne Folgen bleibt folgenlos. Ein Sanktionsmodell ohne praktikablen Eskalationsweg hilft im Tagesgeschäft ebenfalls nicht.
Laufzeit und Änderungsmechanismus
IT-Services ändern sich laufend. Neue Standorte kommen hinzu, Microsoft- oder Cloud-Dienste werden anders genutzt, Sicherheitsanforderungen werden verschärft, Lieferketten ändern sich. Ein SLA muss diese Realität abbilden.
Deshalb gehört ein klarer Änderungsmechanismus in jedes solide Vertragswerk. Wer darf Änderungen anstoßen? Wie werden neue Systeme aufgenommen? Wann ändern sich Servicezeiten, Prioritäten oder Sicherheitsanforderungen? Für KMU ist genau das oft der Punkt, an dem ein SLA vom statischen Vertrag zum strategischen Werkzeug wird. Es hält den laufenden Betrieb, das Risikomanagement und die Compliance auf derselben Linie.
Wichtige Metriken und KPIs verständlich erklärt
Im Alltag scheitern viele SLAs nicht an fehlenden Zahlen, sondern an unklaren Begriffen. Das zeigt sich meist erst im Störungsfall. Der Dienstleister meldet sich pünktlich zurück, der Betrieb steht aber trotzdem noch. Für Geschäftsführung und IT-Leitung ist deshalb entscheidend, welche Kennzahl was tatsächlich absichert.
Reaktionszeit beschreibt, wann ein Ticket angenommen oder mit der Bearbeitung begonnen wird. Lösungszeit beschreibt, bis wann der betroffene Service wieder nutzbar sein muss. Verfügbarkeit bewertet den Betrieb über einen definierten Zeitraum. Priorität legt fest, welche Fristen überhaupt gelten. Wer diese vier Punkte im Vertrag nicht sauber trennt, diskutiert im Ernstfall über Formalien statt über Wiederanlauf und Risiko.
Was die wichtigsten Kennzahlen wirklich bedeuten
| KPI | Praktische Bedeutung | Typischer Fehler in KMU-SLAs |
|---|---|---|
| Verfügbarkeit | Misst, wie zuverlässig ein Service im vereinbarten Zeitraum nutzbar ist | Es bleibt offen, ob Wartungsfenster, Fremdleistungen oder Cloud-Abhängigkeiten herausgerechnet werden |
| Reaktionszeit | Gibt vor, wie schnell der Dienstleister auf eine gemeldete Störung reagieren muss | Sie wird als Qualitätsbeweis verkauft, obwohl das Problem damit noch nicht gelöst ist |
| Lösungszeit | Definiert, wann der betroffene Dienst wieder funktionieren muss oder ein Workaround stehen muss | Sie fehlt ganz oder ist so weich formuliert, dass sie kaum durchsetzbar ist |
| Priorität | Ordnet Tickets nach Geschäftsauswirkung und legt daran Fristen fest | Die Einstufung erfolgt nach Lautstärke des Anrufers statt nach betroffener Geschäftsleistung |
Für KMU reicht meist ein kleiner, klarer KPI-Satz. Entscheidend ist nicht die Menge der Kennzahlen, sondern ihre Messbarkeit und ihre Wirkung im Betrieb. Ein Audit nach NIS-2 oder ISO 27001 fragt am Ende nicht nach schönen Tabellen, sondern nach nachvollziehbaren Zuständigkeiten, definierten Reaktionswegen und belastbaren Nachweisen.
Verfügbarkeit richtig lesen
Verfügbarkeit ist die Kennzahl, die in Verhandlungen am häufigsten überschätzt wird. Eine hohe Prozentzahl klingt gut, sagt für sich allein aber wenig aus. Erst mit Bezugszeitraum, Messmethode und Ausschlüssen wird sie belastbar.
Die Europäische Kommission beschreibt in ihren Leitlinien zur Verfügbarkeit digitaler Dienste, dass Verfügbarkeit immer im Zusammenhang mit Messzeitraum und Unterbrechungen bewertet werden muss, nicht als isolierter Prozentwert (European Commission zu Availability and Business Continuity). Microsoft dokumentiert in seinen SLA-Hinweisen ebenfalls, dass die Berechnung von Uptime, Wartungsfenstern und servicebezogenen Ausnahmen nur dann belastbar ist, wenn diese im Vertrag eindeutig definiert sind (Microsoft, SLA terms and service availability definitions).
Für die Praxis heißt das: Zwei Anbieter können beide 99,9 Prozent zusagen und trotzdem ein sehr unterschiedliches Risikoniveau liefern. Der eine misst nur den Kernservice. Der andere rechnet Authentifizierung, Netzwerkabhängigkeiten oder geplante Wartung anders. Genau an dieser Stelle entscheidet sich, ob ein SLA zur Absicherung taugt oder nur gut aussieht.
Worauf es bei KPIs in der Praxis ankommt
- Nur messbare Kennzahlen vereinbaren: Wenn unklar bleibt, wer misst, womit gemessen wird und welche Systeme in die Messung einfließen, ist der KPI später kaum belastbar.
- Geschäftsauswirkung vor Technikdetail stellen: Für ein ERP, ein Ticketsystem und einen Dateiservice gelten oft unterschiedliche Fristen, auch wenn alles formal “IT” ist.
- Workaround und Endlösung unterscheiden: Für viele KMU ist ein funktionierender Notbetrieb innerhalb kurzer Zeit wichtiger als die vollständige Ursachenbeseitigung am selben Tag.
- Ausschlüsse schriftlich prüfen: Wartung, Fremdprovider, Internetanschluss, Cloud-Plattform und Mitwirkungspflichten des Kunden müssen ausdrücklich geregelt sein.
- Nachweis für Audits mitdenken: Ein KPI ist erst dann brauchbar, wenn Reports, Tickets und Eskalationen sauber dokumentiert werden.
Besonders im Kontext von NIS-2 wird aus einer operativen Kennzahl schnell ein Compliance-Thema. Wenn ein Dienst geschäftskritisch oder sicherheitsrelevant ist, muss das SLA erkennbar zum Risikoprofil des Unternehmens passen. Ein Standardwert aus der Vorlage eines Providers reicht dafür oft nicht aus.
In Projekten mit KMU setze ich deshalb selten auf möglichst viele SLA-Zahlen. Sinnvoller sind wenige Kennzahlen, die den Betrieb wirklich steuern: klare Reaktionszeiten je Priorität, realistische Wiederherstellungsziele, sauber definierte Verfügbarkeit und eine dokumentierte Messlogik. Genau daraus wird ein SLA, das im Alltag trägt und im Audit standhält.
SLA-Vorlage für KMU mit praktischen Formulierungen
Ein brauchbares SLA entsteht nicht aus juristischen Floskeln, sondern aus klaren Regeln für den Betriebsalltag. Gerade in KMU muss das Dokument zwei Dinge gleichzeitig leisten. Es muss Streit vermeiden und es muss im Audit zeigen, dass kritische IT-Services bewusst gesteuert werden. Genau deshalb arbeite ich bei SLA-Vorlagen lieber mit kurzen, belastbaren Klauseln als mit langen Standardtexten, die im Ernstfall niemand sauber auslegen kann.
Muster für Geltungsbereich und Leistung
Der erste Prüfpunkt ist immer derselbe. Welche Leistungen sind wirklich enthalten, und was ausdrücklich nicht?
Beispielhafte Formulierung:
Der Dienstleister erbringt die in Anlage 1 beschriebenen IT-Services für die dort benannten Systeme und Anwendungen. Nicht ausdrücklich genannte Leistungen, insbesondere Projektarbeiten, individuelle Softwareanpassungen und Leistungen Dritter, sind nicht Bestandteil dieses Service Level Agreements.
Das wirkt unspektakulär, verhindert aber einen der häufigsten Konflikte in ausgelagerten IT-Betriebsmodellen. Ohne klare Abgrenzung wird aus einem Betriebsvertrag schnell ein Auffangbecken für jede Zusatzanforderung. Für KMU ist das wirtschaftlich riskant und im Compliance-Kontext unsauber dokumentiert.
Muster für Prioritäten und Eskalation
Prioritäten müssen sich an der Auswirkung auf das Geschäft orientieren. Nicht an der Lautstärke im Ticketsystem.
Eine kritische Störung liegt vor, wenn ein geschäftskritischer Dienst vollständig ausfällt oder ein wesentlicher Geschäftsprozess nicht mehr durchgeführt werden kann.
Eine hohe Störung liegt vor, wenn wesentliche Funktionen erheblich beeinträchtigt sind, jedoch eine Umgehungslösung besteht.
Eine mittlere Störung liegt vor, wenn die Nutzung eingeschränkt, aber der Geschäftsbetrieb nicht wesentlich unterbrochen ist.
Dazu gehört eine Eskalationslogik, die nicht nur Stufen nennt, sondern Verantwortlichkeiten festlegt:
- Stufe 1: Bearbeitung durch Service Desk oder Bereitschaft
- Stufe 2: Übergabe an technische Fachverantwortliche bei drohender Zielverfehlung
- Stufe 3: Einbindung des Managements bei kritischer Dauerstörung oder wiederholter Verletzung
In der Praxis scheitern Eskalationen selten an fehlender Technik. Sie scheitern an unklaren Rollen, fehlenden Rufnummern und nicht benannten Entscheidern. Wer NIS-2 vorbereitet, sollte genau hier sauber formulieren. Die organisatorische Einordnung zur Umsetzung von NIS-2 in Deutschland zeigt, warum solche Nachweise für externe Dienstleister nicht nur operativ, sondern auch regulatorisch relevant sind.
Muster für Mitwirkungspflichten des Kunden
Dieser Abschnitt wird oft zu knapp gehalten. Dabei entscheidet er im Streitfall regelmäßig darüber, ob Fristen tatsächlich verletzt wurden oder ob Informationen, Freigaben oder Zugänge auf Kundenseite gefehlt haben.
Der Kunde stellt sicher, dass autorisierte Ansprechpartner benannt und erreichbar sind. Erforderliche Zugänge, Freigaben, Testmöglichkeiten sowie relevante Informationen zur Störung sind unverzüglich bereitzustellen. Verzögerungen, die auf unterlassener oder verspäteter Mitwirkung beruhen, hemmen die vereinbarten Fristen für die Dauer der Behinderung.
Das ist keine einseitige Entlastung des Dienstleisters. Es bildet den realen Betriebsprozess ab. Gerade bei hybriden Umgebungen mit interner IT, Fachbereich und externem Provider lässt sich die Leistung sonst kaum fair bewerten.
Muster für Verfügbarkeit und Service-Credits
Verfügbarkeitszusagen gehören in fast jedes SLA. Sie sind aber nur brauchbar, wenn Messzeitraum, Ausschlüsse, Messmethode und Folgen einer Unterschreitung mitgeregelt sind. Branchenüblich sind abgestufte Service Credits bei verfehlten Verfügbarkeitswerten, wie sie etwa auch in den SLA-Grundsätzen von Cloud-Anbietern beschrieben werden, zum Beispiel in den AWS Service Level Agreements.
Eine neutrale Formulierung kann so aussehen:
Wird der vereinbarte Service Level im Abrechnungszeitraum unterschritten, erhält der Kunde die in Anlage 2 definierte Servicegutschrift. Weitergehende Ansprüche bleiben unberührt, soweit sie einzelvertraglich vereinbart oder gesetzlich vorgesehen sind.
Wichtig ist der wirtschaftliche Blick. Service Credits schaffen einen Ausgleich, ersetzen aber keinen tragfähigen Notfallprozess. Für ein KMU ist ein schneller Wiederanlauf oft mehr wert als eine kleine Gutschrift auf der Monatsrechnung.
Praktischer Zusatz für deutsche KMU
Ich empfehle fast immer noch einen knappen Anhang mit drei Punkten. Benannte Systeme, feste Ansprechpartner und definierte Kommunikationswege im Störungsfall. Das klingt banal, ist aber oft der Unterschied zwischen einem Dokument für die Ablage und einem SLA, das im Betrieb wirklich funktioniert.
Wer Unterstützung bei der Ausgestaltung braucht, kann Vertragsberatung, spezialisierte IT-Rechtsanwälte oder einen IT-Dienstleister mit Managed-Service-Erfahrung einbinden. Auch Deeken.Technology GmbH arbeitet mit SLA-basierten Servicezusagen für betreute IT-Umgebungen, was bei ausgelagerten Betriebsmodellen sinnvoll sein kann. Der Grundgedanke ist derselbe wie bei anderen klar geregelten Vertragsverhältnissen, etwa bei Verträgen für temporäre Unterkünfte. Leistungen, Zuständigkeiten und Ausnahmen gehören schriftlich so konkret geregelt, dass im Konfliktfall keine Auslegungslücke bleibt.
Rechtliche Aspekte und Compliance mit NIS-2 und ISO 27001
Spätestens bei Auditpflichten endet die Sichtweise, ein SLA sei nur ein technischer Anhang. Für Unternehmen mit regulatorischem Druck ist es ein dokumentierter Nachweis darüber, wie externe Leistungen kontrolliert, gemessen und durchgesetzt werden.
Seit der Einführung der DSGVO am 25. Mai 2018 ist die rechtliche Verpflichtung für klar geregelte Servicebeziehungen deutlich gestiegen. Ein Dienst, der nur 29 von 30 Tagen läuft, erreicht 96,7 % Verfügbarkeit und liegt damit oft unter dem vertraglichen Standard. Genau solche Abweichungen werden bei Audits relevant (Einordnung bei ComputerWeekly Deutschland).
Warum NIS-2 das Thema verschärft
NIS-2 verlangt keine netten Absichtserklärungen, sondern nachweisbare organisatorische und technische Steuerung. Wenn ein externer Dienstleister wesentliche Systeme betreibt, muss das Unternehmen belegen können, welche Anforderungen gelten, wie deren Einhaltung kontrolliert wird und wie bei Störungen eskaliert wird.
Dafür ist ein sauber formuliertes SLA oft der praktischste Nachweis. Es verbindet Betriebsanforderung, Sicherheitsniveau und Dokumentation. Wer tiefer in die organisatorische Perspektive einsteigen will, findet bei der Umsetzung von NIS-2 in Deutschland eine passende Einordnung.
ISO 27001 denkt in Verantwortlichkeiten
ISO 27001 verlangt geordnete Prozesse, Lieferantensteuerung und dokumentierte Maßnahmen. Genau deshalb passt ein gutes SLA so gut in ein ISMS. Es legt fest, welche Sicherheits- und Serviceanforderungen an externe Partner gestellt werden und wie deren Leistung überprüfbar bleibt.
Die Logik ist nicht auf IT beschränkt. Auch in anderen Vertragsarten zeigt sich, dass saubere Leistungs- und Verantwortungsdefinitionen Konflikte vermeiden. Wer das einmal in einem anderen Kontext sehen will, findet bei Verträge für temporäre Unterkünfte ein anschauliches Beispiel dafür, wie präzise Regelungen Nutzung, Pflichten und Haftung strukturieren.
Ohne dokumentierte Anforderungen an externe Dienstleister wird Compliance schnell zur Behauptung statt zum Nachweis.
Was rechtlich häufig fehlt
- Datenspeicherort und Sicherheitsmaßnahmen sind nicht konkret genug beschrieben.
- Kontrollrechte des Auftraggebers fehlen oder bleiben theoretisch.
- Abhängigkeiten zu Subdienstleistern sind nicht nachvollziehbar dokumentiert.
- Eskalations- und Meldewege sind betrieblich nicht auditfest.
Geschäftsführer und IT-Leiter sollten das SLA deshalb nie isoliert sehen. Es gehört in den Zusammenhang von Datenschutz, Informationssicherheit, Lieferantensteuerung und Haftungsprävention.
Implementierung und Kontrolle So lebt Ihr SLA in der Praxis
Ein unterschriebenes SLA verbessert noch keinen Service. Es wirkt erst, wenn es im Alltag gemessen, besprochen und bei Abweichungen konsequent genutzt wird. Viele Unternehmen haben formal gute Vereinbarungen, aber keine operative Routine dazu.
Entscheidend ist ein einfaches Steuerungsmodell. Monitoring liefert die Daten. Das Ticketsystem dokumentiert Reaktions- und Lösungszeiten. Service-Reviews bewerten die Ergebnisse. Und bei Verstößen gibt es einen festgelegten Folgeprozess statt spontaner Eskalation.
Drei Dinge, die in der Praxis funktionieren
- Messung automatisieren: Nutzen Sie Monitoring- und Ticketing-Werkzeuge so, dass SLA-Werte nicht manuell zusammengesucht werden müssen.
- Regelmäßig reviewen: Vierteljährliche oder halbjährliche Leistungsüberprüfungen werden für KMU empfohlen, um Probleme früh zu erkennen und Standards zu halten. Das ist in der deutschen Praxis ein sinnvoller Takt, wie die Einordnung zu SLA-Reviews bei ComputerWeekly im oben verlinkten Beitrag zeigt.
- SLA und Betriebsmodell koppeln: Wenn Services ausgelagert werden, muss das SLA direkt in Support, Bereitschaft, Change-Prozesse und Eskalation eingebettet sein. Wer dazu den organisatorischen Rahmen sucht, findet bei IT-Service-Outsourcing und der praktischen Betriebsverantwortung einen passenden Anschluss.
Ein gutes SLA ist kein Kontrollinstrument gegen den Dienstleister. Es ist die gemeinsame Betriebsgrundlage. Genau deshalb verbessert es nicht nur die Rechtssicherheit, sondern meist auch die Zusammenarbeit.
Wer ein Service Level Agreement für Managed Services, Cloud-Betrieb oder NIS-2-nahe Anforderungen sauber aufsetzen oder prüfen lassen will, kann sich an Deeken.Technology GmbH wenden. Das Unternehmen unterstützt KMU bei der Strukturierung von IT-Services, der Definition messbarer Service Levels und der Einbettung in Sicherheits- und Compliance-Vorgaben.
