F

DORA Third-Party ICT Risk Management Obligations

Guide to DORA third party risk management: mandatory contractual clauses, Register of Information, exit strategies, and ESA oversight of critical providers.

DORA third party risk management represents the most operationally demanding pillar of the Digital Operational Resilience Act. Articles 28 through 44 of Regulation (EU) 2022/2554 impose a structured regime governing how financial entities select, contract with, monitor, and exit relationships with ICT third-party service providers. According to a 2024 survey by the European Banking Authority, financial institutions maintain an average of 147 ICT third-party arrangements, each of which must now satisfy DORA’s requirements.

Since 17 January 2025, these obligations are binding across all 21 categories of financial entities. This article covers each component of the DORA third party risk management framework and how it intersects with existing GDPR obligations.

What Does DORA Require for Third-Party Risk Management?

DORA treats third-party ICT risk as a systemic issue, not merely a procurement concern. Article 28(1) establishes the foundational principle: financial entities must manage ICT third-party risk as an integral component of their overall ICT risk management framework. Outsourcing to a cloud provider, a payments processor, or a data analytics vendor does not outsource the associated risk.

The regulation creates obligations at every stage of the third-party lifecycle: pre-contractual due diligence, mandatory contractual provisions, ongoing monitoring, a Register of Information reported annually to competent authorities, exit strategies ensuring continuity, and sub-outsourcing controls governing the provider’s own supply chain.

According to EIOPA’s 2025 supervisory report, 34% of financial entities had not completed a full inventory of their ICT third-party arrangements by the application date – a compliance gap that supervisors are actively pursuing.

Pre-contractual assessment and concentration risk

Article 28(4) requires thorough due diligence before entering into any ICT arrangement. For providers supporting critical or important functions, the assessment must cover information security capabilities, business continuity arrangements, financial stability, data location including any transfers outside the EU, and concentration risk.

Article 29 specifically addresses ICT concentration risk. The European Systemic Risk Board has flagged that the top three cloud providers support over 70% of cloud-based financial services infrastructure in the EU, making concentration risk a sector-wide concern. Entities must document mitigation measures, including multi-provider strategies where feasible.

What Contractual Clauses Does DORA Mandate?

Article 30 prescribes the minimum content that must appear in contractual arrangements with ICT third-party providers. These are regulatory requirements, not optional negotiating points.

Every contract must include a clear description of functions and services, data processing and storage locations, provisions on data availability, authenticity, integrity, and confidentiality, obligations for the provider to assist during ICT incidents, cooperation obligations with competent authorities, and termination rights with minimum notice periods.

Enhanced requirements for critical functions

Where the arrangement supports a critical or important function, Article 30(3) adds further mandatory clauses: full service-level descriptions with quantitative performance targets, unrestricted rights of access, inspection, and audit, exit strategies with adequate transition periods, incident notification within 4 hours for major incidents, and data protection obligations that parallel GDPR Article 28 processor agreements.

A 2025 analysis by Deloitte found that 58% of existing ICT outsourcing contracts in the financial sector required amendment to meet these requirements, with audit rights and exit strategy provisions being the most common gaps.

Sub-outsourcing rules

Article 29(2) and Article 30(3)(a) address the ICT provider’s own supply chain. Contracts must require the provider to obtain prior approval before sub-outsourcing critical functions, inform the financial entity of any proposed changes to sub-contractors, and ensure sub-contractors meet the same contractual and security standards. According to a 2025 ECB supervisory review, the average number of sub-outsourcing layers for critical ICT services at significant credit institutions is 2.7, with some arrangements reaching five tiers.

How Does DORA’s Framework Relate to GDPR Article 28?

Financial entities implementing dora third party risk management will recognise significant overlap with GDPR’s data processor regime. GDPR Article 28 requires controllers to formalise the relationship through a data processing agreement containing mandatory clauses on instructions, security, sub-processing, audit rights, and data return or deletion.

Requirement GDPR Art. 28 DORA Art. 30
Written contract required Yes Yes
Security measures specified Yes Yes
Sub-processor controls Prior authorisation Prior approval + risk assessment
Audit and inspection rights Required Required (unrestricted for critical functions)
Data location transparency Implicit via transfers regime Explicit requirement
Incident notification 72-hour breach notification 4-hour initial, tiered reporting
Exit/data return provisions Data return or deletion Comprehensive exit strategy required

The key difference is scope: GDPR Article 28 applies only when personal data is processed, while DORA Article 30 applies to all ICT services regardless of personal data involvement. For a full mapping of how these two frameworks interact, see the DORA vs GDPR overlap analysis.

What Is the Register of Information Under Article 28(3)?

Article 28(3) introduces one of DORA’s most distinctive requirements: every financial entity must maintain and keep up-to-date a Register of Information covering all contractual arrangements with ICT third-party service providers. This register must be reported to the competent authority at least annually.

The register must document the identity of each provider, the functions and services provided, whether the arrangement supports a critical or important function, the start date, term, and renewal provisions, data processing and storage locations, and the applicable governing law.

According to the EBA’s implementation monitoring, 41% of financial entities reported difficulties in compiling a complete register by January 2025, primarily due to fragmented procurement records and informal IT arrangements. Legiscope automates the compilation and maintenance of this register, linking ICT provider records with corresponding GDPR processing activities to eliminate duplicate documentation effort.

The Register of Information operates alongside – but does not replace – the Records of Processing Activities required under GDPR Article 30. Where an ICT arrangement also involves personal data processing, both registers must be maintained. Organisations that align their documentation systems can reduce redundancy significantly, particularly when mapping providers against their GDPR compliance checklist.

How Does ESA Oversight of Critical Providers Work?

Articles 31 through 44 establish a direct oversight framework for ICT third-party service providers designated as critical. For the first time, an EU regulation gives financial supervisors the power to directly oversee technology companies that are not themselves financial institutions.

Designation and oversight powers

The ESAs – the EBA, ESMA, and EIOPA – designate critical providers based on systemic impact, substitutability, and the number and significance of financial entities relying on the provider. Designated providers are assigned a Lead Overseer who may conduct general investigations, on-site inspections, and issue binding recommendations.

If a critical provider fails to comply, the Lead Overseer may issue penalty payments of up to 1% of the provider’s average daily worldwide turnover for each day of non-compliance, for a maximum of six months.

What Exit Strategies Does DORA Require?

Article 28(8) requires financial entities to define and maintain exit strategies for every ICT arrangement supporting a critical or important function. This is not merely a termination clause – it is a documented plan for transitioning services without disruption.

Exit strategies must address transition planning with defined timelines, data portability and return mechanisms, continuity of service during the transition period, alternative arrangements including insourcing where appropriate, and regular testing of the exit plan’s feasibility. The regulation explicitly prohibits lock-in mechanisms that would prevent or unreasonably delay termination.

According to a 2025 DORA compliance survey, exit strategy documentation was the least mature area among financial entities, with only 28% having tested exit plans in place by the application date.

Frequently Asked Questions

What is the DORA Register of Information?

The Register of Information is a mandatory, up-to-date inventory of all contractual arrangements with ICT third-party service providers. Required by Article 28(3), it must be reported to the competent authority at least annually and include details on provider identity, services provided, data locations, and criticality classification.

Does DORA replace GDPR requirements for ICT providers?

No. DORA operates alongside GDPR. Where an ICT arrangement involves personal data processing, both DORA’s contractual requirements and GDPR Article 28 processor obligations apply simultaneously. See the DORA vs GDPR overlap analysis for a detailed comparison.

What happens if a critical ICT provider does not comply with ESA recommendations?

The Lead Overseer may impose penalty payments of up to 1% of the provider’s average daily worldwide turnover per day of non-compliance, for a maximum period of six months. The Lead Overseer may also recommend that financial entities suspend or terminate arrangements with the non-compliant provider.

How often must exit strategies be tested?

DORA does not prescribe a specific testing frequency, but Article 28(8) requires that exit plans be maintained, regularly reviewed, and practically feasible. Supervisory expectations, reflected in EBA guidance, point toward annual review and periodic testing aligned with the entity’s overall resilience testing programme.

Automate your GDPR compliance

Save 340+ hours per year on compliance work. Legiscope provides AI-powered GDPR management trusted by compliance professionals.

Discover Legiscope
TD
Written by
Dr. Thiébaut Devergranne
Fondateur de Legiscope et expert RGPD

Docteur en droit de l'Université Panthéon-Assas (Paris II), 23 ans d'expérience en droit du numérique et conformité RGPD. Ancien conseiller de l'administration du Premier ministre sur la mise en œuvre du RGPD. Thiébaut est le fondateur de Legiscope, plateforme de conformité RGPD automatisée par l'IA.