Erreicht der Betrieb nachts im Ausfall die richtigen Entscheider?

Eine Notfallnummer beruhigt nur, solange niemand sie im Ernstfall anrufen muss. In einer schweren IT-Störung zählt nicht, ob irgendwo eine Kontaktliste existiert. Entscheidend ist, ob der Betrieb nachts die richtigen Personen erreicht, ob diese Personen entscheiden dürfen und ob klar ist, wann die nächste Eskalationsstufe greift.

Incident-Response-Leitfäden beschreiben, wie Organisationen Sicherheitsvorfälle erkennen, bewerten, eindämmen und nachbereiten. CISA, NIST und der BSI IT-Grundschutz nutzen dafür unterschiedliche Begriffe, zielen aber auf denselben Kern: Eine Krise braucht vorbereitete Abläufe, Zuständigkeiten und Kommunikation. Für ITSM-Generalisten ist das wichtig, weil ein Ausfall selten nur technisch bleibt. Er betrifft Service Desk, Fachbereiche, Management, Provider, Datenschutz, Kommunikation und manchmal Kunden direkt.

Kontaktlisten altern schneller als Notfallpläne

Die Schwachstelle liegt oft nicht im fehlenden Dokument, sondern in seinem Zustand. Telefonnummern ändern sich, Rollen wechseln, Providerkontakte ziehen um, Bereitschaften rotieren und Vertretungen werden nicht sauber nachgetragen. Solange kein Ernstfall eintritt, wirkt die Liste ausreichend. Erst nachts zeigt sich, ob eine Nummer noch stimmt, ob der Angerufene erreichbar ist und ob er überhaupt weiß, welche Entscheidung von ihm erwartet wird.

Besonders riskant sind Listen, die nur Namen sammeln. Ein Sicherheitsvorfall oder ein großer Ausfall braucht nicht irgendeinen Kontakt, sondern eine klare Rolle. Wer darf ein System vom Netz nehmen? Wer informiert Kunden? Wer entscheidet über externe Unterstützung? Wer spricht mit Datenschutz, Einkauf oder Geschäftsführung? Wenn solche Rechte offen bleiben, entsteht im Krisenstab eine Warteschleife. Technikteams arbeiten weiter, aber wichtige Entscheidungen hängen fest.

Erreichbarkeit ist keine Zuständigkeit

Ein erreichbarer Mensch löst noch kein Problem, wenn er nur weiterleiten kann. Deshalb sollte jede Notfallrolle drei Dinge enthalten: Zweck, Entscheidungsrahmen und Vertretung. Der Zweck erklärt, warum diese Person kontaktiert wird. Der Entscheidungsrahmen sagt, was sie sofort freigeben darf. Die Vertretung verhindert, dass Urlaub, Krankheit oder Zeitzonen die Eskalation blockieren.

Für den Service Desk ist diese Klarheit besonders wichtig. Dort laufen Meldungen, Rückfragen und Stimmungsbilder zusammen. Wenn der Service Desk nicht weiß, wann aus einer Störung ein meldepflichtiger Sicherheitsvorfall, ein Kundenkommunikationsthema oder ein Managementfall wird, bleibt die Lage zu lange technisch eingeordnet. Die ersten Minuten werden dann mit Suchen, Nachfragen und Absichern verbraucht.

Providerkontakte brauchen echte Eskalationswege

Viele kritische Services hängen an externen Dienstleistern. Auch dort reicht eine allgemeine Supportadresse nicht. Im Ausfall muss klar sein, welcher Vertrag greift, welche Reaktionszeiten gelten, welche Rufnummer für schwere Vorfälle gedacht ist und wann der nächste Eskalationskontakt beim Provider eingeschaltet wird. Ein Ticketportal ist hilfreich, aber es ersetzt keine belastbare Notfallkommunikation.

Die Verantwortung bleibt trotzdem intern. Ein Provider kann nur so schnell helfen, wie die eigene Organisation ihn sauber aktiviert. Dazu gehören Kundennummern, Vertragsreferenzen, betroffene Services, Priorität, technische Erstinformationen und eine erreichbare interne Entscheidungsstelle. Fehlt eines davon, wird der externe Kontakt zum neuen Engpass.

Der Probealarm zeigt die Wahrheit

Eine Kontaktliste sollte nicht nur geprüft, sondern geprobt werden. Ein kurzer Probealarm muss nicht dramatisch sein. Es reicht, außerhalb der Komfortzone zu testen: Wer nimmt ab? Wer ruft zurück? Wer erkennt seine Rolle? Wer weiß, wo der aktuelle Lagekanal liegt? Wer kann innerhalb weniger Minuten eine Freigabe geben? Solche Tests zeigen mehr als jede Dokumentenprüfung.

Wichtig ist, den Test nicht als Misstrauenskontrolle zu verkaufen. Er schützt die Betroffenen. Niemand möchte im echten Ausfall zum ersten Mal erfahren, dass er als Entscheider eingetragen ist oder dass eine alte Mobilnummer noch im Plan steht. Ein Probealarm macht sichtbar, wo Organisation, Technik und Kommunikation auseinanderlaufen.

Gute Eskalation hat wenige klare Stufen

Zu viele Eskalationsstufen machen den Plan langsam. Zu wenige Stufen überfordern einzelne Personen. Ein brauchbarer Ablauf unterscheidet deshalb klar zwischen Erstannahme, technischer Koordination, Serviceverantwortung, Security-Bewertung, Managemententscheidung und externer Kommunikation. Nicht jede Störung braucht alle Stufen. Aber im Plan muss sichtbar sein, welche Schwelle welche Rolle aktiviert.

Diese Schwellen sollten praktisch formuliert sein. Beispiele sind Kundenwirkung, Datenabflussverdacht, Ausfall eines kritischen Geschäftsprozesses, überschrittene Wiederherstellungszeit, fehlende Providerreaktion oder öffentlicher Kommunikationsdruck. So kann der Betrieb schneller entscheiden, statt abstrakte Prioritätsklassen zu diskutieren.

Nach dem Ausfall muss die Liste besser werden

Die Nachbereitung ist der Moment, in dem eine Kontaktliste ihren Wert beweist. Jede falsche Nummer, jede unklare Rolle, jede zu späte Entscheidung und jede unnötige Rückfrage gehört in die Verbesserung. Dabei geht es nicht um Schuld, sondern um Reaktionsfähigkeit. Ein Notfallplan ist kein Archivdokument. Er muss nach jedem Test und jedem echten Vorfall leichter nutzbar werden.

Für ITSM entsteht daraus eine einfache Regel: Notfallkontakte gehören in denselben Pflegezyklus wie Services, Provider, Bereitschaften und Kommunikationswege. Wer sie nur einmal im Jahr formal bestätigt, übersieht die operative Realität. Wer sie regelmäßig testet, Rollen mit Entscheidungsrechten verbindet und Providerwege sauber dokumentiert, gewinnt im Ernstfall Zeit. Und genau diese Zeit entscheidet, ob eine Störung beherrschbar bleibt oder zum Organisationsproblem wird.

Quellen und Einordnung: NIST Computer Security Incident Handling Guide, CISA Cybersecurity Incident and Vulnerability Response Playbooks, BSI IT-Grundschutz. Bildquelle: Pexels, Foto-ID 887751. Stand der Quellenprüfung: 01.07.2026.