Wenn heute Nacht ein schwerer ICT-Incident beginnt: Wer entscheidet in der ersten Stunde?
Auf einen Blick
An diesem Punkt lautet die zentrale Frage nicht mehr nur, ob das Incident Team den Service wiederherstellen kann.
Wenn heute Nacht ein schwerer ICT-Incident beginnt: Wer entscheidet in der ersten Stunde?
Board AskBestätigen, ob das Institut Entscheidungsrechte in der ersten Stunde, Klassifizierung, Eskalation, Kommunikation und regulatorische Reporting-Trigger für major ICT-related incidents belegen kann.
Situation
Nehmen wir folgende Situation an.
Ein kritischer ICT-Service wird spät am Abend instabil. Online-Banking, Zahlungen, Risk Reporting, Trading Support, Client Service, Identity Access oder ein cloud-gehosteter Workflow ist betroffen.
- Die technische Ursache ist unklar.
- Der Provider untersucht noch.
- Die ersten internen Updates sind unvollständig.
- Kunden können bereits betroffen sein.
Das Institut weiß noch nicht, ob das Ereignis ein major ICT-related incident unter DORA ist.
Aber die Uhr läuft bereits.
An diesem Punkt lautet die zentrale Frage nicht mehr nur, ob das Incident Team den Service wiederherstellen kann.
Die Vorstandsfrage lautet, ob das Institut belegen kann, wer entscheidet, wer eskaliert, wer kommuniziert und wer den Incident klassifiziert, bevor Root Cause bekannt ist.
Wenn heute Nacht ein schwerer ICT-Incident beginnt: Wer entscheidet in der ersten Stunde?
Management Summary
ICT Incident Management ist zu einer board-relevanten Resilienzfrage geworden. DORA verlangt von Finanzunternehmen, einen Prozess für das Management ICT-bezogener Incidents einzurichten, um ICT-related incidents zu erkennen, zu steuern und zu melden; Incidents und erhebliche Cyber Threats zu erfassen; Incidents nach Priorität, Schwere und Kritikalität der betroffenen Services zu klassifizieren; Rollen und Verantwortlichkeiten zuzuweisen; sowie interne Eskalations- und Kommunikationsverfahren einzurichten.
Der erste jährliche DORA-Überblick zu major ICT-related incidents berichtete 3.383 major incidents im Jahr 2025. Die ESAs stellen fest, dass direkte Auswirkungen auf Kunden und Transaktionen im Allgemeinen begrenzt waren, während Systemausfälle und externe Ereignisse die Haupttreiber waren. Die Ergebnisse unterstreichen außerdem die Bedeutung von Third-Party Risk Management, Oversight über ausgelagerte Services und enger Koordination mit Service Providern während Incident Response und Remediation.
Die Reporting-Uhr macht Entscheidungsfähigkeit in der ersten Stunde kritisch. Commission Delegated Regulation (EU) 2025/301 verlangt, dass der Initial Report für einen major ICT-related incident so früh wie möglich eingereicht wird, jedenfalls innerhalb von vier Stunden ab Klassifizierung als major und spätestens 24 Stunden ab dem Zeitpunkt, zu dem das Finanzunternehmen Kenntnis vom Incident erlangt hat. Wird der Incident erst später als major klassifiziert, muss die Initial Notification innerhalb von vier Stunden ab Klassifizierung übermittelt werden. Der Intermediate Report ist innerhalb von 72 Stunden nach Initial Notification fällig, der Final Report spätestens einen Monat nach dem Intermediate Report oder dem zuletzt aktualisierten Intermediate Report.
Eine starke Board-Antwort lautet nicht: „Wir haben einen Incident Plan." Eine starke Antwort zeigt, wer den Incident klassifizieren kann, wer die Business-Impact-Sicht verantwortet, wer das Management Body informiert, wer externe Kommunikation entscheidet, wer regulatorisches Reporting auslöst und ob der First-Hour Record rekonstruiert werden kann.
Management-Report-Panel
Kalibrierung der Antwortqualität
Der RAG-Status kalibriert die Qualität der Antwort. Er bewertet nicht das Institut.
Die Entscheidungskette der ersten Stunde
Wer antworten sollte
- Technology kann den Service wiederherstellen.
- Operations kann Recovery koordinieren.
- Compliance kann den Incident melden.
- Das Management Body verantwortet die Resilience Expectation.
Nachweise, die der Vorstand anfordern sollte
- 01First-Hour Decision Matrix
- 02DORA Classification Path
- 03Incident Command Record
- 04War-Room Timeline
- 05Business Impact Assessment
- 06Management-Body Notification Trigger
- 07Regulator Notification Evidence
- 08Client and External Communication Protocol
- 09Provider Escalation and Dependency Log
- 10Post-Incident Review Pack
Warnsignale
- “IT kümmert sich darum.”
- “Wir warten auf Root Cause.”
- “Der Provider untersucht noch.”
- “Wir informieren den Vorstand, sobald es als major bestätigt ist.”
- “Der Incident Plan ist dokumentiert.”
- “Der Service Owner wird wissen, was zu tun ist.”
- “Der Regulator wird informiert, falls erforderlich.”
- “Kunden werden informiert, nachdem wir die Auswirkung verstanden haben.”
Keine dieser Aussagen ist notwendigerweise falsch. Sie sind nur keine ausreichende Evidenz für Board-Level Reliance.
Weg zu Grün
- Decision Rights definiert
- Impact Path sichtbar
- DORA Clock kontrolliert
- Kommunikation gesteuert
- Evidenz gesichert
- Lessons eingebettet
Der RAG-Status kalibriert die Qualität der Antwort.
Er bewertet nicht das Institut.
Empfohlene nächste Frage
Welcher kritische oder wichtige Service würde den größten First-Hour Decision Pressure erzeugen, wenn er heute Nacht ausfällt — und können wir belegen, wer entscheidet, bevor Root Cause bekannt ist?
Ausgewählte Quellenbasis
- European Union — Regulation (EU) 2022/2554, Digital Operational Resilience Act
- Commission Delegated Regulation (EU) 2024/1772 — ICT Incident Classification Criteria and Materiality Thresholds
- Commission Delegated Regulation (EU) 2025/301 — Time Limits and Content for Major ICT Incident Notifications and Reports
- ESAs — 2025 Report on Major ICT-Related Incidents under DORA
- ESMA / ESAs — First Annual Overview of Major ICT-Related Incidents under DORA, 3 June 2026
- EBA — Joint Technical Standards on Major Incident Reporting
- ECB Banking Supervision — Supervisory Priorities 2026–28
- NIST — SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- BCBS — Principles for Operational Resilience
- FSB — Cyber Incident Reporting: Achieving Greater Convergence
- FSB — Format for Incident Reporting Exchange
Experten-Kommentar — 7 Min. Lesezeit
Major ICT Incidents sind in der ersten Stunde selten sauber.
Die ersten Fakten sind unvollständig. Der Business Impact ist unsicher. Technische Teams untersuchen möglicherweise noch. Ein Provider hat die Ursache vielleicht noch nicht bestätigt. Das Institut weiß möglicherweise noch nicht, ob der Incident reportable wird. Kunden bemerken möglicherweise bereits eine Störung. Interne Stakeholder verlangen Updates, bevor das Incident Team eine stabile Sicht hat.
Genau deshalb ist First-Hour Decision Capability wichtig.
Die schwache Version von Incident Management ist dokumentenzentriert. Sie fragt, ob ein Incident Plan existiert.
Die stärkere Version ist entscheidungszentriert. Sie fragt, ob das Institut unter Unsicherheit entscheiden kann.
DORA verstärkt diese Unterscheidung. Die Verordnung ist nicht auf technische Wiederherstellung beschränkt. Sie verlangt einen Prozess, um Incidents zu erkennen, zu steuern und zu melden; sie zu klassifizieren; Rollen und Verantwortlichkeiten zuzuweisen; Eskalations- und Kommunikationsverfahren einzurichten; Senior Management und Management Body zu informieren; und Auswirkungen zu mindern, damit Services rechtzeitig operativ und sicher werden.
Das bedeutet: Das Board sollte nicht nur fragen, ob der Incident-Management-Prozess existiert.
Es sollte fragen, ob die Entscheidungen der ersten Stunde ausführbar sind.
Das sind keine administrativen Fragen. Es sind Resilienzfragen.
Der erste DORA-Incident-Report der ESAs macht das Thema greifbar. Er verzeichnet 3.383 major ICT-related incidents im Jahr 2025 und stellt zugleich fest, dass direkte Auswirkungen auf Kunden und Transaktionen im Allgemeinen begrenzt waren. Das ist ein wichtiges konstruktives Signal. Es deutet darauf hin, dass rechtzeitige Detection, Response und Recovery Schaden begrenzen können, auch wenn die Incident-Landschaft komplex und vernetzt ist.
Die ESAs betonen außerdem, dass ICT-Risiken zunehmend grenzenlos und vernetzt sind und dass rund ein Drittel der major incidents aus Ausfällen entstanden, die Dritten zurechenbar waren — einschließlich ICT Providers, anderer Finanzunternehmen und Infrastrukturprovider. Das verstärkt den Punkt, dass ICT Incidents sich schnell über Entitäten, Services, Jurisdiktionen und gemeinsame Infrastruktur bewegen können. Für die First-Hour Decision Chain ist die praktischere Board-Frage jedoch nicht Geografie allein. Sie lautet, ob das Institut technische Response, Provider-Eskalation, Business Impact Assessment, regulatorische Klassifizierung und Management-Body-Sichtbarkeit koordinieren kann, bevor Root Cause bekannt ist.
Das ist der richtige Ton für dieses Briefing.
Der Punkt ist nicht, dass Institute scheitern, wenn Incidents auftreten.
Der Punkt ist, dass Incidents testen, ob Decision Rights, Eskalation und Evidenz real sind.
Ein kritischer Service-Ausfall kann als technisches Ereignis beginnen. Innerhalb von Minuten kann er zu einem Operational-Resilience-Ereignis werden. Innerhalb der ersten Stunde kann er zu einer regulatorischen Klassifizierungsfrage, einer Kundenkommunikationsfrage, einer Provider-Dependency-Frage und einer Management-Body-Visibility-Frage werden.
Wenn diese Fragen sequenziell beantwortet werden, kann das Institut Zeit verlieren.
Wenn sie durch eine getestete Decision Chain beantwortet werden, kann das Institut handeln, während Unsicherheit weiterhin besteht.
Das ist die praktische Board-Erkenntnis.
Root Cause ist nicht die erste Entscheidung.
Root Cause ist oft das Ergebnis späterer Analyse.
Die erste Entscheidung ist, ob das Institut genug weiß, um Impact zu begrenzen, korrekt zu eskalieren, verantwortlich zu kommunizieren und den Classification Path zu starten.
Für Boards ist das wichtigste Artefakt daher nicht die Incident Policy.
Es ist der First-Hour Evidence Trail.
Dieser Trail sollte zeigen, was bekannt war, was angenommen wurde, wer entschieden hat, wer informiert wurde, was kommuniziert wurde, was noch nicht bekannt war, was eskaliert wurde und was zurückgestellt wurde.
Ein guter First-Hour Record erfordert kein perfektes Wissen.
Er erfordert disciplined uncertainty.
Das unterscheidet einen dokumentierten Incident Process von Operational Resilience.
Ein Incident Plan beschreibt, was passieren sollte.
Incident Decision Capability beweist, dass das Institut handeln kann, wenn die Fakten unvollständig sind.