DORA ICT third-party risk: the register, the contracts, and the oversight regime

The short answer

DORA Articles 28 to 30 require every in-scope financial entity to know exactly which technology providers it depends on, to record those dependencies in a **register of information**, to assess concentration risk **before** signing, and to include a prescribed set of **contractual clauses** in every ICT services contract.

Articles 31 to 44 then add something without precedent in EU financial regulation: providers designated as **critical ICT third-party service providers** come under direct oversight by a European Supervisory Authority.

This is the pillar that generates the most work, and the one where supervisors have shown the most early interest — because the register is the artefact that reveals whether an entity actually understands its own dependencies.

Who this applies to

Financial entities in DORA Article 2 scope — and, through them, **their technology providers**.

If you sell software, infrastructure, data or managed services to EU financial institutions, DORA reaches your contracts even if you are not a financial entity and not established in the EU. Your customers cannot sign without the Article 30 clauses. **In practice this is how most providers first encounter DORA**: as a contract renewal that suddenly contains audit rights and exit obligations.

The register of information — Article 28

Every entity maintains a register of all contractual arrangements for the use of ICT services, at **entity, sub-consolidated and consolidated level**. Arrangements supporting **critical or important functions** are distinguished from the rest.

The register is not an internal convenience. Competent authorities can require it, and the European Supervisory Authorities use aggregated registers to identify which providers should be designated as critical. **Its structure and fields are specified in implementing technical standards adopted under the Regulation** — build to that specification rather than to a general vendor-inventory template, and check the current version before reporting, since the reference dates and collection cycles have been adjusted between cycles.

What it must capture, in substance: who the provider is and its identifiers, what service is provided, whether it supports a critical or important function, where data is processed and stored, the contract's start and end and notice periods, and the chain of subcontractors involved in the critical parts of the service.

**The subcontracting chain is the part that catches organisations out.** Knowing your direct provider is not enough when the function that would actually fail sits three layers down.

Assessment before signing — Article 29

Before entering an arrangement, the entity assesses whether it would lead to **ICT concentration risk**. The assessment considers, among other things:

This is a pre-contractual duty. Discovering concentration risk during a renewal is not compliance with Article 29 — it is a finding.

• whether the provider is **easily substitutable**, or whether multiple arrangements exist with the same provider or closely connected providers;
• the consequences of the provider's failure or disruption on the entity's ability to deliver its services;
• for arrangements supporting critical or important functions, the **subcontracting chain**, particularly where a subcontractor is established in a third country.

The mandatory contractual clauses — Article 30

Article 30(2) sets clauses required in **every** ICT services contract. In substance:

For arrangements supporting **critical or important functions**, Article 30(3) adds further requirements — including full service level descriptions with precise targets, notice periods and reporting obligations, requirements to implement and test **business contingency plans**, use of ICT security measures appropriate to the applicable regulatory framework, and **unrestricted rights of access, inspection and audit** for the entity, its appointees and competent authorities. **Exit strategies** must be in place, allowing the entity to exit without disruption to its business or breach of regulatory requirements.

**The audit right is the clause providers resist most**, and the one entities most often accept a watered-down version of. A right to receive a third-party assurance report is not the same as a right of access, inspection and audit — and Article 30(3) is explicit about which one it requires for critical or important functions.

• a clear and complete description of all functions and services, including whether subcontracting of a critical or important function is permitted and under what conditions;
• the **locations** where services are provided and where data is processed and stored, with notification of any change;
• provisions on **availability, authenticity, integrity and confidentiality** of data, including personal data;
• provisions ensuring **access, recovery and return** of data in an easily accessible format on insolvency, resolution, discontinuation or termination;
• **service level descriptions**, with precise quantitative and qualitative performance targets;
• an obligation on the provider to give **assistance at no additional cost, or at a cost determined in advance**, when an ICT incident related to the service occurs;
• an obligation on the provider to **cooperate fully** with the entity's competent authorities and resolution authorities;
• **termination rights** and associated minimum notice periods;
• conditions for **participation in the entity's security awareness and training programmes**.

Oversight of critical providers — Articles 31 to 44

The European Supervisory Authorities designate certain providers as **critical ICT third-party service providers**, based on criteria in Article 31(2): the systemic impact on the stability, continuity or quality of financial services should the provider face a large-scale operational failure; the systemic character or importance of the financial entities relying on it; the degree of substitutability; and the number of Member States in which it operates.

Each designated provider is assigned a **Lead Overseer** — EBA, ESMA or EIOPA. The Lead Overseer may request information, conduct general investigations and on-site inspections, and issue recommendations.

**The enforcement mechanism runs through the customer relationship.** Where a designated provider does not comply with the Lead Overseer's recommendations, competent authorities may require financial entities to **suspend, in part or entirely, the use of the service**, or to terminate the arrangement. A provider that ignores the framework risks having its financial-sector customers instructed to leave.

Providers may also be designated **on a voluntary opt-in basis** under Article 31(11).

The failure modes

**Treating the register as a vendor list.** A procurement spreadsheet does not answer Article 28. The register is structured by function criticality and includes the subcontracting chain — most vendor lists have neither.

**Mapping only direct suppliers.** The function that fails is often three layers down. Article 30 requires knowing whether subcontracting of a critical or important function is permitted, and under what conditions.

**Accepting an assurance report in place of an audit right.** Article 30(3) requires unrestricted rights of access, inspection and audit. A SOC 2 report is evidence a provider may offer; it is not the contractual right the Regulation requires.

**Writing an exit strategy that cannot be executed.** An exit plan that assumes data can be retrieved in a usable format, without having tested that assumption against the actual contract and the actual export capability, is a document rather than a plan.

**Assuming intra-group arrangements are out of scope.** They are not. Intra-group ICT service arrangements fall within the framework, and the assumption that a sister company needs no contractual clauses is a common gap.

**Confusing designation with obligation.** Whether a provider is designated critical does not change what *your* contract must contain. Article 30 applies to every arrangement regardless of the provider's designation status.

What to build first

1. **The register**, to the specification in the applicable implementing standards. Longest lead time, first thing asked for. 2. **The critical-or-important-function determination.** Almost every other obligation is scoped by it. 3. **A contract gap analysis** across the existing estate against Article 30(2) and (3). Most portfolios need renegotiation, not drafting from scratch. 4. **Concentration risk assessment** as a pre-contractual gate in procurement, not a periodic review. 5. **Exit strategies that have been tested**, at least on paper, against the actual export capability of the provider.

Tools available on NexCyber

• Free applicability assessment — confirm DORA scope under Article 2
• Compliance responsibility mapper — who owns the register, by role
• Penalty calculator — exposure by regulation

Further reading

→ What is DORA — scope, the five pillars and the 2025 date → Threat-led penetration testing under DORA Article 26 → DORA × NIS2 — which instrument governs when both apply → One evidence set across five EU regulations → DORA regulation overview

*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. The register's structure and the reporting cycle are set in implementing technical standards that are amended over time — verify against the current text and record the date checked. Consult your competent authority or a qualified adviser.*