Inhalt in Kürze
- IT-Service-Level-Agreements sind die vertragliche Grundlage für messbare IT-Servicequalität — ohne SLA gibt es keine Eskalations-Basis im Streitfall
- Pflichtbestandteile: Leistungsbeschreibung, Verfügbarkeit, Reaktions- und Lösungszeiten, Servicezeiten, Eskalationsstufen, Reporting, Konsequenzen bei Nichterfüllung
- Realistische Reaktionszeiten: 4 Stunden für Standard-Tickets während Servicezeit, 1 Stunde für kritische Vorfälle — alles unter 1 Stunde wird im KMU-Bereich oft nur als Marketing-Versprechen ausgesprochen
- 99,5 % Verfügbarkeit erlaubt ~3,6 Stunden Ausfall pro Monat — für die meisten Hamburger KMU der wirtschaftlich sinnvolle Standardwert
- NIS-2 verschärft die SLA-Anforderungen: Incident-Response-Prozesse und 24-Stunden-Meldefristen müssen vertraglich abgesichert sein
IT-Service-Level-Agreements (SLAs) sind Verträge zwischen IT-Dienstleister und Kunde, die die Erwartungen und Anforderungen an die IT-Services verbindlich definieren. Sie sind Kern der IT-Service-Management-Praxis und entscheiden im Streitfall, wer was leisten muss. Ohne SLA gibt es keine messbare Service-Qualität. Und ohne messbare Qualität entstehen genau die Konflikte, die wir bei Hamburger Erstmandaten so oft sehen — „der hat zugesichert, dass…”, „aber das war doch verstanden…”
In diesem Artikel räumen wir mit Mythen auf, zeigen die Pflichtbestandteile eines guten SLA und geben Ihnen praktische Werte aus der Hamburger KMU-Realität.
Was ein gutes IT-SLA leistet
Ein sauberes SLA hat drei Funktionen:
- Erwartungsmanagement. Beide Seiten wissen, was zugesichert ist — und was nicht. Keine bösen Überraschungen.
- Mess-Grundlage. Verfügbarkeit, Reaktionszeit, Lösungszeit lassen sich nur prüfen, wenn sie definiert sind.
- Eskalations-Grundlage. Bei wiederholter Nichterfüllung gibt es klare Konsequenzen — Service-Credits, Eskalation, im Extremfall Sonder-Kündigung.
Wir sehen bei Hamburger Übernahme-Mandaten regelmäßig zwei Extreme: SLAs, die wie Romane gelesen werden müssen (50 Seiten, niemand versteht’s, niemand misst’s). Oder gar keine SLAs (“der lief halt immer…”). Beides ist Mist.
Pflichtbestandteile eines IT-SLA
Ein praxistaugliches SLA muss mindestens diese Bausteine enthalten:
- Leistungsbeschreibung. Was genau wird erbracht? Welche Geräte sind im Scope? Welche Anwendungen? Was ist explizit ausgeschlossen?
- Verfügbarkeit. Welche Verfügbarkeit wird zugesichert (z.B. 99,5 % pro Monat) und in welchem Zeitfenster (Geschäftszeit oder 24/7)?
- Reaktions- und Lösungszeiten. Definiert nach Priorität (kritisch / hoch / mittel / niedrig) und Servicezeit.
- Servicezeiten. Wann sind Mitarbeiter erreichbar? Was passiert nachts/am Wochenende? Sonderregelungen für Notfälle.
- Eskalationsstufen. Wer wird wann informiert? Erste Stufe Service-Desk, zweite Teamleiter, dritte Geschäftsführung.
- Reporting-Pflichten. Welche Reports? Wie oft? Mit welchen Kennzahlen? Quartalsweise SLA-Review-Termin.
- Konsequenzen bei Nichterfüllung. Service-Credits, Pönalen, Sonder-Kündigungsrecht.
- Mitwirkungspflichten des Kunden. Was muss der Kunde liefern (Zugänge, Hardware, Ansprechpartner)?
- Anpassungs- und Kündigungsregeln. Wie werden SLAs angepasst? Welche Kündigungsfristen?
IT-Wiederherstellungszeiten — RTO/RPO im KMU 2026
IT-Wiederherstellungszeiten beschreiben, wie schnell ein IT-System nach einem Ausfall wieder verfügbar sein muss. Zentrale Metriken: RTO (Recovery Time Objective, max. Ausfallzeit) und RPO (Recovery Point Objective, max. Datenverlust). Im KMU-Standard 2026: RTO 4-8 Stunden für unkritische Systeme, 1 Stunde für ERP/E-Mail, 15 Minuten für VoIP. Vertraglich im IT-SLA festgehalten.
RTO und RPO sind die beiden Pflicht-KPIs jedes belastbaren SLA — und seit dem NIS-2-Umsetzungsgesetz Pflichtbestandteil dokumentierter Notfallpläne. Das BSI verweist im Standard 200-4 (Business Continuity Management) auf RTO/RPO als Grundgerüst jeder Wiederanlauf-Planung.
Praxis-Richtwerte aus Hamburger KMU-Mandaten:
| System-Klasse | Beispiele | RTO | RPO | Verfügbarkeit |
|---|---|---|---|---|
| Geschäftskritisch | VoIP, Domain-Controller, ERP-Frontend | 15 Min – 1 Std | 1 Std | 99,9 % |
| Wichtig | E-Mail, Fileserver, Buchhaltung | 4 Std | 4 Std | 99,5 % |
| Unkritisch | Archiv, Test, Druckserver | 8 – 24 Std | 24 Std | 99 % |
Je System einzeln festlegen — ein VoIP-Ausfall stoppt sofort den Vertrieb, ein Archivserver darf einen Arbeitstag fehlen. Die Werte gehören als Anhang ins SLA, mit Verweis auf den Disaster-Recovery-Plan und die konkrete Abgrenzung RTO vs. RPO. Wer im NIS-2-Scope ist, muss zusätzlich nachweisen, dass RTO/RPO regelmäßig getestet werden — Backup-Restore-Tests, Failover-Übungen, dokumentierte Wiederanlauf-Protokolle.
Verfügbarkeit verstehen: Was 99,5 % wirklich bedeutet
Verfügbarkeit ist die meistdiskutierte SLA-Kennzahl — und meistmissverstandene. Hier die rohen Zahlen:
| Verfügbarkeit | Maximaler Ausfall pro Monat | Typischer Anwendungsfall |
|---|---|---|
| 99 % | 7,3 Stunden | Reine Bürokommunikation, kein E-Commerce |
| 99,5 % | 3,6 Stunden | KMU-Standard, Geschäftszeit |
| 99,9 % | 43 Minuten | Web-Shops, kritische Anwendungen |
| 99,95 % | 22 Minuten | E-Commerce, Banken-Schalter |
| 99,99 % | 4 Minuten | Hochverfügbare Industrie-Steuerung |
Wichtig: Höhere Verfügbarkeit kostet exponentiell mehr. Redundante Server, geclusterte Datenbanken, zwei Rechenzentren mit Geo-Replikation — das sind ganz andere Kostenklassen als ein Single-Server mit Backup. Für die meisten Hamburger KMU sind 99,5 % im Geschäftszeitraum die wirtschaftlich sinnvolle Wahl.
Reaktionszeit ≠ Lösungszeit
Eine der häufigsten Verwechslungen:
Zeit von der Ticket-Eröffnung bis zum Beginn der Bearbeitung durch einen qualifizierten Mitarbeiter. Diese Zeit lässt sich verbindlich zusichern.
Zeit von der Ticket-Eröffnung bis zur Behebung des Problems. Diese Zeit hängt von vielen Faktoren ab (Hardware-Lieferung, Hersteller-Support) und kann nur als Zielwert garantiert werden — nicht verbindlich.
Wer mit ‘garantierten Lösungszeiten’ wirbt, weiß meistens nicht, was er verspricht — oder versteckt’s im Kleingedruckten. Eine seriöse Reaktionszeit-Zusicherung sieht so aus:
| Priorität | Definition | Reaktionszeit (Servicezeit) |
|---|---|---|
| Kritisch | Komplettausfall, Sicherheits-Vorfall | 1 Stunde |
| Hoch | Mehrere Mitarbeiter betroffen, Workaround möglich | 4 Stunden |
| Mittel | Einzelner Mitarbeiter, Workaround vorhanden | 8 Stunden |
| Niedrig | Wunsch, Anfrage ohne Dringlichkeit | 24 Stunden |
Bei hagel IT garantieren wir vertraglich 4 Stunden für Standard-Tickets in Geschäftszeit — der praktische Anspruch ist 30-60 Minuten. Diese Lücke zwischen Vertrag und Praxis ist Absicht: lieber unter-versprechen und über-liefern.
Vertraglich haben wir vier Stunden Reaktionszeit. Aber unser Anspruch ist: Wenn es bei Ihnen brennt, helfen wir sofort. Dafür haben Sie die Geschäftsführer direkt als Ansprechpartner.
Jens HagelGeschäftsführer, hagel IT-Services GmbH
Die typischen SLA-Fallen
Bei Übernahme-Mandaten in Hamburg sehen wir immer wieder dieselben Probleme im Bestand:
- Pseudo-Reaktionszeiten — 15 Minuten als 'Reaktionszeit' definiert, aber gemessen ab automatisierter Empfangsbestätigung. Der Techniker meldet sich erst nach 4 Stunden.
- Unrealistische Lösungszeiten — '4 Stunden Lösungszeit' für jedes Problem zugesichert, in der Praxis nicht haltbar bei Hardware-Defekten.
- Verfügbarkeit ohne Messmethode — '99,9 % Verfügbarkeit' versprochen, aber niemand misst's. Im Streitfall fehlt die Datengrundlage.
- Servicezeiten zu eng — 9-17 Uhr Mo-Fr, aber Logistik-Kunde fährt Frühschicht ab 5 Uhr. Lücke nicht gesehen.
- Pönalen ohne Wirkung — Service-Credits in Höhe von 50 Euro pro Vorfall bei einem 5.000-Euro-Monatsvertrag. Ohne Hebel.
- Reporting fehlt — Zugesicherte Werte werden nie reportet, niemand prüft die Einhaltung.
NIS-2 verändert die SLA-Anforderungen
Das NIS-2-Umsetzungsgesetz verlangt seit Dezember 2025 eine 24-Stunden-Erstmeldung bei Sicherheits-Vorfällen ans BSI. Das geht nur, wenn der IT-Dienstleister den Vorfall innerhalb von 24 Stunden erkennt und meldet. Konsequenzen für SLAs:
- Incident-Response-Prozess vertraglich. Wer meldet was wann an wen? Welche Kommunikationswege? Wer dokumentiert?
- Lieferanten-Verantwortung. NIS-2 verlangt Bewertung und Steuerung von Zulieferern. Im SLA müssen die Verantwortlichkeiten klar geregelt sein.
- Schulungs- und Audit-Rechte. Der Kunde muss die Sicherheits-Standards des Dienstleisters prüfen können — vertraglich abgesichert.
Bei NIS-2-Beratung in Hamburg prüfen wir auch die bestehenden SLAs unserer Kunden — und passen sie ggf. an die neuen Anforderungen an.
Aus der Praxis: Was Kunden wirklich brauchen
Wir wollen uns nicht um IT kümmern müssen. Wenn ein neuer Mitarbeiter kommt: Laptop da, E-Mail eingerichtet, Telefon funktioniert. Wenn jemand geht: Zugänge gesperrt. Einfach. Zuverlässig.
Hinter diesem einfachen Wunsch steckt ein präzises SLA:
- Onboarding-Lead-Time: Neuer Mitarbeiter angemeldet → Account und Hardware fertig in 5 Werktagen
- Offboarding-Lead-Time: Mitarbeiter ausgeschieden → Zugänge sofort gesperrt, Hardware-Rückgabe in 5 Werktagen
- Standard-Reaktionszeit: 4 Stunden in Servicezeit (Mo-Fr 8-18 Uhr)
- Eskalation: Bei Komplettausfall direkt an die Geschäftsführung
- Reporting: Quartalsweise SLA-Performance-Review
Solche Werte sehen unspektakulär aus — sind in der täglichen Praxis aber das, was den Unterschied macht. Wer das systematisch liefert, hat einen zufriedenen Kunden. Wer es nicht liefert, hat Streit.
SLA und Vertragslaufzeit
Lange SLA-Diskussionen werden oft an unflexiblen Vertragslaufzeiten festgezurrt. Wer 5 Jahre gebunden ist, kann SLAs schwer anpassen. Wer 1 Jahr Laufzeit hat, kann jährlich nachverhandeln. Mehr dazu in unserem Artikel über Vertragslaufzeiten im IT-Bereich und beim IT-Audit mit den richtigen Fragen an den Dienstleister.
Bei jedem Vertragswechsel die SLA-Werte aus den letzten 12 Monaten als Realitäts-Check nehmen. Welche Reaktionszeit war im Schnitt nötig? Wie oft kam es zu kritischen Vorfällen? Wo gab es Eskalationen? Daraus die SLA-Werte ableiten — nicht aus theoretischen Wunschvorstellungen.
Was ein gutes SLA in Euro wert ist
Bei einem Hamburger Logistik-Kunden hatten wir kürzlich einen Vorfall: Ein gehackter Drucker im Gäste-WLAN ermöglichte einen Lateral-Move auf das Buchhaltungs-System. Reaktionszeit: 28 Minuten von Erkennung bis Isolation. Schaden: 0 Euro (kein Datenabfluss, kein Lösegeld). Mit einer 4-Stunden-SLA-Reaktion wäre derselbe Vorfall vermutlich zu Datenabfluss und Erpressung eskaliert. Geschätzter potentieller Schaden: hoher fünfstelliger Bereich.
Genau dafür zahlt man ein gutes SLA — nicht für die Theorie auf dem Papier.
SLA als Teil des Managed-IT-Service
Bei Managed IT-Services in Hamburg liefern wir das SLA als Teil des Hauptvertrags — nicht als 50-Seiten-Anhang. Klar verständlich, mit messbaren Werten, quartalsweisem Review. Wer mehr braucht (Hochverfügbarkeit, 24/7, Branchen-spezifische Anforderungen), bekommt das individuell vereinbart. Falls Sie aktuell mit einem schlechten SLA leben — eine pragmatische SLA-Verhandlung als IT-Service Hamburg gehört zum Wechsel-Service dazu.
SLA-Probleme mit dem aktuellen IT-Dienstleister?
15 Minuten Erstgespräch. Wir prüfen Ihren bestehenden Vertrag und zeigen, was realistisch verbessert werden kann.
Termin buchen →Ihr nächster Schritt
Bringen Sie zum Termin am besten eine Kopie Ihres aktuellen SLA mit (oder die zugesicherten Reaktionszeiten und Verfügbarkeits-Werte). In 15 Minuten haben wir eine ehrliche Einschätzung, ob das marktüblich, übertrieben oder lückenhaft ist — und was Sie konkret tun können.
