In 2025, almost one in three major ICT incidents reported under DORA began with a failure at a third party. Not only at the providers firms had identified as critical. The European Supervisory Authorities explicitly included providers that had not been designated as such.
That should change how firms build the Register of Information. A contract list can tell you who the firm buys from. It cannot, by itself, tell you what the business depends on.
01
What the first year of incident data shows
In June 2026, the ESAs published their first annual report on major ICT-related incidents under DORA. Financial entities reported 3,383 major incidents across the EU in 2025. Two thirds caused no disruption or only minor disruption to clients and transactions. That is the reassuring part: detection, response and containment often worked.
The quieter finding is the one worth keeping on the desk. Twenty-nine per cent of major incidents originated with a third-party failure. The report names ICT providers, other financial entities and infrastructure providers. It also warns that dependencies on providers not designated as critical remain a matter for supervisory attention.
This was not mainly a story about sophisticated attacks moving through a software supply chain. Cybersecurity-related incidents accounted for 10 per cent of the total. System failures accounted for 51 per cent. External events accounted for 27 per cent.
The dependency that hurts is often ordinary: a provider’s system stops, connectivity fails, a service behind the service goes down, or an operational relationship turns out to work differently from the way it was documented.
02
The contract list shows only part of the chain
Starting with contracts feels sensible. They are already on file, the Register of Information is organised around contractual arrangements and each supplier has a legal name. The result looks solid.
But the contract list answers a narrower question: who did we sign with? Operational resilience asks something else: what has to keep working for this function to continue?
Those answers do not always line up. A provider may rely on services the financial entity never contracted for directly. A reseller may sit between the firm and a platform with which the firm has, in fact, accepted a separate agreement. A business team may depend on an application that never appeared in the critical service map because it was treated as ordinary office software.
A register built from the contract list can therefore be complete in one sense and incomplete in the sense that matters. Every agreement may be present while the actual path of failure remains hidden.
03
An MSP, Microsoft and one overlooked spreadsheet
Penrose, a Dutch law firm, gives a useful example involving a managed service provider. A smaller financial institution may run its ICT environment through an MSP and assume that Microsoft sits behind it as a subcontractor. Under Microsoft’s Cloud Solution Provider model, however, the institution may have accepted the Microsoft Customer Agreement directly, sometimes through an attestation made by the MSP. For the services covered by that agreement, Microsoft may be a direct ICT third-party provider rather than the MSP’s subcontractor.
The legal chain matters, but the operational chain matters too. Imagine that “IT support” is classified as non-critical because the firm believes its critical work happens elsewhere. Then look at the work itself. The team responsible for regulatory transaction reporting uses Excel. Its ability to perform a critical function now depends on Microsoft 365, regardless of where “IT support” sits on the organisation chart.
The point is not that every Microsoft product is automatically critical. It is that criticality follows actual use. The name of the department, the supplier category and the person who pays the invoice are weak substitutes for knowing how the work is done.
04
Map from the function outward
A better sequence starts with the function.
- Identify the functions whose disruption would materially affect the firm or its obligations.
- Trace the services, applications, infrastructure and people those functions actually use.
- Follow the operational dependencies behind those services, including the ones introduced by MSPs, resellers and shared platforms.
- Reconcile that map against the contracts, supplier records and Register of Information.
This order exposes two different gaps. One is contractual: the firm misunderstood who supplies what, or under which agreement. The other is operational: the firm recorded the contract correctly but did not connect the service to every function that relies on it.
Neither gap is solved by adding more supplier rows without understanding the dependency. The work is to connect functions, services, providers and contracts in a way that survives a simple question: if this stops tomorrow, what stops with it?
05
The register and the incident report belong together
The ESAs plan to analyse incident reports alongside the Register of Information. That is a logical next step. One dataset shows where firms say their dependencies are. The other shows where major failures actually began.
As those datasets are connected, a tidy but shallow register becomes less defensible. The question will not only be whether a provider was recorded. It will be whether the recorded relationships explain the incidents, concentrations and functions the supervisor can see elsewhere.
Nearly one in three major incidents originating at a third party does not mean every supplier is critical. It means third-party dependency is not peripheral to operational resilience. Firms need to map it from the business outward, then use the contracts to verify the picture.
The risk is not confined to what you signed. It sits in what the organisation actually needs in order to keep working.
06
Sources
- European Supervisory Authorities, 2025 Report on major ICT-related incidents, Joint Committee report JC 2026 16, 3 June 2026.
- Penrose, DORA and outsourcing to third-party ICT service providers, 11 November 2025.
Ariadnah Solutions B.V. develops reporting software for the DORA Register of Information. This article is part of “DORA Register of Information: lessons from the field”, examining the register from the perspective of the entities that file it and the authorities that use it.