This informal CPD article, ‘Outsourced but Not Off the Hook: Managing ICT Third-Party Risk Under DORA, and What the First Incident Report Shows’, was provided by CPDs.Academy, a CPD training platform delivering compliance education for professionals in EU-regulated financial services.
Many regulated firms now rely heavily on outside technology providers. Core systems, cloud hosting, data, payment processing and a long tail of smaller services increasingly sit outside the firm, and with them a growing share of operational risk. The Digital Operational Resilience Act has applied across the European Union financial sector since 17 January 2025, and it treats that dependency as a supervised risk rather than a private commercial matter (1). The first annual overview from the European Supervisory Authorities, published on 3 June 2026, gives a sense of the scale. Of the 2025 major ICT incidents included in the ESAs’ analysis, 29% originated from failures attributable to third parties, including ICT third-party providers, other financial entities and infrastructure providers (2). That overview should be read with a caveat. It covers the 2025 incidents for which final reports had been submitted by the cut-off date, and about 15% of notified major incidents, still without a final report, were left out, so it is a strong signal rather than a complete census. For a compliance function, the practical question is less whether to outsource than whether the firm can govern the dependency in the way DORA now requires.
What DORA requires on third-party risk
DORA’s premise is that resilience is a governance question before it is a technical one. The management body carries ultimate responsibility for the firm’s ICT risk, the risk brought in by providers included, and is expected to exercise that responsibility rather than sign it away (1). Third-party risk is not a corner of procurement. It belongs to the same framework the board must answer for.
DORA neither bans outsourcing nor discourages it. What it does is turn the management of ICT third-party risk into a formal, governed obligation, set out mainly in Articles 28 to 30 (1). Three duties sit at the centre. A firm has to run third-party risk as an integral part of its ICT risk framework, owned by the management body rather than left to procurement. It has to know, in one place, who its providers are and what they support. And it has to write specific protections into the contracts themselves, in more detail where the service underpins a critical or important function.
The second of those, knowing who your providers are, is harder than it sounds. Article 28 requires financial entities to maintain and update a register of information covering all contractual arrangements for ICT services provided by ICT third-party service providers, at entity, sub-consolidated and consolidated levels (1). The register also feeds the supervisory process. Competent authorities collect it and pass the information to the European Supervisory Authorities, for purposes that include identifying critical ICT third-party providers (1). The format is not left to the firm. Commission implementing standards prescribe the template, fifteen linked tables running from the entity down through each provider, contract, service and subcontractor, in a machine-readable form the authorities can aggregate across the sector (3). A register that is incomplete or out of date is not an internal housekeeping matter. It is a gap the supervisor can see.
Article 30 makes the obligation contractual. ICT third-party arrangements must set out, among other things, the services provided, the locations from which the services are delivered or the data is processed, the provider’s cooperation duties, service-level descriptions, incident assistance and termination rights (1). Where the arrangement supports a critical or important function, the contract needs more: detailed service-level descriptions, access, inspection and audit rights, and exit arrangements that let the firm move away from the provider without unacceptable disruption (1). The exit term is easy to underrate. A dependency that cannot be unwound in an orderly way is not truly under the firm’s control, however smooth the service on an ordinary day.
Much of the regime turns on a single classification, whether a service supports a critical or important function, meaning one whose failure would materially impair the firm’s financial performance, the soundness or continuity of its services, or its ability to keep meeting its regulatory obligations. Get that judgment wrong and the heavier contractual and oversight duties either go missing where they are needed or are loaded on where they are not. The classification is not a label assigned once and filed. It has to be revisited as the business and its dependencies change.
DORA also requires firms to look beyond the direct provider where ICT services supporting critical or important functions may be subcontracted. Long or complex subcontracting chains can weaken both the firm’s ability to monitor the service and the supervisor’s ability to supervise the financial entity. In an incident, the difficult question may not be only which provider failed. It may be who sits behind that provider.
ICT providers directly into DORA framework
Concentration, the risk behind the risk
Article 29 adds a dimension a single firm cannot fix on its own, concentration (1). When much of the sector leans on the same few cloud and infrastructure providers, a failure at one of them stops being a private incident and edges towards a systemic one. DORA requires a firm to assess whether a proposed arrangement would add to that concentration, both at the level of the individual provider and of the function being placed outside. The first ESA report supports the concern from the other side. A third of the major incidents in 2025, more than a thousand, had a cross-border impact, which the authorities link to firms’ increasing dependence on shared infrastructure and common ICT services (2). The dependency that makes outsourcing efficient is the same one that lets a single disruption travel.
The regulation answers the systemic side of concentration with a mechanism that reaches past the individual firm. The providers most important to the sector can be designated as critical ICT third-party providers and placed under direct oversight by the European Supervisory Authorities, with lead overseers able to examine them and issue recommendations (1). It brings certain non-financial ICT providers directly into the DORA oversight framework. For a regulated firm it is a reminder that its largest dependencies are now visible to supervisors from both directions, through the firm’s own register and through the oversight of the provider.
The incident that is yours even when it is not
Reporting is where third-party risk becomes unavoidably the firm’s own. Article 19 places the duty to report a major ICT-related incident on the affected financial entity, which must notify its competent authority (1). The time limits are set by technical standards: the firm has four hours from classifying an incident as major to send an initial notification, and in any event no more than 24 hours from becoming aware of it (4). That duty does not shift because the failure began elsewhere. The ESA report puts it plainly: a major incident can be reportable for a firm even where the immediate cause sits outside its own environment (2). Two of 2025’s largest disruptions make the point. The TARGET2 outage in February and the Iberian power blackout in April both began well outside the firms that ultimately reported them, yet both generated major incident reports because the consequences landed on regulated entities (2).
There is a collective dimension as well. Because each firm reports its own major incidents, supervisors can now assemble a wider picture of shared exposure across the sector. The ESA report is the product of that pooling, and the 29% third-party figure is visible only because thousands of separate reports were brought together (2). What a firm files in its own interest also feeds a picture no single firm could assemble, and that picture is starting to steer where supervisors look next.
Put the pieces together and the register of information stops being a form and becomes an operational tool. If a provider fails in the middle of the night, the questions are immediate. Which of our functions does this touch. Is any of them critical or important. Does the disruption already start the clock for an initial notification. A firm that cannot answer from its own records is not ready, whatever its policies say.
What it means for firms
For a compliance function, DORA turns outsourcing oversight from a procurement checklist into a standing discipline. The register has to be real and current, not reconstructed at year end. Contracts for ICT services supporting critical or important functions need the required access, audit and exit terms written in clearly. Concentration has to be weighed before signing, not after a provider fails. And the incident-reporting process has to reach into the firm’s suppliers, because their failure can start the firm’s clock. None of this is exotic, but the 29% figure shows why supervisors are likely to keep pressing firms on third-party risk.
Two habits make the difference in practice. The first is treating the register of information as a living operational record the incident team can actually use at speed, not a spreadsheet refreshed once a year for the regulator. The second is owning the classification of critical and important functions deliberately and keeping it current, because the audit rights, the exit plans and the oversight all key off it. A firm that does those two things well tends to find the rest of DORA’s third-party regime falls into place.
Closing thoughts
Outsourcing moves the work to a provider. It does not move the responsibility, and DORA now puts that in law. A firm that hosts its systems with a third party still owns the resilience of the service its own customers receive, and still carries the reporting duty when that service fails. The first year of incident data is not an argument against outsourcing. It is a reminder that a dependency a firm cannot see, cannot weigh for concentration, or cannot unwind in a crisis is not one it fully controls. Knowing exactly who sits behind each critical function, and being able to prove it, is now part of the job.
We hope this article was helpful. For more information from CPDs.Academy, please visit their CPD Member Directory page. Alternatively, you can go to the CPD Industry Hubs for more articles, courses and events relevant to your Continuing Professional Development requirements.
References
(1) Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), applicable from 17 January 2025, including Article 5 on governance, Article 19 on major incident reporting, Articles 28 to 30 on ICT third-party risk, and Articles 31 to 44 on critical ICT third-party provider oversight.
(2) Joint Committee of the European Supervisory Authorities (the European Banking Authority, the European Insurance and Occupational Pensions Authority and the European Securities and Markets Authority), 2025 Report on major ICT-related incidents under Article 22 of Regulation (EU) 2022/2554 (DORA), JC 2026 16, 3 June 2026.
(3) Commission Implementing Regulation (EU) 2024/2956 of 29 November 2024 laying down implementing technical standards on the standard templates for the register of information under Article 28(9) of Regulation (EU) 2022/2554 (DORA).
(4) Commission Delegated Regulation (EU) 2025/301 and Commission Implementing Regulation (EU) 2025/302, which specify the content, time limits, forms, templates and procedures for reporting major ICT-related incidents under Regulation (EU) 2022/2554 (DORA), including an initial notification within four hours of classification as major and no later than 24 hours after the financial entity becomes aware of the incident.
