DORA: prepare the first hours of a major ICT incident

The first annual report by the European Supervisory Authorities on major ICT-related incidents under DORA offers a lesson that is more useful than a ranking of causes: incident readiness depends on the ability to assemble reliable data about impact, scope and information-system dependencies quickly. In 2025, 3,383 major incidents were reported in the European Union; around one third had a cross-border impact and almost one third originated from failures attributable to third parties.1

These figures do not mean that the sector is structurally weak. The ESAs explicitly caution that incident counts alone are not a risk indicator, and two thirds of major incidents caused no or only minor disruption to clients and transactions.1

For a CISO, the operational question is therefore less “can we complete the DORA form?” than “can we produce the information that the form requires under time pressure, without reconstructing the information system in the middle of the crisis?” DORA establishes a progressive reporting chain: a limited initial notification, a more detailed intermediate report and a final report once root-cause analysis has sufficiently advanced.24

When does an ICT incident become major under DORA?

DORA distinguishes an ICT-related incident from a major ICT-related incident. The Regulation defines the latter by its high adverse impact on the network and information systems supporting critical or important functions.2 Delegated Regulation 2024/1772 then specifies the classification criteria and materiality thresholds.3

An incident is considered major where it affects critical services and meets the materiality conditions defined by the delegated regulation, including the specific threshold referred to in Article 9(5)(b), or at least two of the other materiality thresholds.3

The criteria cover clients, financial counterparts and transactions, duration and service downtime, geographical spread, data losses, criticality of services and economic impact.3

That mechanism has a data-architecture consequence: at the beginning of an incident, classification is not driven by a technical signal alone. The event must be connected to services, functions, affected populations and operational effects. An alert on a component is not yet a DORA classification.

The four-hour clock starts after classification, but the 24-hour clock is already running

Delegated Regulation 2025/301 sets three deadlines.4

The initial notification must be submitted as early as possible, within four hours of classification as major and no later than 24 hours after the financial entity became aware of the incident. The intermediate report is due no later than 72 hours after the initial notification, even where the incident status or handling has not changed. The final report is due no later than one month after the intermediate report, or after the latest updated intermediate report where applicable.4

Several timestamps therefore need to be tracked separately: technical detection, organisational awareness, classification as major, submission of the initial notification and subsequent versions. Treating “detected” and “classified” as the same timestamp can make deadline control ambiguous.

Stage	Regulatory deadline	Internal capability required
Classification	As soon as the criteria can be assessed	Connect incident, services, functions and impacts
Initial notification	≤ 4 h after classification and ≤ 24 h after awareness	Reference, timestamps, scope and available information
Intermediate report	≤ 72 h after the initial notification	Enriched impact, handling status and consolidated facts
Final report	≤ 1 month after the latest intermediate report	Cause, resolution, impacts and consolidated costs

Implementing Regulation 2025/302 establishes a single template for those stages and specifies which fields must be supplied at each reporting stage.5 The right technical response is not necessarily a new tool. It is first a known data source for every material reporting field.

Build an incident data spine before the crisis

Cybercoria recommends defining a minimum internal incident record that does not attempt to reproduce the regulatory form, but links its data to operational repositories. For example:

incident:
  id: INC-...
  detected_at: ...
  aware_at: ...
  classified_major_at: ...
  affected_services: [...]
  critical_functions: [...]
  affected_entities: [...]
  countries: [...]
  third_parties: [...]
  impact:
    clients: ...
    transactions: ...
    availability: ...
    integrity: ...
  containment_actions: [...]
  root_cause_status: ...
  report_versions: [...]
  evidence_refs: [...]

This structure is Cybercoria analysis, not a DORA requirement. Its value lies in the joins: affected_services should resolve to the service catalogue; critical_functions to business or continuity repositories; third_parties to contracts and outsourced services; affected_entities to the legal perimeter; and evidence_refs to logs, tickets and decisions retained during incident response.

Related analysis
DORA: build the ICT third-party register from the real information system →

The third-party register and incident reporting answer different questions but converge at the critical moment: the register describes contractual dependencies and ICT services; the incident process must identify which of them are actually affected. The first does not prove that the second will be fast.

Constructed case: a shared identity outage starts two clocks

Consider a constructed example, not a real organisation. At 08:10, monitoring detects widespread authentication failures affecting an identity provider used by several applications. At 08:20, the on-call team confirms that production services are affected and the organisation becomes aware of the incident. At 09:05, dependency data shows that two important functions are affected and clients in two countries cannot access services. At 10:05, the incident is classified as major under the applicable criteria.

In this example, the classification-based limit places the initial notification deadline at 14:05. The 24-hour limit from awareness would expire at 08:20 the following day, so the 14:05 deadline is the constraining one.4

The difference between a prepared organisation and one that improvises lies in what happens between 08:20 and 10:05. If function criticality, dependent applications, using entities and the provider are already connected, the team can spend its time assessing real impact and restoring service.

If those relationships exist only in separate files, email and a few people’s memory, classification becomes an investigation of its own.

This case does not cover every situation. A confidentiality incident, an integrity loss or a transaction-related event will require other data and other expertise. It only illustrates the value of maintaining a dependency model before the crisis.

The first DORA report mainly exposes interconnected risk

The 2025 report provides three useful signals. First, around one third of major incidents had a cross-border impact.1 Second, system failures and external events were the predominant drivers observed.1 Third, almost one third of incidents originated from failures attributable to third parties, a category including ICT third-party providers, other financial entities and infrastructure providers.1

These results reinforce an operational need already visible in DORA: during an incident, teams need to move from an affected component to the supported function, the provider involved, the affected entities and the geographical scope. The value is not a static map; it is the ability to traverse those relationships under pressure.

The figures do not show that one third of incidents were “caused by cloud”, nor that cybersecurity represents only a minor share of overall risk. The ESAs state that 10% of reported incidents were categorised as cybersecurity-related, but that statistic belongs to a specific classification framework and the first year of DORA reporting.1

What the 3,383 incidents do not prove

The report itself requires caution. Around 15% of major incidents notified in 2025 were excluded because no final report had been received by the 5 February 2026 cutoff date.1

The ESAs also note that this was the first year of the framework and that reports were not yet subject to the full set of automated data-quality rules that could be derived from the reporting requirements.1

Incident counts should therefore not become a simplistic benchmark between institutions or a way to demonstrate that one organisation is more resilient than another. Aggregated data identifies patterns; it does not replace contextual analysis or internal testing.

The next useful test: produce the initial dossier without hunting for information

A useful DORA exercise can be much simpler than a full crisis simulation. Select a critical service, construct a plausible incident, start the clock, and ask the team to retrieve the information required for classification and the initial notification.

Measure four things: time to identify affected functions; time to determine affected entities and countries; time to retrieve the third parties involved; and time to establish a traceable version of facts and timestamps.

These are internal indicators proposed by Cybercoria, not regulatory thresholds.

If most of the exercise is spent asking “who knows where that information is?”, the priority is probably not to improve the notification form. It is to reduce the cost of reconstructing context before the next incident.