DORA Third-Party ICT Provider Oversight
Deep-dive into DORA Chapter V on ICT third-party risk management, covering the register of information, contractual requirements, critical provider oversight, concentration risk, and exit strategies.
- 1
The register of information under Article 28(3) requires over 50 data fields per ICT service arrangement and must be available to competent authorities on request.
- 2
All ICT service contracts must include mandatory provisions under Article 30, with enhanced requirements for arrangements supporting critical or important functions.
- 3
Critical ICT third-party providers are subject to direct oversight by an ESA-appointed Lead Overseer — a precedent-setting regime for non-financial technology companies.
- 4
Concentration risk assessment is mandatory: entities must evaluate and document dependency on individual providers and maintain viable exit strategies.
- 5
Contractual remediation of legacy ICT service agreements was required by 17 January 2025 — entities should verify that all arrangements now meet Article 30 standards.
ICT Third-Party Risk Management: Principles and Scope
Chapter V of DORA (Articles 28-44) establishes one of the most comprehensive ICT third-party risk management regimes in any financial regulation globally. The core principle is straightforward: financial entities that outsource or rely on ICT services remain fully responsible for compliance with all regulatory requirements. Outsourcing execution does not outsource accountability. This principle, while not new conceptually, is given significantly more teeth under DORA than under previous outsourcing guidelines.
The scope of Chapter V extends to all contractual arrangements through which ICT third-party service providers supply ICT services to financial entities. This includes cloud computing, software-as-a-service, managed security services, data analytics, and any other digital service. Critically, it covers both direct providers and subcontractors in the ICT supply chain. Financial entities must understand and manage the full chain of providers supporting their critical or important functions — not just the entity with which they have a direct contractual relationship.
Article 28 sets the overarching management principles. Financial entities must adopt a strategy for ICT third-party risk, integrated into their broader ICT risk management framework. They must conduct risk assessments prior to entering into ICT service arrangements, and must maintain an ongoing monitoring and oversight capability throughout the lifecycle of the arrangement. The management body must approve the strategy and must be regularly informed about ICT third-party risk exposure — particularly concentration risk arising from dependency on a limited number of critical providers.
Register of Information (Article 28(3))
Article 28(3) introduces one of DORA's most operationally demanding requirements: the register of information. Financial entities must maintain and keep up-to-date a register of information in relation to all contractual arrangements on the use of ICT services provided by third-party ICT service providers. This register is not a simple vendor list — it must contain comprehensive, structured data about each arrangement.
The ITS on the register of information (published under Article 28(9)) specifies the exact data fields required. These include: the identification of the financial entity, the identification of the ICT third-party provider (including LEI where available), a description of the ICT services provided, the classification of the supported function (critical/important or not), the start and end dates of the arrangement, the governing law and country of the provider, whether data is processed in the EU or a third country, subcontracting chains, and whether the provider has been designated as critical by the ESAs.
The register must be maintained at entity level and, for groups, at consolidated and sub-consolidated levels. Financial entities must be able to provide the register to their competent authority upon request. In practice, this means the register must be a living document — updated within a reasonable timeframe whenever a new ICT service arrangement is entered into, an existing one is materially changed, or an arrangement is terminated. Many financial entities are finding that their existing vendor management systems lack the data granularity required by the ITS, necessitating significant data collection and system enhancement efforts.
The register of information also feeds into the ESA's critical provider designation process. The ESAs will use register data submitted by financial entities to identify ICT third-party service providers that are critical to the financial sector as a whole — triggering the oversight framework in Articles 31-44. Accurate and complete register data is therefore not just an entity-level compliance obligation; it contributes to sector-wide systemic risk management.
Start building your register of information immediately if you have not already. The ITS specifies over 50 data fields per arrangement. Retrofitting this data across hundreds of ICT service contracts is a multi-month effort that cannot be compressed into the final weeks before a supervisory request.
Contractual Arrangement Requirements (Article 30)
Article 30 prescribes mandatory contractual provisions that must be included in all ICT service agreements, with additional requirements for arrangements supporting critical or important functions. The baseline provisions applicable to all arrangements include: a clear description of the ICT services, the locations where data will be processed and stored, provisions on data protection and data access, the service levels and performance targets, and the rights of the financial entity regarding monitoring and audit.
For arrangements supporting critical or important functions, Article 30(3) layers on substantially more demanding requirements. These include: full descriptions of service levels with precise quantitative and qualitative performance targets, notice periods and reporting obligations for incidents, business continuity and disaster recovery requirements, audit and access rights for the financial entity and its competent authority, termination rights (including for material breach and regulatory change), exit strategies and transition plans, and obligations on the provider regarding subcontracting (including prior notification and approval requirements).
The audit and access rights deserve particular attention. Under Article 30(3)(e), financial entities must ensure that they, their competent authorities, and any third parties appointed by either, have the right of access, inspection, and audit of the ICT third-party provider. This includes access to the provider's premises, documentation, and relevant records. For cloud service providers and large platform providers that serve thousands of clients, pooled audit mechanisms and third-party certifications (such as SOC 2 or ISO 27001) may be accepted as partial fulfilment — but they do not eliminate the entity's right to conduct its own audit when circumstances warrant.
Existing contracts that predate DORA's application date must be reviewed and, where necessary, renegotiated to include the required provisions. Article 28(8) gave financial entities until 17 January 2025 to bring legacy contracts into compliance. For entities with large vendor portfolios, this contract remediation exercise was one of the most resource-intensive aspects of DORA preparation.
Critical ICT Third-Party Provider Oversight Framework (Articles 31-44)
Articles 31 through 44 establish a unique oversight framework whereby the ESAs — acting through a Lead Overseer — directly supervise ICT third-party service providers designated as critical to the EU financial sector. This is unprecedented: for the first time, non-financial technology companies can be subject to direct regulatory oversight by EU financial supervisory authorities.
The designation process under Article 31 considers factors including the systemic importance of the financial entities relying on the provider, the degree of substitutability of the provider, and the number of Member States in which the provider operates. The ESAs jointly assess providers based on register of information data and other intelligence, and the Joint Committee of the ESAs publishes the list of designated critical providers. Once designated, a provider is assigned a Lead Overseer from among the three ESAs.
The Lead Overseer has broad powers under Articles 35-36, including the right to request information and documentation, to conduct general investigations and on-site inspections, and to issue recommendations. Critically, the oversight framework does not give the Lead Overseer the power to impose direct penalties on providers — the enforcement mechanism runs through the financial entities. If a critical provider fails to comply with Lead Overseer recommendations, the competent authority of the financial entity can require the entity to suspend or terminate the arrangement.
For financial entities, the practical implications are significant. Reliance on a designated critical provider means increased supervisory attention on the quality of the entity's own oversight and risk management of that relationship. The entity must be able to demonstrate that it has independently assessed the provider's ICT risk posture, that contractual provisions meet Article 30 requirements, and that exit strategies are viable. The critical provider designation does not transfer the entity's risk management responsibilities to the Lead Overseer — it adds a layer of supervisory oversight on top of the entity's own obligations.
Concentration Risk and Multi-Provider Strategies
DORA introduces explicit concentration risk requirements that go beyond traditional outsourcing guidelines. Article 29(2) requires financial entities to assess whether entering into an ICT service arrangement would lead to undue concentration risk, taking into account the entity's dependency on the provider, the number of critical functions supported, and the substitutability of the provider. This assessment must be documented and reviewed periodically.
Concentration risk in ICT is a sector-wide concern that individual financial entities cannot fully mitigate on their own. When a large proportion of the banking sector depends on a small number of cloud infrastructure providers, a single outage can have systemic consequences. The ESRB and the ESAs have flagged this concentration as a financial stability risk, and DORA's critical provider oversight framework is partly a response to this concern. Financial entities should expect supervisory authorities to challenge them on concentration risk during SREP or equivalent review processes.
From a practical perspective, mitigating ICT concentration risk requires a deliberate multi-provider strategy for critical functions, robust business continuity planning that accounts for provider failure, and viable exit strategies that enable migration to alternative providers within acceptable timeframes. This does not necessarily mean duplicating every service across multiple providers — which may be prohibitively expensive — but it does mean having documented and tested plans for what happens when a critical provider is unavailable, whether due to a technical outage, a contractual dispute, or a geopolitical event.
The exit strategy requirements under Article 28(8) are closely linked to concentration risk management. Financial entities must ensure that ICT service arrangements for critical functions include transition plans and exit provisions that allow orderly migration without disruption to the business function. These exit strategies must be tested — not merely documented — and must be reviewed when material changes occur in the provider relationship or the entity's ICT environment.
Practical Implementation Approach
Implementing DORA Chapter V requirements is a cross-functional programme that involves procurement, legal, IT, risk management, compliance, and business units. The first step is a comprehensive inventory of all ICT service arrangements — not just those managed centrally by IT or procurement, but also departmental subscriptions, shadow IT, and developer tools that may not appear in formal vendor registers.
Once the inventory is complete, each arrangement must be classified according to whether it supports a critical or important function. This classification drives the level of due diligence, contractual requirements, and ongoing monitoring that apply. The classification should align with the business impact assessments and critical function mapping required by Articles 7-8 of DORA's ICT risk management chapter. Inconsistencies between the risk management framework and the third-party risk management approach will attract supervisory criticism.
Contractual remediation is typically the longest lead-time activity. Large ICT providers — particularly hyperscale cloud providers — have their own contract negotiation processes and may resist bespoke amendments. Financial entities should leverage industry initiatives (such as those coordinated by national banking associations or the European Banking Federation) that negotiate standardised DORA-compliant clauses with major providers. For smaller providers, the financial entity may have more negotiating leverage but must still conduct proportionate due diligence.
Ongoing monitoring and oversight must be operationalised beyond the initial setup. This includes regular performance reviews against contractual SLAs, periodic risk reassessments, annual review of the register of information, and incident coordination procedures with providers. Financial entities should invest in tooling that automates data collection for the register of information, tracks contractual obligations, and alerts when arrangements require renewal, renegotiation, or exit planning.
The ESAs published a set of standardised templates for the register of information under the ITS. Using these templates as your baseline data model ensures alignment with supervisory expectations and simplifies the reporting process when the register is requested by competent authorities.
What is the register of information and who must maintain it?
The register of information is a structured, comprehensive record of all contractual arrangements for ICT services with third-party providers. Under Article 28(3), every financial entity within DORA's scope must maintain and keep it up-to-date. It must include identification details of both parties, descriptions of services, criticality classifications, data processing locations, subcontracting chains, and more. Groups must maintain the register at entity, consolidated, and sub-consolidated levels.
Can we rely on SOC 2 reports instead of conducting our own audits of ICT providers?
SOC 2 reports and ISO 27001 certifications can serve as supporting evidence in your due diligence and ongoing monitoring programme, but they do not fully substitute for the audit and access rights required under Article 30(3)(e). DORA requires that the contractual arrangement preserves your right to conduct independent audits. Pooled audits (where multiple financial entities audit a provider jointly) are an accepted practical alternative for large providers. However, you must retain the contractual right to conduct a direct audit when circumstances — such as a major incident or supervisory request — warrant it.
What happens if a critical ICT provider refuses to comply with a Lead Overseer recommendation?
The Lead Overseer does not have the power to impose direct penalties on ICT third-party providers. However, if a critical provider fails to comply with recommendations, the Lead Overseer informs the financial entities' competent authorities. Those authorities can then require the financial entities relying on that provider to take action, potentially including suspending or terminating the arrangement. The enforcement mechanism runs through the regulated financial entities, not directly against the provider.
How do we handle concentration risk when there are only a few viable cloud providers?
DORA does not require you to avoid using major cloud providers. It requires you to assess concentration risk, document it, and have credible mitigation measures. Practical approaches include: using multiple availability zones or regions, implementing application-level portability (e.g., containerisation), maintaining tested exit and transition plans, ensuring critical data can be extracted in standard formats, and diversifying non-critical workloads across providers. The key is demonstrating to supervisors that you have considered the risk and have actionable contingency plans.
Ready to Operationalise This?
Turn this guide into working compliance workflows. Create an account or schedule a personalised demo.