DORA Art 28: What It Requires and Who It Applies To

What is DORA Art 28?

DORA Article 28 is a provision of the Digital Operational Resilience Act (Regulation (EU) 2022/2554), a directly applicable EU regulation that sets binding requirements on how financial entities manage the risks arising from their dependence on external ICT service providers. The European Commission published DORA in the Official Journal on December 27, 2022. It became applicable across all EU member states on January 17, 2025.

The regulation came out of a recognition by EU supervisors that the financial sector had quietly become dependent on a very small number of cloud and technology providers. A disruption at any one of them could cascade simultaneously across dozens of banks, payment processors, and insurers with no obvious firebreak. That concentration had built up without a clear regulatory framework requiring institutions to measure it, disclose it, or plan for it.

Article 28 sits within Chapter V of DORA, titled "Managing of ICT Third-Party Risk." It's the structural foundation of obligations running through Article 44. The article establishes the requirement to maintain a register of all ICT third-party providers, conduct pre-contract due diligence, assess concentration risk, and build documented exit strategies for providers supporting critical or important functions.

Art 28 works alongside Article 30, which specifies the minimum contractual content required in ICT third-party arrangements, and the supervisory oversight framework for Critical Third-Party Providers (CTPPs) in Articles 31 to 44. For most institutions, the practical compliance work centres on three deliverables: the register, the risk assessments, and renegotiating legacy contracts to include the mandatory clauses.

Who does DORA Art 28 apply to?

DORA Article 28 applies to all "financial entities" as defined in Article 2 of the regulation. The scope covers the majority of regulated firms operating in the EU financial system.

Covered entities include:

• Credit institutions (retail banks, commercial banks, savings institutions, and EU branches of non-EU banks)
• Payment institutions and e-money institutions
• Investment firms authorised under MiFID II
• Crypto-asset service providers (CASPs) under MiCA
• Insurance and reinsurance undertakings (above Solvency II thresholds)
• Central counterparties (CCPs), central securities depositories (CSDs), and trade repositories
• Credit rating agencies and data reporting service providers
• Alternative investment fund managers (AIFMs) and UCITS management companies
• Crowdfunding service providers
• Pension scheme management bodies

The proportionality principle applies. Microenterprises with fewer than 10 employees and annual turnover below EUR 2 million face a limited subset of Art 28 obligations, mainly around the register and basic contractual requirements. There's no blanket fintech carve-out. A Series B payments startup with 50 employees processing EUR 500 million annually is fully in scope.

From a jurisdictional perspective, Art 28 covers entities established in EU member states. Third-country financial entities operating through EU-based branches are subject to DORA's requirements for those EU operations. Non-EU ICT providers aren't directly regulated by DORA, but EU financial entities must ensure their contracts with those providers comply with Art 28 standards. That effectively extends the regulation's commercial reach well beyond EU borders.

What does DORA Art 28 require?

The core obligations are:

1. Maintain a complete ICT third-party register. Every in-scope financial entity must document all contractual arrangements with ICT third-party service providers. This covers cloud infrastructure, SaaS platforms, managed security services, data analytics vendors, and any third-party API embedded in a product or process. The register must distinguish arrangements supporting critical or important functions from those that don't. The EBA's regulatory technical standards (published January 2024) specify the exact required fields: provider identity, service description, contract dates, criticality classification, and concentration risk indicators.

2. Conduct pre-contract due diligence. Before signing any arrangement covering a critical or important function, the entity must assess the ICT provider's security standards, business continuity arrangements, financial health, and compliance track record. It's not a tick-box exercise. Examiners expect documented evidence of the assessment process, including how scoring was done and whether any concerns required escalation.

3. Assess concentration risk. Entities must evaluate their exposure to individual ICT providers and to groups of interconnected providers. They must also analyse sector-level concentration: the risk that too many market participants depend on the same provider simultaneously. The European Supervisory Authorities have explicitly flagged Amazon Web Services, Microsoft Azure, and Google Cloud as the dominant concentration points in published consultation documents.

4. Implement documented exit strategies. For every provider supporting a critical or important function, there must be a credible plan for switching to an alternative or internalising the function. Exit strategies must address data portability, contractual lock-in clauses, transition timelines, and contingency arrangements if the provider becomes insolvent or loses regulatory authorisation.

5. Enforce minimum contractual content. Article 30 (cross-referenced throughout Art 28) specifies mandatory contract clauses: service descriptions, SLAs, the entity's audit rights, the regulator's audit rights, data security standards, business continuity obligations, and termination rights. Contracts signed before January 17, 2025 must be renegotiated to include these clauses. No grace period exists in the DORA text.

6. Review and update the register and assessments at least annually and after any material change, including incidents at the ICT provider.

What evidence do regulators expect?

Examiners checking Art 28 compliance on an inspection day want documents, not explanations. They will request:

• The complete ICT third-party register in the EBA's standardised format, with a criticality classification for each provider and a clear written rationale for that classification
• Due diligence files for each provider supporting a critical or important function: security certification evidence (ISO 27001, SOC 2 Type II, or equivalent), financial stability assessments, business continuity documentation, and any escalation records where a provider failed the initial scoring threshold
• Contract files for all critical arrangements, with a compliance checklist showing each Art 30 mandatory clause is present and referencing where in the contract it appears
• Concentration risk analysis: entity-level analysis of your firm's dependency on individual providers, and sector-level awareness of dependencies shared across the market
• Exit strategy documents for every critical provider, including version history confirming regular review and a test record or gap analysis demonstrating the strategy is executable
• Board or senior management approval records for decisions to use a provider for critical functions, including any formal residual risk acceptances
• Incident logs tracking disruptions or performance failures by ICT third parties, and the documented internal response
• Annual review records confirming the register and assessments were updated on schedule

Regulators expect the register to be current. A register last updated 18 months ago, or one that includes providers the entity no longer uses, signals a governance failure before any substantive review has begun.

Common failure modes

Most Art 28 findings in supervisory reviews fall into a small set of patterns.

• Incomplete register. Firms capture tier-one providers (cloud infrastructure, core banking vendors) but miss SaaS tools adopted by individual business lines, third-party APIs embedded in customer-facing products, and data analytics vendors processing sensitive data. The EBA has consistently noted inconsistent scoping as the leading gap in ICT third-party registers across its annual ICT risk assessments (EBA Risk Assessment Reports: https://www.eba.europa.eu/risk-analysis-and-data/risk-assessment-reports).

• Criticality classification set too low. Some entities classify everything as non-critical to reduce compliance burden. Examiners scrutinise this. When a provider's failure would directly interrupt customer services or regulatory reporting, it qualifies as critical. Mis-classification forces a full reassessment and typically generates a formal finding.

• Exit strategies that read like aspirations. "We would migrate to an alternative provider within six months" is not an exit strategy. Supervisors want data portability tested, transition timelines validated against real migration estimates, and contract terms reviewed for lock-in clauses. The UK FCA demonstrated a similar standard in its 2022 action against TSB Bank, fining the bank £48.65 million for ICT outsourcing and migration failures, explicitly citing the absence of credible fallback plans (FCA Final Notice: https://www.fca.org.uk/news/press-releases/fca-fines-tsb-bank-its-it-migration-failures).

• Legacy contracts missing mandatory clauses. Many ICT contracts signed before DORA don't include audit rights for the entity or its regulators. Art 28 requires them. Firms that haven't renegotiated are in breach from January 17, 2025, regardless of how compliant everything else is.

• Concentration risk documented but unaddressed. Entities may record concentration in their register and accept it without board-level consideration or a mitigation plan. Supervisors expect evidence of escalation, formal risk acceptance, and at minimum a plan to reduce material concentration over a defined timeline.

Penalties for non-compliance

DORA doesn't establish a single EU-wide fine schedule. Enforcement runs through national competent authorities (NCAs): the ECB for significant institutions under the Single Supervisory Mechanism, national banking supervisors for less significant institutions, and sector-specific regulators for payment institutions, investment firms, and insurers.

Under DORA Article 50, NCAs can impose:

• Public statements naming the financial entity and the nature of the breach
• Orders to cease non-compliant conduct
• Administrative pecuniary penalties of up to EUR 5,000,000 for legal entities, or 1% of total annual worldwide net turnover (whichever is higher). For natural persons with direct decision-making responsibility, the cap is EUR 1,000,000.

That's a substantial ongoing exposure for large cloud providers with EU financial sector customers.

For Critical Third-Party Providers under direct ESA oversight, the Lead Overseer (EBA, ESMA, or EIOPA, depending on sector) can impose periodic penalty payments of up to 1% of average daily worldwide turnover per day for non-compliance periods of up to six months.

Member states may introduce criminal liability via national implementing legislation for intentional or grossly negligent breaches.

The ECB incorporated DORA readiness as a scored element in its 2024-2026 supervisory priorities (ECB Banking Supervision Supervisory Priorities: https://www.bankingsupervision.europa.eu/banking/priorities/html/ssm.supervisory_priorities2024~8b1aa2c449.en.html). Several significant institutions received formal remediation requirements in their 2024 SREP outcome letters, with deadlines for completing ICT third-party register remediation. Non-completion risks supervisory escalation, potentially including capital add-ons.

Related regulations and frameworks

DORA Art 28 sits within a wider regulatory stack, and firms operating across jurisdictions will find direct counterparts elsewhere.

The DORA regulation as a whole provides the overarching framework; Art 28 is one of its most operationally intensive articles. Within the EU regulatory perimeter, GDPR intersects wherever ICT third parties process personal data. GDPR's processor agreement requirements (Articles 28 and 29 of GDPR) must now align with DORA Art 28 contractual standards. When a cloud provider processes both personal data and supports critical functions, the single contract must satisfy both regulatory frameworks simultaneously.

PSD2 and its successor PSD3 impose security and outsourcing requirements on payment institutions that overlap significantly with Art 28. Firms already compliant with PSD2's outsourcing regime need to upgrade to meet DORA's more granular standards, particularly around exit strategies and audit rights.

At the international level, the US Federal Reserve's SR 23-4 guidance on third-party risk management covers broadly similar ground. Firms with both EU and US regulatory exposure should align their frameworks to the stricter standard, which in most areas will be DORA.

The Basel Committee's BCBS 323 operational risk framework requires banks globally to account for ICT and third-party risk in their capital calculations. Art 28 documentation feeds directly into the BCBS 323 evidence base (BIS, "Principles for Operational Resilience," August 2021: https://www.bis.org/bcbs/publ/d516.htm).

The EU AI Act adds a further layer for entities using AI-powered ICT services. A third-party AI system supporting credit decisions, fraud detection, or compliance functions may qualify as high-risk under Article 6, triggering conformity assessment requirements on top of DORA's contractual standards.

EBA's Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) preceded DORA and remain a useful interpretive baseline. They don't replace DORA obligations but help clarify how "critical or important function" has historically been interpreted by EU supervisors.

How FluxForce supports DORA Art 28 compliance

FluxForce's AI agents maintain continuous, auditable records of ICT provider assessments, flag changes in concentration risk, and generate evidence packages in the EBA's standardised register format. Nova Sentinel monitors third-party security posture around the clock. The regulatory compliance automation platform maps each contractual requirement to the evidence on file, identifies gaps, and queues them for remediation before an examiner finds them. Every decision produces a full audit trail that regulators can review on request. Book a demo to see how it works.