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.
Since 17 January 2025, the applicable obligations are binding on in-scope financial entities, subject to Article 2 exclusions and proportionality. 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, an up-to-date Register of Information and the applicable supervisory reporting, exit strategies ensuring continuity, and sub-outsourcing controls governing the provider’s own supply chain.
The first control is a reconciled inventory: compare procurement records, accounts payable, architecture dependencies and business-owner knowledge. An agreement can provide ICT services even if the internal purchasing system calls it a consultancy or licence.
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 addresses ICT concentration risk, including difficulty substituting a provider and multiple arrangements with the same or closely connected providers. Map common underlying dependencies, not just the names of direct suppliers. A multi-provider strategy is one possible mitigation; DORA does not impose a universal requirement to buy from several cloud providers.
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
For ICT services supporting critical or important functions, Article 30(3) adds detailed service levels, relevant notification and reporting duties, tested continuity and security arrangements, participation in TLPT, effective access/inspection/audit rights and an adequate transition period. It does not impose a universal four-hour provider-to-customer incident notice. The financial entity’s regulatory reporting clock must instead inform workable contract escalation deadlines.
Record every gap against the correct paragraph: Article 30(2) applies to contractual arrangements generally; Article 30(3) adds requirements for services supporting critical or important functions. This prevents both missing enhanced requirements and misrepresenting them as identical for every service.
Sub-outsourcing rules
Article 30(2)(a) requires the contract to identify whether subcontracting of services supporting critical or important functions, or material parts, is permitted and on what conditions. Delegated Regulation (EU) 2025/532 adds the relevant assessment and contractual detail, including material-change notification, adequate time to assess changes, objections and termination conditions. Do not substitute a generic prior-approval clause for understanding and monitoring the arrangement.
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 specific or general written authorisation | Defined permitted subcontracting, risk assessment and material-change controls |
| Audit and inspection rights | Required | Required (unrestricted for critical functions) |
| Data location transparency | Implicit via transfers regime | Explicit requirement |
| Incident support | Processor notifies controller without undue delay under Art. 33(2) | Provider assistance and relevant contractual reporting; entity reports under Art. 19 |
| Exit/data return provisions | Data return or deletion | Comprehensive exit strategy required |
The key difference is scope: GDPR Article 28 applies to processing of personal data on behalf of a controller, 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. Article 28(3) requires at least annual reporting on new arrangements, provider categories, types of arrangements and services. The complete register, or requested sections, must be made available on request. Follow the separate authority instructions for register submissions and reference dates.
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.
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 recommendations whose follow-up is governed by Article 42.
Article 35(6)–(8) permits periodic penalty payments for failure to comply with specified information, investigation, inspection or remediation-report requests. This is not an automatic fine for declining every recommendation. Article 42 separately governs notification of intended follow-up or a reasoned explanation, and competent authorities’ possible last-resort action toward financial entities.
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 plan must address obstacles to transition in practice, including proprietary formats, dependencies, capacity and contractual support.
Before a renewal, verify that the assumed alternative is actually available, can accept the exported data and has enough capacity. A list of alternative vendor names does not establish an executable exit.
Review a material subcontracting change
Suppose a critical payment-service supplier proposes moving managed database operations to a new subcontractor. Preserve the notice and planned effective date. Identify the services and data affected, support locations, privileged access, onward dependencies and changes to recovery arrangements. Ask for missing evidence early enough to make a decision before implementation.
The decision record should connect the subcontractor to the contract, supported function and risk assessment. Record whether the change remains within risk tolerance, what safeguards are needed, who owns them, and whether there is an objection or termination trigger under the agreement. If the service processes personal data, separately apply GDPR Article 28 and any transfer assessment. Approval under one framework does not automatically complete the other.
Update the register where the change affects its required data, and test the consequences for the exit plan: can the entity retrieve data if the direct provider and subcontractor disagree? Route unresolved issues to the accountable service owner. Retain the final supplier response and the entity’s decision, not merely a screenshot showing that someone opened the notification email.
For the register’s actual templates and collection arrangements, use the EBA reporting resources. Validate identifiers and relationships as well as file format, and reconcile the result with the procurement inventory before submission.
Where a provider change exposes an unresolved control gap, a supplier remediation and verification plan keeps interim safeguards and closure evidence tied to the responsible decision.
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 distinguishes arrangements supporting critical or important functions. It is maintained continuously, made available on request and submitted under applicable supervisory collection instructions; the Article also sets an annual reporting duty on new arrangements and related categories.
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?
Article 42 requires the provider to notify its intention to follow recommendations or explain why not within 60 calendar days. National competent authorities assess the resulting risks for financial entities and can ultimately require suspension or termination under the statutory conditions. Article 35 periodic penalties concern the specified oversight requests, with a ceiling of 1% of average daily worldwide turnover per day for no more than six months.
How often must exit strategies be tested?
Article 28(8) requires comprehensive, documented exit plans that are sufficiently tested and reviewed periodically in accordance with the proportionality criteria. Set a justified review and testing schedule and reopen the plan when the service or dependency changes; the Article does not impose one universal annual exit test.
FAQ
What does DORA require for third-party ICT risk management?
Chapter V DORA requires: a pre-contract due diligence process; contractual protections (audit rights, SLAs, exit provisions under Art. 30); ongoing monitoring; concentration risk assessment; and inclusion in the Register of Information. Critical functions require enhanced oversight.
What makes an ICT service a “critical or important function” under DORA?
Article 3(22) DORA: a function is critical if its disruption would materially impair financial performance, soundness, continuity of services, or compliance obligations. Risk assessment must identify which functions meet this threshold and apply enhanced third-party management to those.
Can financial entities use the same cloud provider for multiple critical functions?
Yes, but Article 29 DORA requires concentration risk assessment and mitigation. Relying on a single provider for multiple critical functions creates systemic risk that must be documented, managed, and reported to competent authorities. Exit strategies must be credible and tested.
What contractual provisions must DORA ICT contracts include?
Article 30 DORA mandates: full service description and SLAs; data location and portability rights; access and audit rights for the financial entity and regulators; DORA-compliant incident notification; business continuity and exit provisions. Contracts lacking these provisions must be renegotiated.
Applying the workflow in a startup team
For a fintech establishing its first ICT supplier inventory, connect the contract owner, service dependency and exit evidence before comparing software. The DORA tooling guide for startup teams is a related procurement resource for that work. Assess the actual regulatory scope and vendor offer rather than assuming that a startup label determines obligations or price.
Related reading: