If a Major ICT Incident Starts Tonight, Who Decides in the First Hour?
At a glance
At that point, the central question is no longer only whether the incident team can restore the service.
If a major ICT incident starts tonight, who decides in the first hour?
Board AskConfirm whether the institution can evidence first-hour decision rights, classification, escalation, communication and regulatory reporting triggers for major ICT-related incidents.
Situation
Assume the following situation.
A critical ICT service becomes unstable late in the evening. Online banking, payments, risk reporting, trading support, client service, identity access or a cloud-hosted workflow is affected.
- The technical cause is unclear.
- The provider is investigating.
- The first internal updates are incomplete.
- Clients may already be affected.
The institution does not yet know whether the event is a major ICT-related incident under DORA.
But the clock has already started.
At that point, the central question is no longer only whether the incident team can restore the service.
The board question is whether the institution can evidence who decides, who escalates, who communicates and who classifies the incident before root cause is known.
If a major ICT incident starts tonight, who decides in the first hour?
Management Summary
ICT incident management has become a board-level resilience question. DORA requires financial entities to establish an ICT-related incident management process to detect, manage and notify ICT-related incidents; to record incidents and significant cyber threats; to classify incidents by priority, severity and criticality of services impacted; to assign roles and responsibilities; and to establish internal escalation and communication procedures.
The first DORA annual overview of major ICT-related incidents reported 3,383 major incidents in 2025. The ESAs state that direct client and transaction impact was generally limited, while system failures and external events were the main drivers. The findings also underline the importance of third-party risk management, outsourced-service oversight and close coordination with service providers during incident response and remediation.
The reporting clock makes first-hour decision capability critical. Commission Delegated Regulation (EU) 2025/301 requires the initial report for a major ICT-related incident as early as possible, and in any case within four hours from classification as major and no later than 24 hours from the moment the financial entity became aware of the incident. If the incident is classified as major only later, the initial notification must be submitted within four hours from classification. The intermediate report is due within 72 hours from the initial notification, and the final report no later than one month after the intermediate or latest updated intermediate report.
A strong board answer is not: "We have an incident plan." A strong answer shows who can classify the incident, who owns the business impact view, who informs the management body, who decides external communication, who triggers regulatory reporting, and whether the first-hour record can be reconstructed.
Management Report Panel
Answer Quality Calibration
The RAG status calibrates the quality of the answer. It does not judge the institution.
The First-Hour Decision Chain
Who Should Answer
- Technology may restore the service.
- Operations may coordinate recovery.
- Compliance may report the incident.
- The management body owns the resilience expectation.
Evidence the Board Should Request
- 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
Warning Signals
- “IT is handling it.”
- “We are waiting for root cause.”
- “The provider is still investigating.”
- “We will inform the board once it is confirmed as major.”
- “The incident plan is documented.”
- “The service owner will know what to do.”
- “The regulator will be notified if required.”
- “Clients will be informed after we understand the impact.”
None of these statements is necessarily wrong. They are simply not sufficient evidence for board-level reliance.
Path to Green
- Decision rights defined
- Impact path visible
- DORA clock controlled
- Communication governed
- Evidence retained
- Lessons embedded
The RAG status calibrates the quality of the answer.
It does not judge the institution.
Suggested Next Question
Which critical or important service would create the greatest first-hour decision pressure if it failed tonight — and can we evidence who decides before root cause is known?
Selected Source Base
- 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
Expert commentary — 7 min read
Major ICT incidents are rarely clean in the first hour.
The first facts are incomplete. The business impact is uncertain. Technical teams may still be investigating. A provider may not yet have confirmed the cause. The institution may not know whether the incident will become reportable. Clients may already notice disruption. Internal stakeholders may ask for updates before the incident team has a stable view.
That is exactly why first-hour decision capability matters.
The weak version of incident management is document-centric. It asks whether an incident plan exists.
The stronger version is decision-centric. It asks whether the institution can decide under uncertainty.
DORA reinforces that distinction. The regulation is not limited to technical restoration. It requires a process to detect, manage and notify incidents; classify them; assign roles and responsibilities; establish escalation and communication procedures; inform senior management and the management body; and mitigate impacts so services become operational and secure in a timely manner.
This means the board should not ask only whether the incident management process exists.
It should ask whether the first-hour decisions are executable.
These are not administrative questions. They are resilience questions.
The ESAs' first DORA incident report makes the topic tangible. It records 3,383 major ICT-related incidents reported in 2025, while also noting that the direct impact on clients and transactions was generally limited. That is an important constructive signal. It suggests that timely detection, response and recovery can limit harm even where the incident landscape is complex and interconnected.
The ESAs also emphasise that ICT risks are increasingly borderless and interconnected, and that around one third of major incidents originated from failures attributable to third parties — including ICT providers, other financial entities and infrastructure providers. This reinforces the point that ICT incidents can move quickly across entities, services, jurisdictions and shared infrastructure. For the first-hour decision chain, however, the more practical board issue is not geography alone. It is whether the institution can coordinate technical response, provider escalation, business impact assessment, regulatory classification and management-body visibility before root cause is known.
That is the right tone for this briefing.
The point is not that institutions fail when incidents occur.
The point is that incidents test whether decision rights, escalation and evidence are real.
A critical service outage can begin as a technical event. Within minutes, it can become an operational resilience event. Within the first hour, it can become a regulatory classification question, a client communication question, a provider-dependency question and a management-body visibility question.
If those questions are answered sequentially, the institution may lose time.
If they are answered through a tested decision chain, the institution can act while uncertainty remains.
That is the practical board insight.
Root cause is not the first decision.
Root cause is often the result of later analysis.
The first decision is whether the institution knows enough to contain impact, escalate correctly, communicate responsibly and start the classification path.
For boards, the most important artefact is therefore not the incident policy.
It is the first-hour evidence trail.
That trail should show what was known, what was assumed, who decided, who was informed, what was communicated, what was not yet known, what was escalated and what was deferred.
A good first-hour record does not require perfect knowledge.
It requires disciplined uncertainty.
That is what distinguishes a documented incident process from operational resilience.
An incident plan describes what should happen.
Incident decision capability proves that the institution can act when the facts are incomplete.