The Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has applied to EU financial entities - banks, insurers, investment firms, payment and e-money institutions, and several other regulated categories - since 17 January 2025. Most of what makes DORA distinctive for TPRM sits in Chapter V, "Managing of ICT third-party risk," which does not merely encourage good vendor governance; it specifies a register to maintain, an assessment to run before signing, and clauses a contract must contain. Financial entities carry these obligations directly, and push them onto ICT providers through contract, which is why DORA reshapes vendor risk practice well beyond the regulated entities that are formally in scope.
What Chapter V actually requires (Articles 28-30)
Article 28, "General principles," is the foundation: a financial entity remains fully responsible for compliance even when it outsources, and must adopt a documented strategy for ICT third-party risk proportionate to the nature, scale, and complexity of its dependencies. Before signing any ICT contract it must run due diligence covering the criticality of the function, the provider's suitability, and concentration and conflict-of-interest risk. It must maintain a Register of Information on every ICT contractual arrangement at both entity and group level, report material new arrangements to its competent authority each year, and notify the authority in advance before contracting for a function it considers critical or important. For those critical-or-important arrangements specifically, it also needs a documented exit strategy before the relationship starts - the same obligation this cluster covers generally in vendor offboarding.
Article 29, "Preliminary assessment of ICT concentration risk at entity level," requires assessing - before contracting for a critical or important function - whether the provider is easily substitutable, whether the entity already has other arrangements with the same or a closely connected provider, and how complex or opaque subcontracting chains might limit its ability to actually monitor what it signed up for. This is the article behind the concentration-risk discipline covered in depth in concentration risk.
Article 30, "Key contractual provisions," is the most operational: it lists a baseline set of clauses every ICT contract needs, plus an enhanced set required specifically for contracts supporting a critical or important function.
| Every ICT contract | Critical or important functions, additionally |
|---|---|
| Single written document describing all rights, obligations, and services in full | Precise, quantitative and qualitative service-level targets, not general commitments |
| Data processing locations, with advance notice of any change | Reporting obligations for events materially affecting service delivery |
| Data protection, availability, integrity, and confidentiality commitments | Documented business contingency plans and security measures |
| Data access, recovery, and return in an accessible format if the provider becomes insolvent | Mandatory participation in the entity's threat-led penetration testing |
| Provider assistance during ICT incidents at no extra cost | Unrestricted audit and inspection rights for the entity or its delegate |
| Full cooperation with competent and resolution authorities | A documented exit strategy with an adequate transition period |
| Termination rights with a minimum notice period; provider participation in security-awareness training |
Subcontracting: the fourth-party chain, formalized
DORA does not let oversight stop at the direct provider. Commission Delegated Regulation (EU) 2025/532, the regulatory technical standard adopted under Article 30(5) and in force since 22 July 2025, specifies exactly what a financial entity must determine and assess before a provider is allowed to subcontract an ICT service supporting a critical or important function - which subcontractors are involved, what each one delivers, whether a subcontractor's failure would disrupt the service, and what contractual visibility the entity retains into changes further down the chain. In practice this is fourth-party risk written into a binding technical standard rather than left to a program's own judgment.
The Register of Information, in practice
Article 28(3)'s register is not a one-time filing. The first reference date was 31 March 2025, with national competent authorities submitting entities' consolidated registers to the European Supervisory Authorities (the EBA, ESMA, and EIOPA - collectively the ESAs) by 30 April 2025, and the cycle repeats annually. Building this register from scratch under deadline pressure is exactly the failure mode described in why manual vendor risk assessment doesn't scale: the register is only accurate if the underlying vendor and subcontractor inventory - see vendor tiering - is kept current year-round, not reconstructed once a year from memory and spreadsheets.
Oversight of critical ICT third-party providers
Chapter V's second section builds a direct supervisory layer over the ICT providers the financial sector depends on most. Article 31, "Designation of critical ICT third-party service providers," sets the criteria the ESAs use: the systemic impact of the provider's failure, how many and how important the dependent financial entities are, how much those entities rely on the provider for critical functions, and whether viable substitutes exist. A designated provider is assigned a Lead Overseer - the ESA responsible for the financial sector with the largest aggregate exposure to it - whose tasks under Article 33 include assessing the provider's ICT risk management across nine areas (security requirements, physical security, governance, incident handling, testing, and more) and issuing an annual oversight plan. Non-EU providers designated as critical must establish an EU subsidiary within twelve months. On 18 November 2025 the ESAs published the first list, designating 19 providers spanning cloud infrastructure and other ICT services for direct oversight; the list is reviewed and republished annually, so a provider's status can change.
Turning DORA into a working TPRM program
- Treat the register as a living system, not a filing. The entity- and group-level Register of Information is only ever as accurate as the vendor and subcontractor inventory feeding it - build that inventory once and keep it current, rather than reconstructing it before each annual deadline.
- Run the Article 29 concentration check before signing, not after. Substitutability, shared-provider exposure, and subcontracting-chain complexity are pre-contract questions under DORA, which is a stronger requirement than most programs' existing tiering process assumes.
- Audit existing ICT contracts against the Article 30 table. Most legacy vendor agreements are missing several baseline clauses, and almost all are missing the enhanced set for anything supporting a critical or important function.
- Extend due diligence down the subcontracting chain for any critical or important function, per the Article 30(5) RTS - this is where fourth-party visibility stops being optional.
- Watch the CTPP list annually. If a provider you depend on is newly designated critical, expect Lead Overseer findings that are directly relevant to your own risk assessment of that provider.
- Make monitoring continuous, not annual. Article 28's notification and register-update duties are ongoing, which lines up with the shift to continuous vendor monitoring generally.
DORA is a compliance floor, not a program
Meeting DORA's letter - a filed register, signed contract addenda, a documented concentration assessment - is necessary but not sufficient; the harder part is keeping all three current as vendors, subcontractors, and contracts change throughout the year. Governance-heavy platforms such as OneTrust and ProcessUnity are well suited to managing the contractual and documentation side of that record. Continuous-monitoring providers such as BitSight and SecurityScorecard help surface the concentration and subcontractor signal Article 29 asks for. Rescana's approach pairs continuous, evidence-based monitoring with automated evidence collection specifically so the register and audit trail stay current between formal reviews rather than going stale the day they are filed - the same gap covered generally in evidence-based risk scoring.
Frequently asked questions
What does DORA require for third-party ICT providers?
DORA's Chapter V requires EU financial entities to run due diligence and a concentration-risk assessment before contracting for any ICT service, maintain a Register of Information covering every ICT contractual arrangement at entity and group level, and include specific contractual provisions in every ICT contract - with an enhanced set of clauses (precise service levels, audit rights, exit strategy, threat-led penetration testing participation) for contracts supporting a critical or important function. A related regulatory technical standard, Commission Delegated Regulation (EU) 2025/532, further requires assessing the subcontracting chain behind any critical or important ICT service. Financial entities are directly responsible for these obligations and typically flow them down to providers through contract.
What is the DORA Register of Information?
The Register of Information, required under DORA Article 28(3), is a record every in-scope financial entity must maintain of all its contractual arrangements for ICT services, at both entity and consolidated group level, updated on an ongoing basis and reported to its national competent authority annually. The first reference date was 31 March 2025, with competent authorities submitting entities' registers to the European Supervisory Authorities by 30 April 2025, and the cycle repeats each year. It only produces an accurate regulatory filing if the underlying vendor and subcontractor inventory behind it is kept current year-round rather than assembled once under deadline pressure.
Which providers are designated as critical ICT third-party providers under DORA?
DORA Article 31 lets the European Supervisory Authorities (the EBA, ESMA, and EIOPA) designate ICT third-party providers as critical based on the systemic impact of their failure, how many and how important the dependent financial entities are, reliance on the provider for critical functions, and the availability of substitutes. Each designated provider is assigned a Lead Overseer with direct supervisory powers under Articles 32 and 33. The ESAs published the first list of designated critical providers on 18 November 2025, covering 19 providers across cloud infrastructure and other ICT services; the list is reviewed and republished annually, so which providers are in scope can change.
Does DORA apply to ICT providers based outside the European Union?
Indirectly, yes. DORA's obligations formally bind EU financial entities, not ICT providers directly, but financial entities are required to flow key requirements - contractual provisions, audit rights, exit strategies, subcontracting due diligence - down to any provider they use regardless of where that provider is based. Providers designated as critical ICT third-party providers face a further, direct requirement: if established outside the EU, they must set up a subsidiary within the Union within twelve months of designation, bringing them under the same oversight framework as EU-based critical providers.