What is DORA and who is actually covered?
Regulation (EU) 2022/2554, known as DORA (Digital Operational Resilience Act), was adopted on 14 December 2022 and became applicable on 17 January 2025 — with no grace period. Article 2 lists the covered entities: credit institutions, payment institutions, electronic money institutions, investment firms, alternative investment fund managers, management companies, crowdfunding service providers, crypto-asset service providers, and insurance and reinsurance undertakings.
The scope is broader than many anticipate. An online payment platform, an account aggregator or a fintech offering currency exchange services is subject to the regulation on the same basis as a traditional bank. And as soon as a financial entity outsources a function to an ICT provider — a hosting provider, cloud supplier or SaaS vendor — that provider enters the scope of the contractual obligations set out in Article 30.
The five resilience pillars DORA imposes
- ICT risk management (Articles 5 to 16): governance framework, mapping of critical systems, documented business continuity and recovery plans
- Incident management and classification (Articles 17 to 23): detection, notification to competent authorities within precise timeframes, post-incident reports
- Operational resilience testing (Articles 24 to 27): standard penetration testing annually and TLPT (Threat-Led Penetration Testing) every three years for designated entities
- Management of third-party ICT provider risk (Articles 28 to 44): contract register, due diligence, mandatory contractual clauses, oversight of critical providers
- Information sharing (Article 45): voluntary participation in cyber threat intelligence sharing arrangements
Article 28: the ICT contract register as foundation
Article 28(3) of DORA requires each financial entity to maintain and keep up to date a register of all contractual arrangements concluded with third-party ICT providers. This register is not a simple spreadsheet: it must be structured according to the implementing technical standards (ITS) published by the European Supervisory Authorities (EBA, ESMA, EIOPA) and be communicable to competent authorities on request.
In practice, every VPS hosting contract, object storage agreement or content delivery network arrangement must appear with: the provider's name and registered office, a description of the service, the conclusion and expiry dates of the contract, the criticality of the function supported, the location of data and processing centres, and the audit rights stipulated. An update is mandatory at every significant event: new contract, amendment, change of subcontractor, modification of data location.
The register must be maintained at individual, consolidated and sub-consolidated levels — meaning that financial groups must consolidate the contracts of all their covered subsidiaries.
Article 30: the non-negotiable minimum contractual clauses
Article 30 of DORA defines the minimum content of any contract concluded between a financial entity and a third-party ICT provider. These clauses are not recommendations: their absence exposes the financial entity to a regulatory gap identified during an inspection.
Article 30(2) requires for every ICT contract: a precise and complete description of services provided, the locations — countries and data centres — where data is processed and stored, provisions on availability, authenticity, integrity and confidentiality of data, the procedure in the event of an incident and the provider's assistance obligations, termination rights and notice periods, and obligations to cooperate with competent authorities.
Article 30(3) adds, for critical or important functions, additional obligations: full audit rights and access to the provider's premises, the provider's participation in TLPT when the entity is designated, and documented exit strategies with a transition plan to an alternative provider.
Five checks to conduct provider by provider
Qualify the criticality of the hosted function
Before examining the contract, classify the function the provider supports. A transactional database or a payment API is critical. A brochure website with no financial data probably less so. Criticality determines which clauses of Article 30(3) apply — notably enhanced audit rights and TLPT participation.
Verify data location in the contract
Article 30(2)(c) requires that locations — countries and data centres — be explicitly named. A contract that says 'European infrastructure' without specifying countries or sites is not compliant. Require a clause that names the regions and stipulates an obligation to notify in advance of any data relocation.
Check audit and access rights
For critical functions, Article 30(3)(a) imposes full audit rights — including physical access to premises. Verify that your contract does not limit auditing to a self-assessment questionnaire or a shared SOC 2 report. These documents can supplement an audit, not replace it. The clause must stipulate a right of inspection by your internal or external auditors.
Validate the continuity clause and RTO/RPO commitments
DORA requires documented continuity plans for critical functions. Your contract must mention the recovery time objectives (RTO) and recovery point objectives (RPO) guaranteed by the provider, procedures for notification of a major incident, and obligations for periodic testing of these plans. An availability SLA alone is insufficient: it covers nominal availability, not recovery from a disaster.
Document the exit strategy
Article 30(3)(e) makes an exit strategy mandatory for critical functions. It must cover: data portability timelines, export formats, data retention duration after termination, and a transition plan to another provider. Without this clause, you cannot demonstrate to your competent authority that you are managing provider concentration risk.
TLPT: who is concerned and how often?
Threat-Led Penetration Testing (TLPT), provided for by Article 26 of DORA, is an advanced penetration test conducted on production systems in real conditions, drawing on current threat intelligence. It differs from standard penetration tests in its depth and threat-driven methodology.
Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025 and applicable since 8 July 2025, sets the technical standards for TLPT. The frequency is at least once every three years. Not every financial entity covered by DORA must undergo it: competent authorities designate significant entities according to impact, financial stability and ICT risk criteria. The European Supervisory Authorities estimate approximately 100 to 120 significant banks, 40 to 60 insurance groups, and around thirty market infrastructure operators for the first 2025-2028 cycle.
What directly concerns the hosting provider: when a financial entity is designated for TLPT, it can — and often must — involve its ICT providers supplying critical functions. Article 30(3)(b) obliges the provider to cooperate in these tests. If your hosting contract does not include this clause, your financial client is in a regulatory gap.
Standard hosting contract versus DORA-compliant contract
| Clause | Standard contract | DORA-compliant contract (Art. 30) |
|---|---|---|
| Data location | 'European infrastructure' | Countries and data centres named, prior notification obligation in case of relocation |
| Audit rights | Shared SOC 2 report annually | Full audit right by internal/external auditors, access to premises for critical functions |
| Incident management | Notification within 48 hours | Detailed procedure, classification, authority notification timelines, post-incident report |
| Continuity | Monthly availability SLA | Documented RTO/RPO, tested continuity plan, periodic testing obligations |
| Testing participation | Not provided for | TLPT participation clause mandatory for critical functions (Art. 30(3)(b)) |
| Exit strategy | 30-day notice period | Data portability plan, export formats, post-termination retention duration documented |
Data location: why European hosting matters
DORA does not prohibit hosting outside the European Union, but it imposes full traceability and an assessment of geographic concentration risk. For critical functions, Article 28(4) requires evaluating risks linked to concentrating data in a single country or with a single dominant provider.
In practice, competent authorities — the ACPR for French banks and insurers, the AMF for market entities — pay close attention to the location of personal financial data, payment data and market data. Hosting in data centres located in the European Union simplifies the compliance demonstration: the DORA and GDPR combination is easier to document when data does not cross EEA borders.
The EBA's technical standards also specify that the contract register must indicate whether the provider itself relies on subcontractors outside the EU. An opaque subcontracting chain is a vulnerability during an inspection.
Provider concentration risk: avoid relying on a single actor for everything
Article 29 of DORA introduces the concept of ICT concentration risk. A financial entity must assess the risk of entrusting several critical functions to the same provider, or to a small number of providers belonging to the same group. This risk is systemic: if the provider suffers a major incident, several critical functions fall simultaneously.
For a financial actor whose hosting, secure messaging and reporting APIs all rely on the same dominant cloud provider, DORA requires a documented exit strategy and alternatives. This is not an obligation to diversify at all costs, but an obligation to prove that the dependency is known, controlled, and that a continuity plan exists if that provider became unavailable.
This framework favours distributed architectures: autonomous VPS hosting for critical functions, a backup solution at a second provider, and tested failover procedures — rather than total dependence on a single hyperscaler whose standard contractual terms do not match Article 30 requirements.
Prepare the provider file before the inspection
Competent authorities can request to consult the ICT contract register at any time. For each hosting provider, assemble a file containing: the signed contract with Article 30 clauses verified, available compliance certificates or audit reports (ISO 27001, SOC 2, penetration test attestation), documentation of the hosted architecture and function criticality, and the exit procedure with timelines and export formats. This file is not a formality: it is proof that you exercised your due diligence duty as required by Article 28(4).
Sanctions: what DORA provides for non-compliance
DORA does not set a uniform European ceiling for pecuniary sanctions against financial entities. Article 50 of the regulation asks each Member State to confer on its competent authorities the power to impose administrative sanctions and remedial measures, leaving amounts to national law.
In France, the power to sanction belongs to the sanctions committees of the ACPR (for credit institutions, payment institutions and insurers) and the AMF (for market actors). French transposition provisions authorise fines that can reach, according to official sources consulted, up to 10 million euros or 5% of total annual turnover for entities, and up to 5 million euros for responsible natural persons.
Beyond fines, authorities have remedial measures: compliance injunctions, penalty payments, and in the most serious cases, activity restrictions or withdrawal of authorisation. Oversight of critical ICT providers falls under a European level: the DORA Joint Oversight Department, established in 2024 under the aegis of the three European Supervisory Authorities (EBA, ESMA, EIOPA), coordinates direct supervision of providers designated as critical at EU level.
What this concretely changes for choosing a hosting provider
For a financial entity subject to DORA or the agency managing its infrastructure, choosing a hosting provider can no longer be based solely on price or performance criteria. Four operational criteria are added to the specifications.
First, documentability: can the provider supply a precise description of services, the location of data centres, and availability guarantees in a form that can be integrated into the contract register? Second, audit rights: does it contractually accept an audit right by the financial entity's auditors, not just sharing of third-party reports? Third, documented resilience: does it have tested continuity plans, redundant power, duplicated network, and backups whose frequency and retention are contractually stipulated? Fourth, portability: upon termination, within what timeframe and in what format are data returned?
These four criteria are not specific to DORA: they define what serious professional hosting must offer to any organisation hosting sensitive data. DORA makes them mandatory and auditable for financial entities.
DORA and CRA: two complementary regulations, two distinct angles
DORA and the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) are often cited together, but they do not cover the same thing. DORA addresses financial entities and their ICT providers: it governs the operational resilience of a sector. The CRA addresses manufacturers and publishers of products with digital elements: it imposes cybersecurity requirements on products placed on the EU market, regardless of sector.
In practice, a financial entity deploying open source software on its servers is affected by both: by DORA for managing the ICT risk of its hosting provider, and potentially by the CRA if it modifies or distributes software components. For details of CRA obligations applicable to hosting, the article CRA and hosting covers that aspect.
