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. 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 Q1 2026 deadlines.

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:

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 Third-Party Providers

In November 2025, the Joint Committee of the ESAs published the first list of Critical Third-Party Providers (CTPPs) designated under Article 31 of DORA. The designation reflects systemic importance to the EU financial sector — providers whose disruption would have sector-wide impact.

Source: ESA Joint Committee CTPP designation list, November 2025. Designations are subject to review and may be updated. Always verify current status with your Lead Overseer.

What CTPP Designation Means for Your Contracts

If your institution has a contractual arrangement with any of the 19 designated CTPPs for critical or important functions, specific obligations apply:

• The CTPP is required to cooperate with its Lead Overseer — this may include the Overseer requesting information about services provided to your institution specifically
• Your contracts with CTPPs may be reviewed directly by the ESA Lead Overseer during an examination of the CTPP
• If the Lead Overseer issues a recommendation to the CTPP requiring service changes, you will receive notification and must assess the impact on your critical functions
• If the Lead Overseer recommends your NCA require you to temporarily suspend or terminate a CTPP contract (Article 42(1)(f)), you must have an exit strategy ready to execute

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

Related Resources