Vier Stunden – aber wofür eigentlich? SLA und ISO 27001 für IT-Dienstleister

Montagmorgen, 8:03 Uhr. Beim Kunden können 38 Mitarbeiter nicht auf den Terminalserver zugreifen. Im Ticketsystem landet ein Incident mit hoher Priorität.

Um 11:57 Uhr ruft ein Techniker zurück.

„Wir haben das Ticket übernommen und kümmern uns.“

Um 16:40 Uhr läuft der Terminalserver wieder.

Am nächsten Morgen beschwert sich der Kunde: „Sie haben doch vier Stunden zugesagt. Unser Betrieb stand fast den ganzen Tag!“

Der IT-Dienstleister widerspricht: „Wir haben innerhalb von vier Stunden reagiert. Das SLA wurde eingehalten.“

Beide zeigen auf dieselbe Zeile im Vertrag: Reaktionszeit bei kritischen Störungen: vier Stunden.

Der Kunde hatte verstanden: Nach spätestens vier Stunden können unsere Mitarbeiter wieder arbeiten. Der Dienstleister hatte gemeint: Innerhalb von vier Stunden meldet sich jemand und beginnt mit der Bearbeitung.

Auf dem Papier besitzt das Unternehmen ein Service Level Agreement. Im Betrieb besitzt es zwei verschiedene Erwartungen mit derselben Vier davor. Das ist keine Steuerung. Das ist ein zukünftiger Streit mit Stoppuhr.

Die kurze Antwort

Die ISO 27001 verlangt kein Service Level Agreement. Wenn ein IT-Dienstleister aber eine sicherheitsrelevante Leistung zugesichert hat, muss er Prozesse besitzen, die dafür sorgen, dass die Zusage erfüllt wird.

Genau hier greift Abschnitt 8.1. Notwendige Prozesse müssen geplant, umgesetzt und gesteuert werden. Dafür braucht die Organisation geeignete Kriterien. „Vier Stunden“ ist noch kein brauchbares Kriterium, solange unklar bleibt, wann die Uhr beginnt, welche Servicezeit gilt, was als Reaktion zählt und wie das Ergebnis nachgewiesen wird.

In ziemlich normalem Deutsch: Wenn ich das zugesichert habe, muss ich auch Prozesse haben, die dafür sorgen, dass es erfüllt wird.

Das betrifft nicht jede kaufmännische Kennzahl. Eine zugesagte Verfügbarkeit der betreuten Kunden-IT, eine Wiederherstellungszeit oder die Reaktion auf einen kritischen Ausfall berühren jedoch unmittelbar die Verfügbarkeit von Informationen und Systemen. Damit sind wir mitten im ISMS und nicht in einem beliebigen IT-Service-Blog.

Der Servicekatalog sagt was – das SLA sagt wie gut

Der Servicekatalog für IT-Dienstleister beschreibt, welche wiederholbaren Leistungen grundsätzlich angeboten werden. Vertrag und Leistungsbeschreibung legen fest, was der konkrete Kunde beauftragt hat. Das Betriebsführungshandbuch übersetzt die Vereinbarung in seine Umgebung.

Ein SLA ergänzt eine andere Dimension: Mit welcher vereinbarten Qualität soll die Leistung erbracht werden?

Beim Service „Betrieb des Terminalservers“ können beispielsweise relevant sein:

• vereinbarte Service- und Bereitschaftszeiten;
• Verfügbarkeit des Dienstes;
• Reaktionszeit bei unterschiedlichen Störungsklassen;
• Zeit bis zur Wiederherstellung;
• Eskalations- und Informationspflichten;
• Messverfahren und Ausnahmen.

Ohne den Service bleibt das Service Level in der Luft. Eine Reaktionszeit kann nur für etwas gelten, dessen Umfang und Verantwortungsgrenze bekannt sind. Wer ausschließlich das Betriebssystem betreut, kann nicht ohne Weiteres die Verfügbarkeit einer fremden Fachanwendung garantieren.

Abschnitt 8.1 macht aus der Zusage einen Betriebsprozess

Unser ausführlicher Beitrag erklärt, wie Unternehmen nach ISO 27001 Prozesse planen und steuern. Für das SLA ist der entscheidende Punkt: Ein erwartetes Ergebnis braucht einen Ablauf und Kriterien, nach denen dieser Ablauf gesteuert wird.

Bei einer zugesagten Reaktionszeit müssen deshalb praktische Antworten existieren:

1. Über welchen Weg muss die Störung eingehen?
2. Wann beginnt die Messung?
3. Welche Servicezeiten werden berücksichtigt?
4. Wie wird die Priorität bestimmt?
5. Wer übernimmt, wenn der erste Ansprechpartner nicht verfügbar ist?
6. Welche Handlung zählt als qualifizierte Reaktion?
7. Wann stoppt die Uhr?
8. Wo wird das Ergebnis nachvollziehbar dokumentiert?

Das muss kein 25-seitiges SLA-Verfahren werden. Vieles kann im Ticketsystem, in Prioritätsregeln, Bereitschaftsplänen und Eskalationen stecken. Aber der Ablauf darf nicht davon abhängen, dass zufällig der richtige Techniker sein persönliches Postfach öffnet.

Wie Meldungen in eine gemeinsame Arbeitslage gelangen, beschreibt unser Artikel zum Ticketsystem für IT-Dienstleister. Wird eine kritische Meldung nur telefonisch einem Mitarbeiter erzählt und nie erfasst, kann keine belastbare Vier-Stunden-Frist gesteuert werden.

Reaktionszeit ist nicht Wiederherstellungszeit

Viele SLA-Streitigkeiten beginnen damit, dass unterschiedliche Zeiten in einen Topf geworfen werden.

Eine belastbare Vereinbarung darf daher nicht bloß „vier Stunden“ sagen. Sie muss erkennen lassen, welche dieser Zeiten gemeint ist und welches beobachtbare Ereignis Beginn und Ende markiert.

Der Kunde darf die Priorität nicht allein herbeizaubern

Im Ticket steht „DRINGEND!!!“. Damit ist noch nicht entschieden, ob ein kritischer Incident vorliegt.

Die Priorität sollte sich aus vereinbarten Kriterien ergeben, zum Beispiel:

• Wie viele Benutzer oder Standorte sind betroffen?
• Ist ein geschäftskritischer Service vollständig ausgefallen?
• Existiert ein brauchbarer Workaround?
• Sind Vertraulichkeit, Integrität oder Verfügbarkeit erheblich gefährdet?
• Welche zeitlichen Folgen entstehen für den Kunden?

Kunde und Dienstleister müssen diese Kriterien verstehen. Sonst wird jede vergessene Passwortänderung zur höchsten Priorität, während ein schleichend fehlerhaftes Backup unauffällig im normalen Eingang liegt.

Auch der Asset- und Konfigurationsbezug im Kundenbetrieb ist wichtig. Erst wenn klar ist, welcher Service und welches System betroffen sind, lassen sich Zuständigkeit, Auswirkungen und richtige SLA-Regel bestimmen.

Wann beginnt die Uhr – und wann bleibt sie stehen?

Freitag, 17:58 Uhr, geht eine Störung ein. Die Servicezeit endet um 18:00 Uhr. Beginnen die vier Stunden sofort, laufen am Montag weiter oder gilt für kritische Systeme eine gesonderte Rufbereitschaft?

Keine Antwort ist automatisch richtig. Falsch ist nur, diese Frage beim Ausfall erstmals auszudiskutieren.

Dasselbe gilt für Wartezeiten. Der Techniker braucht Logdaten oder eine Freigabe des Kunden. Stoppt die Uhr? Wenn ja: ab der Rückfrage, ab ihrer Bestätigung oder erst, nachdem ein definierter Kontaktweg genutzt wurde? Kann der Dienstleister die Zeit unbegrenzt anhalten, indem er irgendeine Rückfrage stellt?

Sinnvolle Regeln behandeln mindestens:

• zugelassene Meldewege;
• Servicezeiten und Bereitschaft;
• vollständige Mindestangaben;
• Mitwirkung des Kunden;
• Abhängigkeiten von Herstellern und Unterauftragnehmern;
• geplante Wartung;
• Beginn, Unterbrechung und Ende der Messung.

Das ist keine Einladung zu juristischer Ornamentik. Es ist eine Arbeitsgrundlage für Service Desk und Technik.

Verfügbarkeit muss am richtigen Gegenstand gemessen werden

Der Server antwortet auf Ping. Die Fachanwendung zeigt trotzdem nur eine Fehlermeldung. War der Service verfügbar?

Wenn die zugesicherte Leistung der nutzbare Anwendungsdienst ist, reicht ein grüner Hostsensor nicht. Messpunkt und Service müssen zusammenpassen. Unser Beitrag über Logging und Monitoring zeigt, weshalb technische Signale erst im richtigen Kontext handlungsfähig werden.

Bei einer Verfügbarkeitskennzahl muss außerdem feststehen:

• welcher Service betrachtet wird;
• in welchem Messzeitraum;
• während welcher vereinbarten Betriebszeit;
• an welchem Messpunkt;
• welche Wartungszeiten oder Ausschlüsse gelten;
• welche Datenquelle maßgeblich ist;
• wer Abweichungen prüft.

99,9 Prozent sehen beeindruckend aus. Ohne Bezugszeitraum, Messpunkt und Definition des Ausfalls sind sie allerdings nur drei Neunen in einem Vertrag.

Messen heißt nicht, einen Zahlenfriedhof anzulegen

Abschnitt 9.1 unterstützt die Logik aus 8.1: Die Organisation muss bestimmen, was sie überwacht und misst, mit welchen Methoden und wann Ergebnisse analysiert und bewertet werden. Für ein sicherheitsrelevantes SLA bedeutet das nicht, jeden Mausklick zu vermessen.

Das Ticketsystem kann Reaktions- und Wiederherstellungszeiten liefern. Monitoring kann Verfügbarkeitsdaten beitragen. Rufbereitschaft und Eskalationen zeigen, ob der Prozess auch außerhalb normaler Zeiten funktioniert.

Entscheidend ist, dass jemand die Ergebnisse verwendet. Wenn ein zugesagtes Service Level seit vier Monaten verfehlt wird und die Auswertung nur eine hübsche rote Linie produziert, ist die Leistung nicht gesteuert.

Wiederholte Zielverletzungen können ein Problem Management für IT-Dienstleister auslösen. Die Ursache kann in Kapazität, Personalplanung, Technik, einer unrealistischen Zusage oder einer unklaren Leistungsgrenze liegen. Eine notwendige dauerhafte Änderung läuft anschließend kontrolliert über das Change Management im Kundenbetrieb.

Nicht jede Servicekennzahl gehört ins ISMS

Die durchschnittliche Zeit bis zum Rückruf bei einer Preisanfrage ist wahrscheinlich kein Informationssicherheitsziel. Eine zugesagte Wiederherstellung eines kritischen Kundendienstes nach einem Ausfall kann sehr wohl sicherheitsrelevant sein.

Der Zusammenhang entsteht nicht durch die Abkürzung SLA, sondern durch den Inhalt:

• Betrifft die Zusage Vertraulichkeit, Integrität oder Verfügbarkeit?
• Gehört die Leistung zum Anwendungsbereich des ISMS?
• Ist sie eine relevante Kunden- oder Vertragsanforderung?
• Wurde sie als Informationssicherheitsziel oder als Kriterium eines sicherheitsrelevanten Prozesses festgelegt?

Nur weil Vertrieb und Kunde eine Prozentzahl mögen, muss daraus kein neues ISMS-Dashboard werden. Umgekehrt darf eine sicherheitsrelevante Zusage nicht als „reines Vertragsthema“ aus dem Betrieb verschwinden.

Typische Fehler

Automatische Bestätigung gilt als Reaktion

Das Ticket wurde in drei Sekunden bestätigt, aber niemand hat Auswirkungen, Zuständigkeit oder nächste Schritte betrachtet. Eine Empfangsbestätigung beweist den Eingang, nicht die qualifizierte Bearbeitung.

Jede Störung ist kritisch

Dann konkurrieren Terminalserverausfall, einzelne defekte Maus und vergessene Verteilergruppe um dieselbe Eskalation. Prioritätskriterien werden wertlos.

Verfügbarkeit wird dort gemessen, wo es bequem ist

Das Infrastrukturmonitoring ist grün, während der Kunde den Dienst nicht nutzen kann. Gemessen wurde ein technischer Bestandteil, zugesagt war eine Leistung.

Das SLA passt nicht zum eingekauften Betrieb

Verfügbarkeit rund um die Uhr wurde verkauft, aber nachts existieren weder Rufbereitschaft noch Entscheidungsbefugnis. Ein Vertrag erzeugt keinen Techniker durch bloße Willenskraft.

Abweichungen bleiben folgenlos

Der Monatsbericht zeigt wiederholte Verletzungen. Niemand untersucht Ursache, Kapazität oder Prozess. Damit wird gemessen, aber nicht gesteuert.

So starten Sie pragmatisch

Nehmen Sie eine einzige bestehende sicherheitsrelevante Zusage, beispielsweise „vier Stunden Reaktionszeit bei kritischen Störungen“. Legen Sie daneben einen echten Incident und beantworten Sie gemeinsam mit Service Desk und Technik:

1. Woran wurde die zutreffende Priorität erkannt?
2. Wann begann und endete die Frist?
3. Welche Servicezeit galt?
4. Was war die qualifizierte Reaktion?
5. Wer übernahm und wer vertrat ihn?
6. Welche Daten belegen den Ablauf?
7. Wurde das Ergebnis erreicht?

Wenn drei Mitarbeiter drei unterschiedliche Antworten geben, brauchen Sie nicht zuerst ein neues SLA-Werkzeug. Sie brauchen eine eindeutige Regel und einen Ablauf, der diese Regel im echten Betrieb trägt.

Interesse geweckt?

Sie möchten sicherheitsrelevante Leistungszusagen so definieren, dass Kundenbetrieb und ISMS sie tatsächlich erfüllen können? Sprechen Sie mit uns.