RegTech — DORA Compliance

DORA Third-Party ICT Risk: Complete Compliance Guide for Financial Entities (2025–2026)

The Digital Operational Resilience Act — Regulation (EU) 2022/2554, in force since 17 January 2025 — has reshaped the entire compliance landscape for financial entities operating in the EU. Of all its chapters, Chapter V (Articles 28–44) is universally acknowledged as the most operationally demanding. It governs DORA third-party ICT risk: how financial entities must identify, contract, monitor, and exit relationships with every technology provider that supports a critical or important function. This is not a theoretical exercise. According to the European Banking Authority’s 2024 impact analysis, 65% of EU financial entities rely on three or more critical ICT providers for core operations — and the vast majority of those relationships were contractually underprepared when DORA entered into force.

This guide walks through every major pillar of Chapter V — from the mandatory ICT provider register to mandatory contract clauses, from concentration risk to TLPT scheduling — and shows how IgeraRegTech automates the compliance workflow for financial entities of any size.

What Chapter V of DORA Actually Requires (Arts. 28–44): The Big Picture

Chapter V is built around three core obligations that apply to all in-scope financial entities — banks, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, fund management companies, crypto-asset service providers, and crowdfunding platforms:

1. Maintain a complete ICT third-party provider register (Art. 28(3)) covering every contractual ICT relationship, not just critical ones.
2. Embed mandatory contractual clauses (Art. 30) in every contract with an ICT provider supporting a critical or important function — including audit rights, exit strategy, incident notification, data portability, and SLAs with numeric RTO/RPO targets.
3. Manage and document concentration risk (Art. 29) — both internal (reliance on a single provider) and sectoral (when your provider also serves large portions of the financial sector).

On top of these three pillars, Arts. 31–44 establish the EU-level oversight framework for Critical Third-Party Providers (CTPPs): ESA designation, Lead Overseer appointment, Joint Examination Teams, and a fine structure that reaches up to 1% of the CTPP’s global daily turnover.

Who Qualifies as a Critical ICT Third-Party Provider (CTPP)?

DORA Art. 31 defines CTPPs as those formally designated by the Joint Committee of the European Supervisory Authorities after an assessment against criteria set out in the Regulatory Technical Standards (RTS). Designation is not self-declared: it is a formal act by EBA, EIOPA, or ESMA. The criteria for designation include:

• Systemic impact: the number and nature of financial entities relying on the provider for critical or important functions.
• Interdependency: the degree to which those financial entities are interconnected — creating cascade risk if the provider fails.
• Replaceability: how easily a financial entity could switch to an alternative provider in the event of failure or termination.
• Criticality of services: whether the services support payment processing, settlement, custody, core banking, or other systemically significant functions.

In practice, the providers most likely to be designated include: hyperscale cloud providers (AWS, Microsoft Azure, Google Cloud Platform), core banking SaaS vendors (Temenos, Finastra, Mambu), financial data and analytics platforms (Bloomberg, Refinitiv/LSEG, S&P Market Intelligence), and enterprise cybersecurity vendors providing managed detection, SIEM, or SOC services. The ESAs began publishing preliminary designation assessments in late 2024, with formal designations expected throughout 2025–2026.

Crucially, a provider does not need to be formally designated a CTPP for Art. 30 obligations to apply. Every financial entity must classify its own ICT providers as “critical” or “important” at entity level, based on its own internal risk assessment. A small payment institution’s core-banking provider may never be designated as a CTPP by the ESAs, yet that provider is still “critical” for that institution — and Art. 30 mandatory clauses apply in full.

The ICT Third-Party Provider Register (Art. 28(3)): What Must Be Documented

Article 28(3) requires financial entities to maintain an up-to-date register of all contractual arrangements with ICT third-party service providers — not just those classified as critical. This register must be available to supervisors on request at any time.

The European Supervisory Authorities’ RTS specifies the data fields that must be captured for each ICT provider. Based on the final RTS published in January 2024, the register must include:

Key Contractual Obligations Under Art. 30: The Minimum Mandatory Clauses

Article 30 is the provision that most directly reshapes commercial relationships between financial entities and their ICT vendors. Any ICT service contract that supports a critical or important function must include all of the following mandatory provisions:

One of the most significant practical implications of Art. 30 is its retroactive reach: existing contracts must be reviewed and amended to include these clauses for all critical and important ICT providers. The EBA guidance published alongside the RTS indicated that financial entities should have completed contract reviews for critical functions by mid-2025. Contracts with non-critical providers must be updated at next renewal.

Concentration Risk Under DORA Art. 29: Systemic Implications

Article 29 addresses one of the most structurally complex aspects of DORA third-party ICT risk: what happens when a large proportion of the financial sector depends on the same provider. This is not a theoretical scenario. The hyperscale cloud market is dominated by three providers (AWS, Azure, GCP), and concentration at this level creates systemic risk that no individual financial entity can fully mitigate on its own.

DORA’s response is two-pronged. At entity level, each financial institution must assess its own ICT concentration risk — mapping which functions are over-reliant on a single provider and documenting the mitigation strategy (multi-cloud architecture, contractual exit rights, shadow infrastructure). At sectoral level, the ESAs may formally designate CTPPs and appoint a Lead Overseer (ESMA, EBA, or EIOPA, depending on the sector of most affected entities) with authority to conduct Joint Examination Teams (JETs) — multi-regulator inspections of the provider’s ICT infrastructure, security controls, incident management, and subcontractor oversight.

For financial entities, the practical obligation is clear: if more than 60–70% of your critical ICT functions run through a single provider, this must be documented in your ICT risk framework as a material concentration risk, with a mitigation plan and timeline for diversification. Supervisors will scrutinise this during DORA-related inspections.

DORA vs. EBA Outsourcing Guidelines (EBA/GL/2019/02): What Changes, What Stays

Many financial entities approach DORA through the lens of the EBA Outsourcing Guidelines, which have governed their ICT vendor management since 2019. Understanding the relationship between the two frameworks is essential to avoid duplication — and to identify where genuinely new work is required.

Practical Compliance Timeline for DORA Chapter V

DORA became enforceable on 17 January 2025. The compliance timeline for Chapter V obligations rolls through 2025 and into 2026:

• January 2025 (done): DORA enforcement began. ICT risk management framework and preliminary ICT provider register should have been in place by this date.
• Mid-2025: Critical-function ICT contracts reviewed and amended to include Art. 30 mandatory clauses. EBA/EIOPA/ESMA supervisory inspections of DORA readiness underway in several member states.
• End of 2025: First Digital Operational Resilience Testing (DORT) cycle completed for entities subject to advanced testing requirements. All ICT providers supporting critical functions tested through scenario-based exercises. ICT concentration risk assessment documented and submitted to internal governance.
• 2026: Threat-Led Penetration Testing (TLPT) required for significant financial entities under Art. 26. TLPT must include in-scope critical ICT providers as participants. ESA CTPP designation decisions expected throughout 2026 for first wave of hyperscale cloud and data providers.
• Ongoing: Annual register review, continuous monitoring of ICT providers, incident classification and reporting under Art. 19–23, and TLPT on a three-year cycle thereafter.

Real-World Case Study: Fintech Payments SL — From 78% Gap to 12% in 90 Days

Fintech Payments SL (fictitious name; representative of a Spanish payment institution authorised by the Banco de España with annual processing volume of €2.4bn) engaged IgeraRegTech in October 2024 to conduct a full DORA Chapter V gap assessment ahead of the January 2025 enforcement date. The assessment revealed a compliance gap of 78% against Chapter V requirements:

• ICT provider register covered only 9 of 34 active ICT vendors (the other 25 had never been formally documented).
• Only 4 of 34 contracts included Art. 30-compliant audit rights clauses; none included DORA-standard exit strategy provisions.
• Concentration risk assessment was absent: 71% of critical ICT functions ran through a single cloud provider.
• No SLA documentation existed with numeric RTO/RPO targets for any of the 34 vendors.
• No incident notification obligation had been included in any vendor contract.

Using IgeraRegTech’s DORA Chapter V compliance platform, the team at Fintech Payments SL completed the following in 90 days:

1. Built a complete 34-vendor ICT register using the automated intake wizard, pre-populated with contract data extracted from PDFs via the document parsing engine.
2. Ran the Art. 30 clause gap checker across all 34 contracts: the tool flagged missing clauses in each contract and generated amendment drafts for legal review.
3. Generated concentration risk heatmap: one cloud provider accounted for 71% of critical function capacity. IgeraRegTech produced a structured concentration risk report with remediation options (multi-cloud architecture plan, contractual redundancy provisions).
4. Built incident escalation chains for all critical ICT providers, ensuring the 4-hour notification obligation would be met.
5. Created exit strategy documents for the 11 vendors classified as critical or important.

By January 2025 (enforcement date), Fintech Payments SL’s DORA Chapter V compliance gap had been reduced from 78% to 12%. The remaining 12% related to contractual renegotiations with two international cloud providers that required multi-month commercial negotiation cycles. The entity had a documented remediation plan accepted by its internal Audit Committee. Zero supervisory concerns were raised during Banco de España’s initial DORA readiness survey in Q1 2025.

How IgeraRegTech Automates DORA Chapter V Compliance

Managing DORA third-party ICT risk across dozens of vendors, hundreds of contract clauses, and evolving regulatory timelines is operationally intensive. IgeraRegTech’s DORA module was purpose-built to automate the most labour-intensive parts of the Chapter V compliance workflow:

• Art. 28 Register Generation Wizard: guided intake process that collects all mandatory register fields, auto-populates from uploaded contracts, and maintains version history. Exports in ECB/EBA-compatible format for supervisory reporting.
• Art. 30 Contract Clause Checker: upload any ICT contract (PDF or DOCX) and the engine checks it against all 10 mandatory Art. 30(2) clauses, flags absences, and generates a redline amendment document for legal sign-off.
• Concentration Risk Dashboard: visual heatmap of ICT function dependency by provider, with configurable thresholds for material concentration risk alerts. Tracks changes over time as provider portfolio evolves.
• Incident Escalation Chain Builder: define and test notification flows for each critical ICT provider, ensuring the Art. 19 4-hour major incident notification obligation is operationally achievable.
• TLPT Scheduling Assistant: maps critical ICT providers against TLPT scope requirements, generates a testing calendar that meets the Art. 26 three-year cycle, and tracks provider participation confirmations.
• Regulatory Update Feed: automated alerts when ESA guidance, RTS amendments, or supervisory Q&A affect Chapter V obligations, with impact assessment for your specific provider portfolio.

Frequently Asked Questions on DORA Third-Party ICT Risk

1. Does DORA apply to SaaS tools like Microsoft 365 or Salesforce?

It depends on what function those tools support. DORA Art. 3(21) defines ICT services broadly — including SaaS — and Art. 28 covers all ICT third-party relationships. If Microsoft 365 is used for internal communication and administration only (not for processing client data, transactions, or regulatory reporting), it may be classified as non-critical. However, if it supports critical functions — for example, if your entire incident communication workflow relies on Teams, or your regulatory reporting emails transit through Exchange Online — it must be registered and the contract assessed for Art. 30 compliance. The classification decision must be documented with a risk rationale.

2. What if a critical ICT provider refuses to grant audit rights?

A provider’s refusal to grant audit rights as required by Art. 30(2)(f) creates a direct compliance problem for the financial entity. DORA does not permit the financial entity to accept a contract that excludes or materially restricts audit rights for services supporting critical or important functions. In practice, large providers (hyperscale cloud, major SaaS vendors) are standardising on DORA-compliant audit right provisions. If a provider continues to refuse, the financial entity must either reclassify the function as non-critical (with documented justification) or commence transition to an alternative provider. The refusal itself should be documented as a risk indicator in the ICT provider register.

3. How must we assess sub-outsourcing chains under DORA?

Art. 30(2)(a) and (i) require that the subcontractor chain supporting any critical ICT service is documented and that the financial entity has visibility into material changes. In practice, this means: (a) at contract signature, require the provider to disclose all material subcontractors and the jurisdictions they operate in; (b) include a clause requiring prior written notification — with right to object — for any material change to the subcontractor chain; (c) assess whether subcontractor jurisdictions introduce data sovereignty risk (especially for non-EEA processing under GDPR Chapter V). The financial entity is not required to directly audit subcontractors, but must ensure its primary provider has contractual controls over its supply chain.

4. What are the penalties for non-compliant ICT contracts under DORA?

DORA itself sets out penalties for financial entities in Art. 50–52, leaving the specific sanction levels to member state implementation. The ECB can impose fines up to €5m on significant credit institutions for DORA breaches. For CTPPs, Art. 35 allows the Lead Overseer to impose periodic penalty payments of up to 1% of average daily global turnover. More immediately, supervisors conducting DORA readiness assessments in 2025 are issuing remediation notices — with non-compliance expected to feed into SREP (Supervisory Review and Evaluation Process) capital add-on assessments from 2026.

5. Do we need to re-negotiate all existing ICT contracts before January 2026?

Existing contracts must be brought into compliance at the next contractual opportunity — renewal, extension, or material amendment. For contracts supporting critical or important functions, the EBA’s supervisory guidance (published Q4 2024) recommended completing amendments for critical function contracts by mid-2025. Contracts supporting non-critical functions should be updated by end-2025 or at their next renewal point. There is no blanket requirement to terminate and re-sign existing contracts immediately, but entities should not use this as a reason to delay: supervisors will assess whether entities have a credible remediation plan and timeline for all outstanding contracts.