DORA Third-Party Oversight: Managing ICT Vendors Under DORA

Of DORA's five pillars, the fourth — ICT third-party risk management — is the one that generates the most operational work for the most firms. Where NIS2 addresses supply chain in a single sub-paragraph, DORA devotes Articles 28 to 30 (plus the oversight framework of Articles 31 to 44) to it, and backs the obligations with prescribed contractual provisions, a mandatory register, and a wholly new EU-level supervision regime for critical providers.

This article covers what Articles 28 to 30 require, how a financial entity should structure the third-party programme, and how the critical ICT third-party provider (CTPP) oversight regime works. For the broader DORA context, start with the complete NIS2 and DORA compliance guide, and for the comparison with NIS2's lighter regime, NIS2 vs DORA: Key Differences.

This is not legal advice. The ESA Joint Committee continues to publish technical standards affecting interpretation.

Why DORA's third-party regime is different

DORA's third-party pillar exists because the financial sector's resilience increasingly depends on a small number of ICT providers — hyperscale cloud platforms, core banking software vendors, market data providers. A concentration of dependency that, before DORA, no single supervisor had the mandate to examine.

DORA addresses this at two levels. At the entity level, every financial entity must manage its own ICT third-party risk under a prescribed framework (Articles 28 to 30). At the systemic level, the European Supervisory Authorities designate the most systemically important providers as critical ICT third-party providers and supervise them directly (Articles 31 to 44). The combination is what makes Pillar 4 heavier than any third-party regime in EU regulation before it.

Article 28 — the general third-party risk principles

Article 28 sets the foundational obligations for managing ICT third-party risk.

Integration into the risk framework

ICT third-party risk must be managed as an integral component of the ICT risk management framework under Pillar 1 — not as a separate, bolt-on process. See DORA ICT Risk Management Framework Explained for how Pillar 1 and Pillar 4 connect.

The strategy and policy

Financial entities must adopt, and regularly review, a strategy on ICT third-party risk, including a policy on the use of ICT services supporting critical or important functions. The management body approves this policy (linking back to Article 5 governance).

The Register of Information

Article 28(3) requires every financial entity to maintain a Register of Information covering all contractual arrangements for the use of ICT services provided by ICT third-party service providers. The Register distinguishes between ICT services supporting critical or important functions and those that do not. It must be kept current and made available to the competent authority on request. The Register is detailed enough to warrant its own treatment — see DORA Register of Information: Template and Requirements.

Pre-contractual assessment

Before entering into a contractual arrangement, a financial entity must:

• Assess whether the arrangement covers ICT services supporting a critical or important function
• Assess whether supervisory conditions for contracting are met
• Identify and assess all relevant risks, including the risk of the arrangement contributing to ICT concentration risk
• Undertake due diligence on prospective providers
• Identify conflicts of interest the arrangement may cause

Concentration risk

Article 29 specifically requires entities to assess ICT concentration risk — including the risk arising from contracting a provider that is not easily substitutable, and the risk of having multiple arrangements with the same provider or with closely connected providers. The assessment must consider the consequences of a provider's failure or large-scale disruption.

Exit strategies

For ICT services supporting critical or important functions, entities must have documented exit strategies — plans that allow the entity to withdraw from the arrangement without disruption to its business, without breaching regulatory requirements, and without detriment to service continuity and quality. The exit strategy must be tested.

Article 30 — mandatory contractual provisions

Article 30 is the most prescriptive part of Pillar 4. It specifies the provisions that must appear in contracts with ICT third-party service providers — and it sets a higher bar for contracts supporting critical or important functions.

Provisions required in all ICT service contracts

Every contract with an ICT third-party service provider must include, among others:

• A clear and complete description of all functions and ICT services to be provided
• The locations (regions or countries) where the services will be provided and where data will be processed and stored
• Provisions on availability, authenticity, integrity, and confidentiality of data
• Provisions on access, recovery, and return of data in an accessible format on termination
• Service level descriptions
• The provider's obligation to assist at no additional cost, or at a pre-determined cost, when an ICT incident related to the service occurs
• The provider's obligation to cooperate with the financial entity's competent authorities
• Termination rights and associated minimum notice periods
• Conditions for participation in the financial entity's ICT security awareness and digital operational resilience training

Additional provisions for critical or important functions

Where the contract supports a critical or important function, Article 30(3) requires further provisions, including:

• Full service level descriptions with precise quantitative and qualitative performance targets
• Notice periods and reporting obligations of the provider to the financial entity, including notification of developments that might materially impact the provider's ability to perform
• Requirements for the provider to implement and test business contingency plans, and to have ICT security measures, tools, and policies providing an appropriate level of security
• The provider's obligation to participate and fully cooperate in the financial entity's Threat-Led Penetration Testing where relevant
• Unrestricted rights of access, inspection, and audit by the financial entity, or an appointed third party, and by the competent authority
• Exit strategies, in particular a mandatory adequate transition period

The audit rights provision is among the most consequential — and among the most negotiated. DORA requires unrestricted access, inspection, and audit rights. Standard cloud-provider contracts historically did not grant these. The major hyperscalers have published DORA-aligned contractual addenda in response.

The critical ICT third-party provider regime

The second level of DORA's third-party architecture is the direct supervision of critical ICT third-party providers (CTPPs) — the first time EU authorities directly supervise non-financial firms.

Designation

The European Supervisory Authorities (EBA, ESMA, EIOPA, acting through the Joint Committee) designate CTPPs based on criteria in Article 31, including:

• The systemic impact on the stability, continuity, or quality of financial services were the provider to fail
• The systemic character or importance of the financial entities relying on the provider
• The reliance of financial entities on the provider for critical or important functions
• The degree of substitutability of the provider

The first list of designated CTPPs was published in 2025 and includes major cloud, software, and data providers serving the financial sector.

The Lead Overseer

Each CTPP is assigned a Lead Overseer from among the ESAs. The Lead Overseer can:

• Request information and documentation
• Conduct general investigations and on-site inspections
• Issue recommendations on, among other things, ICT security, subcontracting, and concentration
• Impose periodic penalty payments to compel compliance

The periodic penalty payment is DORA's most aggressive enforcement tool: up to 1% of the CTPP's average daily worldwide turnover, per day, imposed for up to six months, to compel a CTPP to comply with a Lead Overseer requirement. No comparable daily-accrual mechanism exists elsewhere in EU regulation for non-financial firms.

What CTPP designation means for financial entities

A financial entity does not need to do anything because a provider is designated a CTPP — the oversight obligation sits with the Lead Overseer, not the financial entity. But CTPP designation is useful intelligence: it tells the financial entity that the provider is systemically important and subject to EU-level scrutiny, which informs the entity's own concentration risk assessment.

📨 DORA's third-party RTS and the CTPP designation list keep evolving. Risk Letters tracks the updates. Free weekly briefing.

Building the third-party programme — a practical sequence

For an SME financial entity building Pillar 4, a workable sequence:

1. Inventory all ICT third-party arrangements — this becomes the Register of Information. Every contract for ICT services, no exceptions.
2. Classify each arrangement — does it support a critical or important function? This classification drives every subsequent obligation.
3. Build the Register of Information in the prescribed ITS format — see the dedicated article.
4. Run pre-contractual due diligence for any new arrangement, and retrospectively assess existing critical arrangements.
5. Assess concentration risk — substitutability of each critical provider, multiple arrangements with connected providers, the consequences of provider failure.
6. Remediate contracts — bring contracts for critical or important functions up to the Article 30(3) standard. Use providers' DORA addenda where available; negotiate where not.
7. Document exit strategies for every critical-or-important arrangement, and test them.
8. Establish ongoing monitoring — performance against SLAs, provider notifications of material developments, periodic review.

The contract remediation step (6) is typically the longest. Legacy contracts rarely meet the Article 30(3) bar, and renegotiation with a large provider moves at the provider's pace.

How this differs from NIS2 supply chain

For a financial entity, DORA Pillar 4 displaces the equivalent NIS2 supply chain obligation under the lex specialis rule. The differences in obligation depth:

• NIS2 — Article 21(2)(d): manage security in relationships with direct suppliers; no mandatory register, no prescribed contract terms
• DORA — Articles 28 to 30: mandatory Register of Information, prescribed contractual provisions, concentration risk assessment, tested exit strategies, and — at the systemic level — direct EU oversight of critical providers

A financial entity moving from a NIS2-style supplier programme to DORA Pillar 4 is not making an incremental adjustment. It is implementing a substantially more prescriptive regime. See NIS2 Supply Chain Security: What Article 21(2)(d) Requires for the NIS2 baseline.

Frequently asked questions

Does DORA's third-party regime apply to all our vendors, or just ICT vendors? It applies to ICT third-party service providers — providers of ICT services. A cleaning contractor is not in scope; a cloud host, a SaaS platform, or a market data provider is.

What is a "critical or important function"? A function whose disruption would materially impair the entity's financial performance, the soundness or continuity of its services, or its ability to meet regulatory requirements. The classification drives the heavier Article 30(3) obligations.

Do we have to use a CTPP, or avoid them? Neither. CTPP designation is a supervisory status, not a recommendation or warning. You may use designated CTPPs; their designation simply informs your concentration risk analysis.

Our cloud provider won't grant unrestricted audit rights — what do we do? The major cloud providers have published DORA-aligned contractual addenda granting the Article 30(3) rights. Request the addendum. Where a smaller provider will not, document the gap as a risk and assess substitutability.

Does the exit strategy need to be tested? Yes, for arrangements supporting critical or important functions. An untested exit strategy does not satisfy the obligation.

How does Pillar 4 connect to the Register of Information? The Register of Information under Article 28(3) is the documentary core of Pillar 4 — every ICT third-party arrangement recorded in the prescribed format. See DORA Register of Information: Template and Requirements.

Are microenterprise financial entities exempt from Pillar 4? No. Proportionality applies — microenterprises face a lighter regime in some areas — but the core third-party obligations, including the Register, apply.

The bottom line

Three takeaways:

1. Pillar 4 is the heaviest operational lift in DORA. Register, prescribed contracts, concentration analysis, tested exit strategies — for most firms this is the longest workstream.
2. The critical-or-important classification drives everything. Get it right early; the Article 30(3) obligations depend on it.
3. Contract remediation runs on the provider's clock. Start the renegotiation of legacy critical-function contracts before the deadline pressure builds.

For the Register of Information specifically, see DORA Register of Information: Template and Requirements. For how Pillar 4 sits within the full DORA framework, see DORA ICT Risk Management Framework Explained.

---

Sources & further reading

• Regulation (EU) 2022/2554 — DORA — Articles 28, 29, 30 (third-party risk management); Articles 31 to 44 (oversight framework for critical ICT third-party providers)
• Commission Implementing Regulation (EU) 2024/2956 — Register of Information template
• Joint Committee of the European Supervisory Authorities — RTS on subcontracting and on the oversight framework
• ESA designation of critical ICT third-party providers — first list, 2025