DORA Compliance for ICT Providers: What EU Financial Clients Will Ask
DORA is the EU regulation on digital operational resilience for the financial sector. Since January 2025 it has required banks, insurers, investment firms, payment and e-money institutions, crypto-asset providers and other financial entities to manage ICT risk, report major ICT incidents, test resilience and manage ICT third-party providers under strict contract rules. Software, cloud and IT service providers to these firms must accept DORA contract terms, and critical providers are overseen directly by EU supervisors.

The DORA regulation (Digital Operational Resilience Act) has applied across the EU financial sector since 17 January 2025. It is aimed at banks, insurers, investment firms, payment and e-money institutions, crypto-asset service providers and many other financial entities, but its effects are felt just as much by their technology suppliers. Every software vendor, SaaS platform, cloud provider and IT service company that supports an EU financial firm is now an "ICT third-party service provider", and DORA tells the financial firm exactly what the contract with that provider must contain.
This guide is written from the supplier's side. It explains what DORA requires of financial entities, what that means for ICT providers (contract terms, incident notification, testing, audit rights and exit plans), how critical ICT providers are designated and overseen, and how to prepare an evidence pack that shortens EU financial sector sales.
What is DORA?
DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. As a regulation it applies directly in all member states. It is accompanied by an amending directive, and by regulatory technical standards (RTS) and implementing technical standards (ITS) developed by the European Supervisory Authorities and adopted by the Commission, which add detail on risk management, incident classification and reporting, the register of information, contract policies, subcontracting and threat-led penetration testing.
DORA is built on five pillars:
- ICT risk management (Articles 5 to 16).
- ICT-related incident management, classification and reporting (Articles 17 to 23).
- Digital operational resilience testing (Articles 24 to 27).
- Management of ICT third-party risk (Articles 28 to 30), and the oversight framework for critical ICT third-party providers (Articles 31 to 44).
- Information-sharing arrangements on cyber threats (Article 45).
History and why DORA was introduced
Before DORA, ICT risk rules for EU financial firms were scattered across sector guidelines, such as the EBA guidelines on ICT and security risk management and on outsourcing, and applied unevenly. At the same time, financial services had become dependent on a small number of cloud and technology providers, cyber attacks on financial firms were increasing, and an outage at one major provider could affect many firms at once. The Commission proposed DORA in 2020 as part of its digital finance package. It entered into force in January 2023 and applied from 17 January 2025, giving firms two years to prepare.
Its purpose is to make sure financial entities can withstand, respond to and recover from ICT disruptions, and to give supervisors visibility of concentration risk in critical ICT providers.
Who is in scope?
Financial entities
Article 2 lists around twenty types, including credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, UCITS management companies, data reporting service providers, insurance and reinsurance undertakings, insurance intermediaries above a size threshold, occupational pension institutions, credit rating agencies, administrators of critical benchmarks, crowdfunding service providers and securitisation repositories. Some smaller entities and microenterprises benefit from a simplified ICT risk management framework (Article 16) and proportionality.
ICT third-party service providers
Any undertaking providing ICT services to financial entities, meaning digital and data services provided through ICT systems on an ongoing basis, including software, hardware support, cloud, data centre, managed services and data analytics. Providers are not directly regulated by DORA unless designated as critical, but they are bound through the contract terms DORA requires and the financial entity's oversight. Location does not matter: providers in India, the US or elsewhere serving EU financial entities are covered by the contractual requirements. For critical providers, DORA requires a subsidiary in the EU in certain cases.
Key requirements for financial entities
ICT risk management
The management body is responsible for ICT risk and must approve and oversee an ICT risk management framework, including strategies, policies, procedures and tools to protect information and ICT assets. Firms must identify and classify ICT assets and functions (including critical or important functions and their dependencies on third parties), protect and prevent, detect anomalies, respond and recover, back up data, learn from incidents and train staff, and maintain business continuity and ICT response and recovery plans that are tested.
Incident management and reporting
Firms must classify ICT-related incidents against criteria in the technical standards (clients affected, duration, geographical spread, data losses, criticality of services, economic impact) and report major ICT-related incidents to their competent authority. Under the technical standards, the initial notification is due within 4 hours of classifying an incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours of the initial notification, and a final report within one month of the latest intermediate report. Significant cyber threats may be notified voluntarily, and clients must be informed of major incidents affecting their financial interests.
Resilience testing
All entities in scope must run a testing programme with a range of tests: vulnerability assessments, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, performance and end-to-end tests, and penetration testing. Significant entities identified by authorities must carry out threat-led penetration testing (TLPT) at least every three years, covering critical functions including those supported by ICT providers, which may need to participate.
ICT third-party risk
Firms must have a strategy and policy on ICT third-party risk, keep a register of information on all ICT service contracts (reported to authorities), assess providers before contracting (including concentration risk and subcontracting chains), and include mandatory contractual provisions. They must have exit strategies for ICT services supporting critical or important functions.
What DORA means for ICT providers: Article 30 contract terms
Article 30 lists the key contractual provisions. For all ICT services, contracts must include:
- A clear and complete description of the functions and services, including whether subcontracting is allowed and on what conditions.
- The locations where services are provided and data processed, and notice of changes.
- Provisions on availability, authenticity, integrity and confidentiality of data, including personal data.
- Access, recovery and return of data in an easily accessible format in case of insolvency, resolution, discontinuation or termination.
- Service level descriptions.
- An obligation to assist the financial entity in ICT incidents related to the service, at no additional cost or at a cost determined in advance.
- An obligation to cooperate fully with the competent authorities and resolution authorities.
- Termination rights and minimum notice periods.
- Conditions for participation in the financial entity's ICT security awareness and training.
For ICT services supporting critical or important functions, contracts must also include, among other things: full service level descriptions with precise quantitative and qualitative performance targets; notice periods and reporting obligations for developments that may materially affect the service; requirements to implement and test business contingency plans and to have appropriate ICT security measures; an obligation to participate and fully cooperate in the financial entity's TLPT; unrestricted rights of access, inspection and audit by the financial entity, appointed third parties and competent authorities; and exit strategies, including a mandatory adequate transition period.
Critical ICT third-party providers
The European Supervisory Authorities designate certain ICT providers as critical based on systemic impact, the number and importance of financial entities relying on them, and substitutability. Critical providers are overseen by a Lead Overseer (one of the ESAs), which can request information, conduct investigations and inspections, issue recommendations, and impose periodic penalty payments of up to 1 percent of the provider's average daily worldwide turnover for up to six months to compel compliance. The ESAs published the first list of designated critical providers in late 2025, consisting mainly of large cloud, data and technology companies. Most software and IT service companies will not be designated, but their large customers will expect them to support oversight-related requests.
How ICT providers can prepare, step by step
- Identify which customers are DORA financial entities and which of your services support their critical or important functions.
- Prepare a DORA contract addendum covering the Article 30 provisions, so negotiations start from your draft.
- Document service locations and data processing locations, and your subcontractors.
- Define service levels with measurable targets and reporting.
- Set up incident notification to customers fast enough for their 4-hour and 24-hour reporting windows, with the information they need to classify incidents.
- Test business continuity and recovery and keep evidence; be ready to share results.
- Prepare for audits and TLPT participation: an audit protocol, pooled audit options, and rules of engagement for testing.
- Build an exit plan: data export in usable formats, transition assistance and timelines.
- Collect assurance evidence: ISO/IEC 27001, SOC 2, ISO 22301, penetration test summaries.
- Provide register of information data: legal entity identifiers, service descriptions, locations and subcontracting chains that customers must report.
Documentation you will need as a provider
- DORA-aligned contract addendum and service descriptions.
- Service level agreements and performance reports.
- List of service and data locations, and subcontractors.
- Information security policies and certifications or attestation reports.
- Business continuity and disaster recovery plans with test results.
- Incident response procedure and customer notification templates.
- Exit and transition plan, and data export documentation.
- Audit and testing cooperation procedure.
Supervision and enforcement
National competent authorities supervise financial entities' compliance and can impose administrative penalties and remedial measures set by national law. The ESAs oversee critical ICT providers. There is no DORA certification; financial entities demonstrate compliance through their frameworks, registers, reports and testing, and they rely on providers' evidence for third-party risk.
Timeline and cost considerations
DORA has applied since January 2025, so financial entities are actively renegotiating contracts and collecting provider information. For providers, the costs are legal work on contract terms, incident notification capability, continuity testing, audit support, exit planning and assurance reports. Providers that standardise a DORA pack avoid repeating this work for each customer.
Benefits and consequences
For providers, being DORA-ready shortens sales cycles with EU financial firms and reduces the risk of being replaced when firms rationalise suppliers. For financial entities, non-compliance can lead to supervisory measures and fines under national law, and to forced changes in outsourcing arrangements. For critical providers, the Lead Overseer can impose periodic penalty payments.
Common mistakes and challenges for IT companies
- Assuming DORA does not apply to non-EU suppliers. Contract requirements apply wherever the provider is based.
- Refusing audit and access rights that DORA makes mandatory for critical or important functions.
- Incident notice clauses measured in days when customers must report within hours.
- No exit plan or data export in usable formats.
- Undisclosed subcontractors, which customers must record and assess.
- Untested continuity plans.
Best practices, tools and technologies
- Publish a DORA readiness statement and contract addendum.
- Automate status and incident notifications to customer contacts.
- Run and document regular restore and failover tests.
- Offer complete data export via API in standard formats.
- Support pooled audits to reduce the burden of many individual audits.
- Keep a live inventory of subcontractors and data locations.
We help clients with the engineering parts: resilient architecture, tested recovery, data export APIs and monitoring, through our SaaS and support services.
How DORA relates to other frameworks
| Framework | Relationship |
|---|---|
| NIS2 | General EU cybersecurity directive; DORA applies as the sector-specific law for financial entities. |
| ISO 22301 | Business continuity standard that helps evidence DORA continuity requirements. |
| ISO/IEC 27001 | Security management system commonly used as provider evidence. |
| SOC 2 | Assurance report many financial customers accept as part of provider due diligence. |
| EU Data Act | Cloud switching and data portability rules that complement DORA exit requirements. |
| Disaster recovery planning | Practical recovery engineering behind DORA's response and recovery duties. |
Real-world implementation examples
Since January 2025, EU banks and insurers have sent suppliers DORA questionnaires and contract addenda, and many large cloud providers have published DORA contract terms and audit programmes for financial customers. Financial entities submitted their first registers of information to authorities in 2025, which required data from every ICT provider.
An illustrative case for an Indian software company supplying a loan origination platform to an EU lender: the lender classifies the service as supporting a critical function. The company signs a DORA addendum with audit rights, commits to notify incidents within one hour of detection with defined content, documents its subcontractors and data centres, demonstrates a failover test, and agrees an exit plan with full data export and a transition period. Its ISO/IEC 27001 and ISO 22301 certificates provide most of the assurance evidence.
Next steps
- List your EU financial customers and the services that support their critical functions.
- Prepare a standard DORA addendum and evidence pack.
- Tighten incident notification, continuity testing and exit capabilities.
- Document subcontractors and locations.
- Get legal advice on contract terms.
Frequently asked questions
When did DORA start to apply?
On 17 January 2025.
Does DORA apply to software vendors?
Not directly, unless designated as a critical ICT third-party provider. Vendors are bound through the contract terms their financial customers must include, and through customers' oversight.
Does DORA apply to non-EU ICT providers?
Yes, through contracts with EU financial entities. Critical providers face direct oversight and may need an EU subsidiary.
What is the DORA register of information?
A register financial entities must keep of all contractual arrangements for ICT services, including provider details, services, functions supported and subcontracting, reported to supervisors.
How fast must major ICT incidents be reported under DORA?
Under the technical standards, an initial notification within 4 hours of classifying an incident as major and no later than 24 hours after awareness, an intermediate report within 72 hours, and a final report within one month.
What is TLPT?
Threat-led penetration testing, an advanced test based on real threat intelligence, required at least every three years for significant financial entities, which may involve their ICT providers.
What is a critical ICT third-party provider?
A provider designated by the European Supervisory Authorities as systemically important to the EU financial sector, subject to direct oversight by a Lead Overseer.
Is there a DORA certification for providers?
No. Providers show readiness through contracts, evidence such as ISO/IEC 27001 or SOC 2, continuity tests and audit cooperation.
How does DORA relate to NIS2?
DORA is the sector-specific law for financial entities; where it applies, its requirements take precedence over the corresponding NIS2 obligations.
What does DORA require in exit plans?
For services supporting critical or important functions, documented exit strategies and contractual transition periods that let the financial entity move to another provider or in-house without disruption.
What penalties apply under DORA?
Member states set administrative penalties for financial entities. Critical ICT providers can face periodic penalty payments of up to 1 percent of average daily worldwide turnover imposed by the Lead Overseer.
Official sources
- Regulation (EU) 2022/2554 (DORA), official text (EUR-Lex)
- Digital operational resilience for the financial sector (European Commission)
- DORA: EBA resources and technical standards (European Banking Authority)
- ESMA: Digital Operational Resilience Act (European Securities and Markets Authority)
- EIOPA: Digital Operational Resilience Act (EIOPA)
Review history
Last reviewed Oct 30, 2026. Next scheduled review Apr 30, 2027, or sooner if the Commission adopts new technical standards, the ESAs publish guidance or update the list of critical ICT providers, or DORA is amended.
- : First published.
This guide explains the official requirements in plain language. It is not legal advice and does not tell you whether your organisation is compliant. Confirm with qualified counsel, your auditor or an accredited certification body.