DORA Third-Party ICT Risk: Complete Guide to Provider Oversight

Own the Register of Information? The Register of Information Specialist certification masters DORA’s hardest artefact end to end: data model, subcontracting chains, reconciliation and submission. Lawyers who draft and negotiate the Article 30 clauses have their own route: DORA training for lawyers and law firms. See all DORA certifications.

1 Why Third-Party Risk Is DORA's Most Complex Pillar

DORA's five pillars cover governance, incident management, resilience testing, third-party risk, and information sharing. Of these, Pillar 4, third-party ICT risk management: occupies the largest share of the regulation by article count (Articles 28–44) and, in practice, the largest share of compliance programme effort. The reason is structural.

The European financial sector does not run on infrastructure it owns. Core banking systems, payment processing, cloud compute, data analytics, trading platforms, custody systems, and cybersecurity operations are predominantly delivered by specialist ICT providers. Estimates from the EBA's outsourcing registers suggest that more than 60% of critical functions in large EU financial institutions depend on third-party ICT services. DORA requires financial entities to manage, monitor, and account for every one of those dependencies.

2 The Register of Information (Article 28)

Article 28(3) requires all in-scope financial entities to maintain a complete, up-to-date Register of Information covering every contractual arrangement with a third-party ICT service provider. Article 28(9) mandates annual submission of that register to the competent authority, and delivery upon request at any time. See our dedicated Register of Information pillar for the 15 templates, xBRL-CSV format and the annual submission calendar.

What the RoI Must Contain

The ESA Implementing Technical Standard (ITS) translates Article 28(3) into a specific relational data model. The register is not a spreadsheet. It is a set of linked tables covering:

• Entity and branch identification: who is submitting, including all group entities covered by a consolidated submission
• Third-party provider master list: every ICT provider with its Legal Entity Identifier (LEI), country of establishment, and CTPP designation status
• Contractual arrangements: one record per contract, with reference date, governing law, notice period, and criticality flag
• Annual costs per arrangement: actual spend (prior year) and estimated cost (current year); feeds supervisory concentration analysis
• ICT services received: each contract broken into individual service lines (cloud compute, managed security, data processing, etc.)
• Functions supported: each ICT service mapped to the business function(s) it enables, with critical/important function (CIF) classification
• ICT assets: servers, applications, databases associated with each service (mandatory for significant institutions from 2026)
• Sub-outsourcing chains: material sub-contractors of providers delivering services to critical functions
• Exit strategies: documented evidence that exit plans exist for critical arrangements

xBRL-CSV Format Requirements

Submissions must be delivered as an xBRL-CSV package: a folder containing a JSON metadata file (report-package.json), one CSV file per template following ESA taxonomy naming conventions, and references to the published ESA taxonomy version. Key validation requirements:

Most Common Errors (Identified in the 2025 First Collection)

• Missing or invalid LEIs: approximately one-third of first-round submissions had LEI issues. Run a Global LEI Foundation lookup against your entire provider list before submission.
• Aggregated contracts: one record per provider instead of one record per contractual arrangement. A provider with five separate contracts needs five records.
• Over-conservative criticality classification: classifying core banking infrastructure as non-critical to reduce scope. NCAs cross-reference criticality claims against incident reporting history.
• Blank sub-outsourcing templates: major cloud providers sub-contract to infrastructure hyperscalers. Claiming no material sub-contractors for AWS or Azure deployments is not credible.
• Empty exit strategy fields for critical arrangements: this is simultaneously a validation error and a substantive compliance gap.

3 Contractual Requirements: Article 30

Article 30 establishes minimum contractual content for all arrangements between financial entities and third-party ICT service providers supporting critical or important functions. These clauses are not optional and cannot be waived. If a contract predates DORA, it must be amended to include them.

The Mandatory Clause List

• Clear and complete description of all ICT services to be provided, including whether sub-contracting is permitted and under what conditions.
• Locations where services will be provided and where data will be processed and stored, including notification requirements for any change.
• Service level objectives (SLOs) covering availability, performance, capacity, and security, with quantified targets and measurement methodology.
• Notice period and reporting obligations for any development that may materially affect the provider's ability to deliver the contracted services.
• Requirements for the provider to implement and test ICT business continuity plans and to participate in the financial entity's own continuity testing.
• Full cooperation with ICT incident investigations affecting the financial entity, including providing logs, forensic data, and root cause analysis.
• Unrestricted audit and inspection rights for the financial entity, its NCA, and relevant ESAs, including on-site access to the provider's premises.
• Right to monitor performance continuously against agreed SLOs, with defined escalation procedures for underperformance.
• Termination rights: the financial entity must be able to exit the contract under defined circumstances, including regulatory direction, material service degradation, or security concern.
• Transition assistance period: upon termination, the provider must continue delivering services for a minimum period (typically 12 months) to allow an orderly transition.
• Data portability and return: upon termination, all data belonging to the financial entity must be returned in a usable format and securely deleted from provider systems within a defined timeframe.
• Sub-outsourcing restrictions: the financial entity's prior approval must be required for any material sub-contracting that affects services to critical or important functions.
• Security standards compliance: the provider must maintain security standards at least equivalent to those required of the financial entity itself under DORA.
• Disclosure obligations: the provider must proactively disclose any ICT incidents, security vulnerabilities, or regulatory actions affecting services to the financial entity.
• Regulatory access: explicit provision allowing the financial entity's NCA direct access to the provider's premises and systems for supervisory examinations.

Sub-Outsourcing Chain Requirements

Where a provider sub-contracts elements of the service to another party, the financial entity must ensure that the sub-contracting chain is:

• Fully mapped in the Register of Information
• Approved by the financial entity (contractual approval right from the direct provider)
• Subject to equivalent contractual protections flowing down the chain
• Monitored for concentration risk: the same sub-contractor supplying multiple critical ICT providers creates systemic dependency

4 Due Diligence and Ongoing Monitoring

Pre-Contractual Assessment

Before entering any new arrangement with a third-party ICT provider for critical or important functions, financial entities must conduct a proportionate due diligence assessment. The assessment should cover:

Run it on paper, once, and reuse it. Our free Vendor Due Diligence Questionnaire (Excel) puts the 22 Article 28-30 requirements in one workbook, with columns for the provider's answer, the evidence they returned and your own assessment.

Ongoing Performance Monitoring

Post-contract, monitoring obligations are continuous. Regulators expect to see documented evidence of:

• Quarterly SLO performance reviews against contractually defined metrics, with formal escalation where targets are missed
• Annual audit or assessment of security controls and resilience measures, either through your own team or a qualified third party
• Incident notification tracking: log every provider-reported incident affecting your services, date received, remediation timeline, and final closure
• Change management notifications: review and approve any material changes to services, sub-contracting, data processing locations, or key personnel
• Annual RoI update: reflect any changes to the contractual arrangement in the Register of Information within 30 days

Concentration Risk Analysis

Concentration risk (the risk that multiple critical functions depend on a single provider or a small number of providers) must be assessed at least annually. The analysis should cover:

• Which providers support more than one critical function (internal concentration)
• Which providers are shared with peer institutions in the same sector (systemic concentration: this feeds the CTPP designation process)
• Geographic concentration: providers whose infrastructure is concentrated in a single data centre region or jurisdiction
• Interdependencies: providers who themselves depend on a common underlying supplier (e.g., all major public clouds share certain semiconductor or networking suppliers)

Scenario: Your Cloud Provider Is Designated a CTPP

5 The 19 Designated Critical ICT Third-Party Providers

On 18 November 2025, the European Supervisory Authorities (ESAs), acting through their Joint Committee, published the first list of critical ICT third-party service providers (CTPPs) designated under Article 31 of DORA. Designation rests on the criteria of Article 31(2): the systemic impact of a failure of the provider, the systemic importance of the financial entities relying on it, their reliance for critical or important functions, and how far the provider can be substituted.

Source: ESAs, list of designated CTPPs under Article 31(9) DORA, 18 November 2025. Entity names are reproduced exactly as published, in the same alphabetical order; the Group and Type columns are our own description. The list does not state the Lead Overseer of each provider: under Article 31(1)(b) it is the ESA responsible for the financial entities holding the largest share of total assets among the provider’s financial-entity customers. The ESAs update the list every year (Article 31(9)).

The list goes well beyond the cloud platforms: six IT services and outsourcing firms, four cloud platforms, three telecoms operators, three financial data and technology providers, two data centre operators and one enterprise software provider. Match it against your register by group, not by contracting entity, and include the subcontractors that underpin services supporting critical or important functions: you can depend on a designated data centre or network operator without a direct contract with it. A provider absent from the list is not out of scope of your own obligations: Article 31(8) excludes, among others, financial entities providing ICT services to other financial entities and intra-group providers, and Articles 28 to 30 apply to every ICT third-party service provider.

What CTPP Designation Means for Your Contracts

Designation places the provider under Union oversight (Articles 31 to 44). It does not change which Article 30 clauses your contract needs, and it does not lighten your own obligations: you remain fully responsible for compliance whichever provider you use (Article 28(1)(a)). What it adds:

• The CTPP must cooperate with its Lead Overseer, which can request information and documentation, conduct general investigations and on-site inspections (Articles 35 and 37 to 39). Your Article 30(3) contracts must provide for the provider’s full cooperation during those inspections
• The Lead Overseer can address recommendations to the CTPP, which must follow them or explain why not within 60 calendar days (Article 42(1)). Your competent authority informs you of the risks identified, and you must take them into account in your ICT third-party risk management (Article 42(3))
• As a last resort, your competent authority may require you to temporarily suspend or terminate the use of the service (Article 42(4) and (6)): keep a tested exit strategy for services supporting critical or important functions
• A CTPP established in a third country must set up a subsidiary in the Union within 12 months of its designation, or financial entities may no longer use its services (Article 31(12))

Are you the provider rather than the financial entity? Read our DORA guide for ICT third-party providers.

Full analysis: CTPP Designations, Who Made the List and What It Means →

6 Practical Toolkit

Due Diligence Checklist for New ICT Providers

Tools and Resources

Third-Party Risk FAQ

Related Resources