DORA: what the first year of major incidents reveals about your architecture

One year after DORA became applicable, the first European evidence makes it possible to move beyond regulatory theory. The incidents actually reported point to a practical lesson: resilience does not depend only on detecting and resolving an outage or cyberattack. It also depends on understanding quickly which functions, applications, infrastructure and dependencies are really affected.

The first annual overview published by the European Supervisory Authorities on 3 June 2026 covers 3,383 major ICT-related incidents reported in 2025. Around one third had a cross-border impact. The ESAs highlight the increasingly interconnected nature of ICT risk, including through shared infrastructure and services.1

The EBA provides another measure of scale: from the start of DORA incident reporting in January 2025 to March 2026, it received more than 18,000 reports. System failures were the dominant event category. Among reported cybersecurity incidents, DDoS, identity theft and data exfiltration or manipulation were among the most common techniques.2

These figures do not define a standard architecture for affected organisations. They do, however, raise a much more operational question: when an incident occurs, can we actually reconstruct its impact across the information system?

A technical incident is rarely only technical

Consider an identity-service outage.

From an infrastructure perspective, the event may look simple: one component no longer responds. From an information-system perspective, the consequences can be very different.

The service may be used by several applications. Those applications may support several business processes, including critical ones. External users, employees or partners may also depend on them.

The chain to reconstruct becomes:

incident → component → application → critical function → users → transactions.

This change of scale is what turns a technical event into an operational incident.

DORA's classification framework considers dimensions including affected clients and financial counterparts, transactions, duration, geographical spread, data losses, criticality of services and economic impact.3

Assessing those dimensions quickly requires more than knowing which server or application failed. Teams need to know what depends on it.

Shared dependencies are a hidden concentration risk

Imagine three applications: a payment platform, a customer portal and an internal account-management application.

They are developed by different teams and hosted in different environments. On a high-level architecture diagram, they look independent.

Yet all three use the same identity service.

One failure can therefore affect three functions that appeared separate.

The same reasoning applies to DNS, networks, IAM, API gateways, databases, cloud services, backup platforms, security components and ICT providers.

An architecture can look distributed while still relying on a small number of highly concentrated common dependencies.

The first DORA incident overview strengthens the case for identifying these dependencies before an incident rather than during one.1

Several small incidents can reveal one weakness

DORA also introduces the concept of recurring incidents.

Commission Delegated Regulation (EU) 2024/1772 provides for incidents that are not individually major to be assessed collectively where they occur at least twice within six months, have the same apparent root cause and together meet the relevant criteria.3

That changes how incident history should be read.

Consider three events: application A is unavailable for 20 minutes in March; application B is degraded for 35 minutes in May; application C is interrupted for 25 minutes in July.

Individually, they may be handled as three technical incidents. Dependency analysis, however, shows that all three applications use the same network component.

The real history is no longer incident A + incident B + incident C, but shared component → three different manifestations → several business functions affected.

Root-cause analysis therefore becomes inseparable from architecture knowledge.

Map impact before you need it

An organisation does not need to document every technical detail at the same level of precision.

For incident analysis, a minimum representation can already connect:

critical function → business process → application → infrastructure → ICT service → provider.

Useful attributes can then include criticality, affected users, location, technical dependencies, provider, fallback solution, RTO/RPO, owner and continuity procedures.

The objective is not to create more documentation. It is to answer quickly: what is affected? what could be affected next? which functions depend on this component? is there a shared dependency? what can keep the service running?

Constructed case: three applications, one dependency

Consider a fictional bank operating three digital services.

The customer portal uses an external identity provider. The mobile application uses the same provider. The contact-centre application also relies on it to authenticate employees.

The provider suffers a major outage.

Technically, one dependency is unavailable. Operationally, three services become partially or completely unusable.

Without explicit relationships between information-system objects, the organisation discovers the scope progressively.

With dependency data, the reasoning can be reversed:

identity provider unavailable → three dependent applications → two customer services + one internal service → affected business functions → teams to mobilise → continuity measures to activate.

This knowledge becomes most valuable precisely when time is scarce.

What the first DORA overview does — and does not — show

The ESAs report that around one third of the 3,383 major incidents had a cross-border impact, while system failures and external events were the main drivers. They also note that direct impact on clients and transactions was generally limited.1

Aggregated figures do not prove that all financial entities share the same architecture weaknesses. Nor should incident counts become a simplistic resilience ranking between institutions.

They do show that ICT incidents occur in a highly interconnected environment where consequences can move quickly beyond the boundary of one application, one entity or one country.

The challenge is therefore no longer only to maintain a DORA-compliant incident process. Organisations also need to connect a technical event to the services, functions, users and dependencies it can actually affect.

An organisation that builds that knowledge during the incident is building it too late.