One ICT Risk View, Three Disconnected Systems Under DORA

Key Takeaways

• The European Supervisory Authorities’ first annual DORA incident report (June 2026) logged 3,383 major ICT-related incidents across EU financial entities in 2025, most driven by system failures rather than external attacks.
• Almost a third of 2025’s major ICT incidents originated from a third-party provider failure rather than the reporting institution’s own systems, exactly the domain most consolidated ICT risk views leave out.
• DORA‘s ICT risk management framework (Articles 5 to 16), incident reporting regime (Articles 17 to 23), and third-party register requirements (Articles 28 to 30) already produce the data a consolidated view needs. Almost no institution connects the three.
• DORA and NIS2 set different clocks for the same kind of event. DORA requires notification within four hours of classifying an incident as major. NIS2 requires an early warning within 24 hours of becoming aware, with no classification step first.
• A board conversation about ICT risk needs a governance answer. A spreadsheet stitched together the week before an exam will not hold up.

In 2025, financial entities across the EU reported 3,383 major ICT-related incidents to their supervisors, the first full year of reporting under the Digital Operational Resilience Act (DORA). System failures were the most common incident type, cited in 51% of them. Around a third had a cross-border impact. Two-thirds did not disrupt clients and transactions, or only caused minor disruption.

What the 2025 Incident Data Shows

System failures were the most common incident type in 2025, cited in 51% of the 3,383 major ICT-related incidents EU financial entities reported that year, according to the European Supervisory Authorities’ first annual DORA incident report, published in June 2026.

Most institutions built their ICT risk narrative around the cyber threat, because that is the story that gets board attention. The data says the more common failure is internal: a system, a process, a dependency that broke under ordinary conditions. Cybersecurity-related incidents accounted for just 10% of the total.

About a third of these incidents crossed borders, a reminder of how interconnected shared infrastructure and shared providers have become across the sector. Two-thirds caused no disruption to clients and transactions, or only minor disruption. Almost a third of all major incidents in 2025 originated from a failure at a third-party provider rather than the reporting institution’s own systems. Mitratech’s analysis of that concentration risk goes deeper into what that dependency actually looks like across the sector.

This is the first year of reporting, so the picture is still forming. It is detailed enough to show where the risk actually concentrates, which is exactly the view most ICT risk programs still cannot produce on demand.

What Does DORA Require for Third-Party ICT Risk Management?

DORA requires financial entities to maintain a live Register of Information on every ICT third-party provider under Articles 28 to 30, covering criticality, concentration, and contractual terms, and to connect that register to the same ICT risk management framework set out in Articles 5 to 16.

In practice, that means the register cannot be a document you update once a year for an audit. It has to reflect which providers are critical, which functions depend on them, and what happens if one fails.

Most Registers of Information satisfy the letter of Article 28 without satisfying the intent behind it. They exist. They are current as of the last review. They are not the kind of record you would want to hand a supervisor with no notice.

Why Does the Data Still Live in Three Different Places?

Three teams hold the pieces of this picture, and none of them were built to answer for the whole. IT and the CSIRT function own the incident log. Procurement or third-party risk owns the vendor register. Business continuity owns the resilience testing record. Each does its job well within its own boundary.

Nobody owns the space between them. A vendor’s risk score changes in the third-party system, and nobody checks whether that vendor also appears in an open incident. A resilience test surfaces a single point of failure, and nobody checks whether that function depends on a provider already flagged as high-risk elsewhere. The information exists. It just never reaches the person who needs to see all of it at once.

This is not a new problem dressed in new language. Mitratech’s earlier look at CSDDD, DORA, and NIS2 contract obligations found the same structural gap between contract management and risk systems that rarely talk to each other. ICT risk runs through three teams instead of two, but the fault line is the same one.

What Is the Difference Between DORA and NIS2 for Vendor Risk Management?

DORA requires financial entities to notify their supervisor within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it. NIS2 requires an early warning within 24 hours of becoming aware, with no classification step first. Where both regimes apply to the same entity, DORA takes precedence.

NIS2’s clock starts the moment you notice something. DORA’s clock starts once you have already decided the incident is major, though that decision itself is expected without undue delay. An institution in scope for both needs a process fast enough to satisfy the stricter of the two timeframes, not just the one that happens to apply to a given incident.

If your institution sits outside the EU, the mechanics differ, but the expectation does not. The UK’s operational resilience regime under the PRA and FCA, and US guidance from the OCC and FFIEC, are moving in the same direction: a single, current view of ICT exposure that a supervisor can ask for without warning.

What a Regulator-Ready ICT Risk View Requires

A regulator-ready ICT risk view requires four things in the same place: a live Register of Information, an incident log with remediation status attached, a concentration assessment of critical-function dependencies, and a resilience testing record tied to both. Assembling them after the fact, once someone has enough notice, does not count.

1. A live Register of Information, updated continuously rather than exported at audit time.
2. An incident log that distinguishes major incidents from routine disruptions, with remediation status attached.
3. A concentration assessment showing which critical functions depend on the same handful of providers.
4. A resilience testing record connected to both, so a test result actually changes how a vendor or a function gets treated afterward.

Mitratech’s own look at why vendor risk no longer gets its own exam found the same underlying ask in a different market: examiners increasingly want to be asked once and shown one answer instead of three times for three partial ones. ICT risk under DORA is the same demand at a larger scale.

What This Means for ERM Leadership

A CRO who can produce one current view of ICT exposure can answer a board question about risk appetite directly. A CRO who has to request the answer from three teams and reconcile it manually is answering a different question: How confident are we that this number is even still current?

That difference shows up first in front of a supervisor, but it shows up just as clearly in front of your own board. The institutions that treat this as connected views instead of separate reports are the ones who will not need three weeks to answer a question that should take three minutes.