+ Neuer Prozess
← Alle Prozesse

Major-Incident-Management

Veröffentlicht v2 P-IT-04
IT & Entwicklung Owner: DH David Heinemann Approver: Iris Vogt Geändert 22.05.2026 19:44 Veröffentlicht 10.05.2026 Review bis 22.02.2027
#ITIL#Incident#Krisenmanagement
Bearbeiten

Zweck & Scope

Zweck

Schnelle Wiederherstellung des Service bei kritischen Ausfällen und transparente Kommunikation gegenüber Kunden und Stakeholdern.

Geltungsbereich

Alle produktionsrelevanten Systeme mit Schwere „kritisch" oder „hoch".

Auslöser

Monitoring-Alarm oder Kundenmeldung über einen Major-Incident.

Inputs · Outputs · KPIs

Inputs

Alarmmeldung, betroffene Komponenten, betroffene Kunden

Outputs

Wiederhergestellter Service, Post-Mortem, Kommunikations-Log

KPIs

MTTR ≤ 60 Min · 95 % aller Stakeholder informiert ≤ 15 Min · Post-Mortem ≤ 5 Werktage

Beteiligte Rollen

  • IT-Betrieb
  • IT-Sicherheit
  • Produktverantwortlicher
  • Solution Architect
  • Geschäftsführung
  • Service-Mitarbeiter
  1. 1

    Alarm wird ausgelöst

    Start

    Monitoring oder Kundenmeldung erreicht das On-Call-Team.

  2. 2

    Major-Incident klassifizieren

    Aktivität IT-Betrieb ⏱ 5 Min.

    Severity bewerten (S1/S2), Scope erfassen, Major-Incident-Flag setzen.

    Systeme: PagerDuty, Jira

    • R IT-Betrieb
    • C IT-Sicherheit
    • I Produktverantwortlicher
  3. 3

    War Room einberufen

    Aktivität IT-Betrieb ⏱ 10 Min.

    Bridge-Call mit allen relevanten Rollen starten. Rollen: Incident Commander, Communications Lead, Tech Lead.

    Systeme: Zoom, Slack

    • R IT-Betrieb
    • C Solution Architect
    • I Geschäftsführung
  4. 4

    Sicherheitsvorfall?

    Entscheidung IT-Sicherheit

    Falls Sicherheitsbezug → Security-Incident-Sub-Prozess starten.

  5. 5

    Mitigation ausführen

    Aktivität Solution Architect ⏱ 30 Min.

    Rollback, Failover, Hotfix-Deployment oder Workaround.

    Systeme: CI/CD, Infrastruktur-Tools

    • R Solution Architect
    • A IT-Betrieb
    • C Produktverantwortlicher
  6. 6

    Kunden & Stakeholder informieren

    Aktivität Produktverantwortlicher ⏱ 15 Min.

    Status-Page aktualisieren, betroffene Großkunden direkt informieren.

    Systeme: Statuspage.io, CRM

    • R Produktverantwortlicher
    • I Geschäftsführung
    • I Service-Mitarbeiter
  7. 7

    Wiederherstellung verifizieren

    Aktivität IT-Betrieb ⏱ 15 Min.

    Smoke-Tests, Monitoring grün, Bestätigung durch Kundenmeldungen.

  8. 8

    Post-Mortem

    Aktivität Solution Architect ⏱ 90 Min.

    Blameless Post-Mortem, Maßnahmenkatalog ableiten, in OKR-Tracking überführen.

    • R Solution Architect
    • C IT-Betrieb
    • A Produktverantwortlicher
  9. 9

    Ende

    Ende

    Incident geschlossen, Lessons Learned dokumentiert.

+ Schritt hinzufügen

RACI-Matrix

Verantwortlichkeiten je Schritt und Rolle. R = Ausführend · A = Verantwortlich · C = Befragt · I = Informiert

# Schritt IT-Betrieb IT-Sicherheit Produktverantwortlicher Solution Architect Geschäftsführung Service-Mitarbeiter
1 Alarm wird ausgelöst
2 Major-Incident klassifizieren RR C I
3 War Room einberufen RR C I
4 Sicherheitsvorfall? R
5 Mitigation ausführen A C RR
6 Kunden & Stakeholder informieren RR I I
7 Wiederherstellung verifizieren R
8 Post-Mortem C A RR
9 Ende

RACI je Schritt pflegen

1. Alarm wird ausgelöst

Keine RACI-Zuweisungen.

2. Major-Incident klassifizieren

  • R IT-Betrieb Responsible (Ausführend)
  • C IT-Sicherheit Consulted (Befragt)
  • I Produktverantwortlicher Informed (Informiert)

3. War Room einberufen

  • R IT-Betrieb Responsible (Ausführend)
  • C Solution Architect Consulted (Befragt)
  • I Geschäftsführung Informed (Informiert)

4. Sicherheitsvorfall?

Keine RACI-Zuweisungen.

5. Mitigation ausführen

  • R Solution Architect Responsible (Ausführend)
  • A IT-Betrieb Accountable (Verantwortlich)
  • C Produktverantwortlicher Consulted (Befragt)

6. Kunden & Stakeholder informieren

  • R Produktverantwortlicher Responsible (Ausführend)
  • I Geschäftsführung Informed (Informiert)
  • I Service-Mitarbeiter Informed (Informiert)

7. Wiederherstellung verifizieren

Keine RACI-Zuweisungen.

8. Post-Mortem

  • R Solution Architect Responsible (Ausführend)
  • C IT-Betrieb Consulted (Befragt)
  • A Produktverantwortlicher Accountable (Verantwortlich)

9. Ende

Keine RACI-Zuweisungen.

Risiken & Kontrollen

RisikoSchwereKontrolleVerantwortlich
Verspätete Kommunikation
Kunden erfahren erst über Social Media vom Ausfall.
 Kritisch Statuspage automatisch durch Monitoring; Communications Lead obligatorisch. Clara Weiß
Übersehene Sicherheitsdimension
Outage maskiert Angriff (z. B. DDoS oder Datenabfluss).
 Hoch CISO im War Room obligatorisch ab S1. Gina Lindberg

+ Risiko erfassen

Feedback & Fragen

  • CW
    Clara Weiß Verbesserung 22.05.2026 19:44

    Können wir die Statuspage-Templates noch näher an unsere Tone-of-Voice anpassen?

+ Kommentar oder Frage

Versionshistorie

  1. v1 published 22.05.2026 19:44

    Initiale Veröffentlichung

    Snapshot anzeigen 
    {
    "name": "Major-Incident-Management",
    "note": "Initiale Ver\u00f6ffentlichung"
}