Bildquelle: Pexels / Tima Miroshnichenko
Major-Incident-Kommunikation im ITSM: Welche 5 Betriebsbausteine Service-Organisationen 2026 vor dem nächsten Ausfall festziehen sollten
Viele Service-Organisationen investieren inzwischen ernsthaft in Monitoring, Rufbereitschaften und technische Runbooks. Trotzdem kippen größere Störungen noch oft an einer viel banaleren Stelle: an unklarer Kommunikation. Während Teams parallel Logs prüfen, Changes stoppen und Workarounds testen, fragen Fachbereiche, Führungskräfte und Kunden gleichzeitig nach Status, Auswirkung und nächstem Update. Wenn dafür kein belastbares Betriebsmodell existiert, wird aus einem technischen Incident sehr schnell ein Kommunikationsincident.
Die bekannten Leitfäden sind in diesem Punkt erstaunlich eindeutig. Google beschreibt Incident Management entlang der drei Kernaufgaben coordinate, communicate und control. PagerDuty trennt in seinem Incident-Response-Modell bewusst zwischen Incident Commander, Kommunikationsrolle und operativer Problemlösung. Und CISA betont in seinem aktuellen Ransomware Guide, dass Organisationen Reaktionsverfahren, Kontaktwege und Verantwortlichkeiten vor dem Ernstfall vorbereiten müssen, nicht erst währenddessen. Für ITSM-Teams ist das eine klare Botschaft: Major-Incident-Kommunikation ist kein Add-on zum Betrieb, sondern ein eigener Managementprozess im Incident.
Fünf Bausteine sollten 2026 verbindlich sitzen.
1. Eine eigene Kommunikationsrolle benennen, statt den Resolver nebenbei sprechen zu lassen
Der häufigste Fehler in Major Incidents ist organisatorisch: Die Person, die die Lage technisch am besten versteht, soll gleichzeitig das Problem führen, Rückfragen beantworten, Statusmeldungen formulieren und Stakeholder beruhigen. Genau das verlangsamt die Wiederherstellung. Google arbeitet deshalb mit klaren Rollen wie Incident Commander, Communications Lead und Operations Lead. PagerDuty beschreibt denselben Grundgedanken: Der Incident Commander steuert, die Resolver lösen, und Kommunikationsaufgaben werden bewusst getrennt.
Für klassische ITSM-Umgebungen muss das nicht bedeuten, sofort ein riesiges Krisenmodell einzuführen. Schon ein schlankes Rollenbild hilft enorm. Für jeden Major Incident sollte eindeutig festgelegt sein, wer die Lageführung übernimmt, wer technische Maßnahmen koordiniert und wer interne sowie externe Updates verantwortet. In kleineren Organisationen können zwei Rollen von einer Person getragen werden, aber nur als definierte Ausnahme. Entscheidend ist, dass Kommunikation nicht als Nebentätigkeit des lautesten Engineers endet.
Praktisch heißt das auch: Kommunikationsverantwortliche brauchen Zugriff auf Statusseite, Verteiler, Freigabewege und Vorlagen. Wer erst im Incident klären muss, wer auf welcher Seite veröffentlichen darf, ist bereits zu spät.
2. Auslösekriterien für öffentliche und interne Kommunikation vorab festziehen
Nicht jede Störung braucht sofort eine breite Meldung. Aber jede Organisation braucht vorher definierte Kriterien, wann sie intern eskaliert, wann sie Fachbereiche informiert und wann sie öffentlich kommuniziert. PagerDuty empfiehlt dafür klare, vorab abgestimmte Kriterien, etwa betroffene Produkte, Schwere des Nutzungsausfalls, Anzahl betroffener Kunden und Sichtbarkeit des Problems. Genau diese Kriterien fehlen in vielen Service-Desks. Das Ergebnis sind Diskussionen mitten im Incident, ob ein Statusseiten-Eintrag schon notwendig ist oder ob man lieber noch zehn Minuten wartet.
Im Betrieb ist diese Unschärfe teuer. Zu frühe, schlecht eingeordnete Kommunikation erzeugt unnötige Unruhe. Zu späte Kommunikation zerstört Vertrauen, weil Nutzer den Ausfall längst bemerkt haben, das Unternehmen aber noch schweigt. Sinnvoll ist deshalb eine einfache Entscheidungsmatrix, die Severity, Reichweite und erwartete Dauer zusammenführt. Beispiel: Alles, was einen geschäftskritischen Service mit breiter Nutzerwirkung länger als wenige Minuten beeinträchtigt, triggert automatisch ein initiales Stakeholder-Update und die Prüfung einer öffentlichen Meldung.
Wichtig ist, dass diese Logik nicht nur im Major-Incident-Prozesshandbuch steht, sondern im Tagesbetrieb trainiert wird. Sonst bleibt sie theoretisch und wird im Stress ignoriert.
3. Den ersten Status innerhalb weniger Minuten liefern, auch wenn noch nicht alles bekannt ist
Viele Teams warten mit der ersten Meldung zu lange, weil sie erst Ursache, Scope und Wiederherstellungszeit sauber beantworten wollen. Genau das ist in der Frühphase meist unmöglich. PagerDuty empfiehlt deshalb ausdrücklich eine erste Kommunikation innerhalb von fünf Minuten nach Start des Incident Calls, zunächst als knappe Meldung, dass der Vorfall untersucht wird. Erst danach folgt die erste Einordnung des Impact. Dieser Ablauf ist für ITSM-Teams sehr brauchbar, weil er Ehrlichkeit mit Handlungsfähigkeit verbindet.
Die erste Meldung muss nicht viel enthalten, aber sie muss etwas leisten. Sie sollte sagen, dass der Incident bekannt ist, welche Services oder Funktionen mutmaßlich betroffen sind, seit wann untersucht wird und wann das nächste Update kommt. Mehr braucht es in Minute eins oft nicht. Entscheidend ist das Signal: Wir haben den Vorfall erkannt, wir steuern ihn, und wir melden uns wieder.
Ebenso wichtig ist die Formulierung. Gute Major-Incident-Kommunikation beschreibt Kundenwirkung, nicht nur interne Technik. Ein Fachbereich kann mit „degradierte API-Latenz im Cluster B“ wenig anfangen. Er muss wissen, ob Tickets nicht gespeichert werden, Anmeldungen fehlschlagen oder Bestellungen hängen bleiben. Technische Präzision bleibt wichtig, aber die erste Sprachebene muss geschäftlich verständlich sein.
4. Update-Takt, Freigabegrenzen und Kanäle im Voraus standardisieren
Wenn ein Incident länger dauert, kippt Kommunikation oft in zwei Extreme: Entweder herrscht Funkstille, weil alle mit der Lösung beschäftigt sind, oder es entstehen hektische Ad-hoc-Updates in zu vielen Kanälen. PagerDuty empfiehlt in den ersten zwei Stunden regelmäßige Updates mindestens alle 20 Minuten und danach, je nach Verlauf, einen angepassten Rhythmus. Dieser Gedanke ist für ITSM-Organisationen besonders wertvoll, weil er Erwartungsmanagement ermöglicht.
Ein guter Standard beantwortet vier Fragen vorab. Erstens, über welche Kanäle wird kommuniziert, etwa Statusseite, Teams-Channel, Mailingliste, Service-Portal oder Telefonkette. Zweitens, wer darf welche Aussage ohne zusätzliche Managementfreigabe veröffentlichen. Drittens, in welchem Rhythmus erfolgen Updates bei kurzen, längeren und besonders kritischen Incidents. Viertens, welche Templates gibt es für Untersuchung, bestätigten Impact, Workaround, Teilwiederherstellung und Abschluss.
Gerade Freigabegrenzen werden oft unterschätzt. Wenn jede externe Statusmeldung erst durch drei Hierarchieebenen laufen muss, verliert der Betrieb wertvolle Zeit. Besser ist ein definierter Rahmen: Die Kommunikationsrolle darf innerhalb vorab genehmigter Templates selbst veröffentlichen, solange keine rechtlichen Sonderlagen oder bestätigten Datenschutzfolgen vorliegen. Das beschleunigt den Prozess massiv, ohne Governance auszuhebeln.
5. Kommunikationsqualität nach dem Incident genauso reviewen wie die Technik
Post-Incident-Reviews drehen sich häufig fast nur um Ursache, Change, Monitoring und Präventionsmaßnahmen. Das ist wichtig, reicht aber nicht. Google und PagerDuty verankern Dokumentation und Nachbereitung ausdrücklich als Teil des Incident Managements. Für ITSM bedeutet das: Auch die Kommunikationsleistung gehört in die Nachschau.
Hilfreiche Fragen sind dabei sehr konkret. Wurde der Incident früh genug deklariert. War die Rollenverteilung klar. Kam das erste Stakeholder-Update rechtzeitig. Waren die Meldungen verständlich genug für Nicht-Techniker. Wurden betroffene Regionen, Services und Workarounds konsistent beschrieben. Gab es zu viele Kanäle oder widersprüchliche Aussagen. Und mussten Fachbereiche sich Informationen selbst zusammensuchen, obwohl der Major-Incident-Prozess eigentlich greifen sollte.
Aus diesen Reviews sollten keine weich formulierten Learnings entstehen, sondern umsetzbare Änderungen: bessere Templates, vereinfachte Freigaben, präzisere Severity-Kriterien, mehr Training für Schichtleitungen oder eine feste Kommunikations-Checkliste im Major-Incident-Runbook. CISA weist zurecht darauf hin, dass Reaktionsfähigkeit auf vorbereiteten Verfahren, Kontaktlisten und Übungen beruht. Genau diese Disziplin fehlt oft, wenn Kommunikation als weiches Thema behandelt wird.
Fazit
Major-Incident-Kommunikation trennt 2026 reifen Servicebetrieb von improvisiertem Störungsmanagement. Wer Rollen, Auslösekriterien, Erstmeldung, Update-Takt und Review-Logik sauber definiert, reduziert nicht nur Verwirrung, sondern verkürzt häufig auch die technische Wiederherstellung. Denn Teams, die nicht gleichzeitig Krisenstab, Pressestelle und Resolver spielen müssen, kommen schneller zur eigentlichen Arbeit. Für ITSM-Verantwortliche ist das die entscheidende Einsicht: Gute Kommunikation ist bei Major Incidents kein Begleittext zum Betrieb, sondern ein operativer Kontrollmechanismus.