Ein Major Incident braucht eine Führungsrolle, nicht den größten Verteiler

Ein zentraler Dienst fällt aus. Innerhalb weniger Minuten sitzen Administratoren, Dienstleister, Fachbereich, IT-Leitung und Geschäftsführung in derselben Besprechung. Alle fragen nach dem Stand, mehrere Personen schlagen Änderungen vor und niemand hält fest, welche davon bereits ausgeführt wurden.

Viele Teilnehmende erzeugen noch keine Führung. Im Gegenteil: Je größer der Verteiler, desto leichter werden technische Arbeit, Geschäftsentscheidung und Kommunikation vermischt.

Ein Major Incident braucht deshalb eine Rolle, die den Vorfall führt, ohne selbst jede technische Aufgabe zu übernehmen.

„Major“ beschreibt die Wirkung, nicht die Lautstärke

Eine schwere Störung sollte nicht erst dann zum Major Incident werden, wenn genügend Personen eskalieren. Vorab definierte Kriterien erleichtern eine frühe und konsistente Entscheidung.

Relevante Signale können sein:

• Ausfall eines geschäftskritischen Services,
• erhebliche Auswirkung auf Kunden, Produktion oder Lieferfähigkeit,
• mehrere Standorte oder Bereiche betroffen,
• keine belastbare Wiederherstellungsprognose,
• relevantes Sicherheits-, Datenschutz- oder Vertragsrisiko,
• hoher Koordinationsbedarf über mehrere Teams und Dienstleister,
• notwendige Geschäftsentscheidung über Notbetrieb oder Abschaltung.

Die Kriterien brauchen Spielraum. Ein Vorfall kann auch ohne vollständige Fakten hochgestuft werden, wenn die mögliche Auswirkung groß und schnelles gemeinsames Handeln nötig ist.

Der Incident Lead führt den Prozess, nicht jede Diagnose

Die führende Rolle wird häufig Incident Manager oder Incident Lead genannt. Sie sorgt dafür, dass die richtigen Fragen zur richtigen Zeit entschieden werden.

Zu ihren Aufgaben gehören:

• Lage und Geschäftsauswirkung zusammenführen,
• Arbeitsstränge und technische Leads benennen,
• Prioritäten und nächste Entscheidungszeitpunkte setzen,
• widersprüchliche Aktivitäten stoppen oder klären,
• Entscheidungen, Annahmen und Änderungen dokumentieren lassen,
• Fachbereiche und Führung in einem festen Takt informieren,
• zusätzliche Rollen oder Dienstleister aktivieren,
• Übergabe, Herabstufung und Abschluss steuern.

Der Incident Lead muss genug technisches Verständnis besitzen, um Abhängigkeiten und Risiken einzuordnen. Während der Führung sollte diese Person aber nicht gleichzeitig tief in Logs arbeiten, Konfigurationen ändern oder einen Wiederherstellungsschritt ausführen.

Die CISA-Grundlage für Incident-Response-Pläne trennt die Rolle ausdrücklich von technischen Tätigkeiten und ordnet ihr Führung, Delegation, Kommunikationsfluss und Zeitüberwachung zu. Das Dokument bezieht sich auf Cybervorfälle; die Rollentrennung ist auch auf schwere betriebliche IT-Störungen übertragbar.

Technik, Entscheidung und Kommunikation brauchen eigene Arbeitsräume

Ein einziger großer Call scheint transparent, erzeugt aber oft ständige Unterbrechung. Eine einfache Struktur trennt drei Ebenen:

1. Lageführung: Incident Lead, technische Leads und erforderliche Entscheidungsrollen stimmen Status, Priorität und nächste Schritte ab.
2. Technische Arbeitsstränge: Fachkräfte analysieren und handeln in kleinen, aufgabenbezogenen Gruppen.
3. Stakeholder-Kommunikation: Betroffene erhalten bestätigte Informationen, Auswirkungen, bekannte Arbeitswege und den nächsten Aktualisierungszeitpunkt.

Zwischen diesen Ebenen fließt Information über feste Übergaben. Der technische Lead meldet Erkenntnisse und Entscheidungsbedarf an die Lageführung. Die Kommunikation veröffentlicht nur bestätigte Aussagen und markiert Unsicherheit.

ISO 22320:2018 beschreibt für das Incident Management Rollen, Aufgaben, Ressourcensteuerung sowie gemeinsame Führung und Zusammenarbeit. Der Standard ist bewusst breit und ersetzt keinen ITSM-Ablauf. Er stützt jedoch das Prinzip, dass koordinierte Führung eine eigene Managementaufgabe ist.

Das Lagebild muss klein genug zum Benutzen sein

Ein laufender Major Incident benötigt kein ausführliches Protokoll in Echtzeit. Er benötigt eine verlässliche gemeinsame Sicht.

Ein nutzbares Lagebild enthält:

• betroffene Services und Geschäftsauswirkung,
• bestätigte Fakten,
• offene Annahmen und wichtigste Unsicherheiten,
• aktive technische Arbeitsstränge mit Owner,
• zuletzt ausgeführte Änderungen und deren Ergebnis,
• aktuelle Rückfall- oder Notbetriebsoptionen,
• benötigte Geschäftsentscheidungen,
• Zeitpunkt des nächsten Lageupdates.

Fakten und Hypothesen müssen getrennt bleiben. „Die Datenbank ist überlastet“ ist zunächst eine Hypothese, bis Messungen sie bestätigen. Diese sprachliche Disziplin verhindert, dass Teams auf einer plausiblen Vermutung aufbauen und alternative Ursachen zu früh verwerfen.

Entscheidungsrechte müssen vor der Störung sichtbar sein

Technische Fachkräfte können eine Option vorbereiten. Bestimmte Schritte benötigen eine Geschäfts- oder Risikoeinordnung, beispielsweise:

• produktive Systeme kontrolliert abschalten,
• auf einen eingeschränkten Notbetrieb wechseln,
• inkonsistente Datenstände verwerfen oder zurücksetzen,
• externe Kommunikation auslösen,
• Dienstleister außerhalb vereinbarter Grenzen beauftragen,
• eine Wiederherstellung mit möglichem Datenverlust freigeben.

Wer diese Entscheidungen treffen darf, gehört in das Bereitschafts- und Eskalationsmodell. Ein Name allein reicht nicht; Vertretung und Erreichbarkeit müssen geregelt sein.

Der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“ trennt Aufgabe, Verantwortung, Entscheidungsrecht und technische Berechtigung. Im Major Incident wird diese Trennung unter Zeitdruck besonders sichtbar.

Kommunikation braucht Takt und bestätigten Inhalt

Ohne feste Updates fragen Betroffene einzeln nach. Die technische Mannschaft beantwortet dieselbe Frage mehrfach, während Gerüchte schneller werden als das Lagebild.

Ein Statusupdate sollte knapp beantworten:

• Was ist betroffen?
• Welche geschäftliche Auswirkung ist bestätigt?
• Was ist noch unklar?
• Welche Arbeits- oder Notwege gelten aktuell?
• Was sollen Nutzer oder Führung jetzt tun – und was nicht?
• Wann folgt die nächste Information?

Der NIST SP 800-61 Rev. 3 betrachtet Incident Response als organisationsweite Fähigkeit und benennt neben Incident Handlern auch Führung, technische Rollen, Recht und Kommunikation. Er richtet sich an Cybersecurity Incident Response. Bei Verdacht auf einen Sicherheitsvorfall sind zusätzlich die dafür vorgesehenen rechtlichen, forensischen und meldebezogenen Wege einzubeziehen; dieser Artikel ersetzt keine entsprechende Fachprüfung.

Konstruiertes Beispiel: Alle helfen und niemand führt

Das folgende Beispiel ist konstruiert.

Ein ERP-Service ist nach einer Änderung nicht erreichbar. Netzwerk, Datenbank, Applikation und externer Hersteller arbeiten im selben Call. Während die Datenbankgruppe eine Wiederherstellung vorbereitet, startet ein Administrator den Applikationsdienst erneut. Dadurch verändert sich das Fehlerbild. Die Geschäftsführung fragt parallel nach einem Zeitpunkt, den niemand belastbar nennen kann.

Nach Benennung eines Incident Leads werden technische Arbeitsstränge getrennt. Änderungen laufen über ein kurzes Entscheidungslog, ein Fachbereich entscheidet über den manuellen Notprozess und Stakeholder erhalten alle 30 Minuten einen bestätigten Status. Die Rolle löst den technischen Fehler nicht. Sie verhindert, dass die Beteiligten sich gegenseitig die Arbeitsgrundlage verändern.

Die Major-Incident-Karte

Feld	Zu klärende Entscheidung
Auslösung	Welche Wirkung oder Unsicherheit rechtfertigt den Major-Incident-Modus?
Führung	Wer ist Incident Lead und wer vertritt diese Rolle?
Geschäftsauswirkung	Welche Services, Bereiche, Kunden oder Fristen sind betroffen?
Technik	Welche Arbeitsstränge und technischen Leads sind aktiv?
Entscheidungsrechte	Wer darf Notbetrieb, Abschaltung, Restore oder externe Hilfe freigeben?
Lagebild	Wo stehen Fakten, Hypothesen, Änderungen, Owner und nächste Schritte?
Kommunikation	Wer informiert welche Zielgruppe in welchem Takt?
Eskalation	Wann kommen Sicherheit, Recht, Datenschutz, Hersteller oder Geschäftsführung hinzu?
Rückfallweg	Welche Not- und Wiederherstellungsoptionen sind vorbereitet?
Ende	Wer stuft den Vorfall zurück und welche Übergaben bleiben offen?
Lernen	Wann werden Ursachen, Ablauf und Maßnahmen nachbereitet?

Kleine Teams dürfen Rollen zusammenlegen

Eine kleine IT-Abteilung kann nicht für jede Funktion eine eigene Person bereitstellen. Personalunion ist möglich, solange die Aufgaben bewusst bleiben.

Beispielsweise kann die IT-Leitung Incident Lead und Ansprechpartner der Geschäftsführung sein, während ein Administrator die technische Leitung übernimmt. Eine weitere Person führt das Log und formuliert Statusupdates. Bei einem kleinen Vorfall können Kommunikation und Dokumentation zusammenfallen.

Nicht sinnvoll ist, wenn dieselbe Person gleichzeitig Lage führt, tief technisch arbeitet, jede Freigabe erteilt und alle Stakeholder einzeln informiert. Dann fehlt nicht Personal, sondern ein arbeitsfähiger Zuschnitt.

Nach dem Restore ist der Major Incident noch nicht abgeschlossen

Die technische Verfügbarkeit beendet die akute Störung. Offen bleiben können Datenprüfung, Nutzerkommunikation, Notbetriebsrückbau, Monitoring, Ursachenanalyse und Maßnahmen.

Der Abschluss sollte deshalb trennen:

• Service wiederhergestellt und beobachtet,
• Geschäftsbetrieb fachlich bestätigt,
• temporäre Änderungen dokumentiert oder zurückgebaut,
• offene Risiken mit Owner und Termin übergeben,
• Kommunikation abgeschlossen,
• Nachbesprechung angesetzt.

Die technische Wiederanlaufdokumentation liefert dafür notwendige Arbeitsgrundlagen. Die Nachbesprechung prüft zusätzlich, ob Führung und Informationsfluss funktioniert haben – nicht nur, welche Komponente ausgefallen ist.

Ein Major Incident braucht nicht möglichst viele Menschen in einem Kanal. Er braucht eine Person, die den Gesamtprozess führt, Entscheidungen sichtbar macht und den technischen Rollen Raum zum Arbeiten gibt. Erst dadurch wird aus gemeinsamer Aufmerksamkeit koordinierte Wiederherstellung.