Skip to content
The Algorithm
InsightsCompliance Engineering
Compliance EngineeringFinancial Services9 min read · 2026-03-19

DORA ICT Third-Party Risk: What Banks Are Getting Wrong

Art. 28
DORA Article 28 — the ICT third-party risk management requirement most banks are addressing with spreadsheets
DORA's ICT third-party risk requirements under Chapter V are not satisfied by a vendor risk questionnaire. Article 28 mandates a Register of Information covering all ICT third-party providers. Article 30 specifies mandatory contractual provisions. The concentration risk provisions create specific engineering obligations around cloud provider dependency. What the technical implementation of ICT risk management actually looks like, and where banks are consistently creating examination risk.

DORA's Chapter V — Articles 28 through 44 — creates an ICT third-party risk management framework that is meaningfully more demanding than the vendor risk questionnaire approach most financial institutions used before January 2025. The framework has three components with engineering obligations: the Register of Information, the mandatory contractual provisions of Article 30, and the concentration risk requirements that constrain cloud architecture decisions.

The examination pattern emerging from European supervisory authorities in 2025: examiners are asking to see the Register of Information and testing whether it accurately reflects the ICT third-party relationships that can be inferred from the firm's technology stack. Registers built by compliance teams from vendor contracts — without engineering input on actual system dependencies — consistently fail this test. The API calls, webhook endpoints, and data transfers that engineering teams treat as implementation details are third-party ICT service dependencies under DORA.

The Register of Information: What It Must Contain

Article 28(3) requires financial entities to maintain and update a register of information on all contractual arrangements with ICT third-party service providers. The EBA ITS on the Register of Information (published 2024) specifies required fields in detail. The critical fields from an engineering perspective: the functions supported or assets underpinned by the ICT service; data sensitivity; whether the service is critical or important; the jurisdictions where data is stored or processed; and sub-outsourcing arrangements. Building the Register from contracts alone produces a Register that omits the engineering reality — actual dependencies, data flows, and jurisdictions.

Article 30: Mandatory Contractual Provisions

Article 30 specifies minimum provisions that contracts with ICT third-party service providers must include. The provisions with direct engineering implications: full service level descriptions; provisions on data location; cooperation and audit rights; the right to a transition period that preserves business continuity when the contract terminates; provisions on data recovery and return. The audit rights provision is frequently missing or limited in standard cloud provider contracts — the negotiated addenda required to satisfy Article 30 for AWS, Azure, and GCP are available but require procurement-level action to include.

The Engineering Reality

DORA's concentration risk provisions under Article 29 require financial entities to assess the risk of concentration of ICT third-party dependencies. The EBA guidelines specify that concentration risk exists when a single provider accounts for a significant proportion of critical or important functions. In practical terms: if more than one critical business function depends on a single cloud provider, the concentration risk assessment must include a viable exit strategy. "We would migrate to another cloud provider" is not a viable exit strategy without an architecture that makes that migration feasible in the required timeframe.

Critical ICT Third-Party Providers: The Direct Oversight Regime

DORA Article 31 empowers the ESAs (EBA, ESMA, EIOPA) to designate ICT third-party service providers as critical (CTPPs) and subject them to direct oversight. The first CTPP designations were published in 2025. If your cloud provider, core banking platform, or major SaaS provider is designated as a CTPP, the oversight framework changes. Financial entities using CTPPs must ensure their contracts include provisions enabling ESA cooperation.

Implementation Architecture for Article 28 Compliance

  1. Build the Register of Information from engineering discovery, not contract review — map actual API dependencies, data flows, and third-party service calls
  2. Categorize each third-party service by function criticality, data sensitivity, and jurisdiction — the EBA ITS fields are the minimum
  3. Audit cloud provider contracts for Article 30 mandatory provisions — negotiate addenda for missing provisions before next renewal
  4. Conduct a concentration risk assessment with input from engineering and architecture teams — not just risk and compliance
  5. Implement a process for keeping the Register current as engineering adds new third-party dependencies
  6. Check ESA CTPP lists quarterly and update contractual arrangements for newly designated providers
Related Articles
Compliance Engineering

EU AI Act: What CTOs Actually Need to Do Before August 2026

Read →
Compliance Engineering

DORA Is Live. Here's What 'Operational Resilience' Means for Your Codebase

Read →
Compliance Engineering

FedRAMP Rev 5: What Changed and Why Most Current ATO Holders Are Already Non-Compliant

Read →
Facing This?

The engineering behind this article is available as a service.

We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.

Talk to an EngineerSee Case Studies →
Engage Us