DORA has applied to financial entities in the EU since January 2025, and if you host, operate or develop anything for a bank, insurer or payment institution, it has already arrived in your contracts. The regulation binds financial entities directly, but it works through them into every ICT supplier they use. This guide explains what DORA is, which obligations reach providers, and where the binding answers actually come from.
What is the DORA Regulation?
The Digital Operational Resilience Act (DORA) is Regulation (EU) 2022/2554, a directly applicable EU regulation that requires financial entities to manage ICT risk, report major ICT-related incidents, test their digital resilience and control their dependencies on ICT third-party service providers.
Because DORA is a regulation and not a directive, it applies in every member state without national transposition. It entered into force on 16 January 2023 and its requirements apply from 17 January 2025. An accompanying directive, Directive (EU) 2022/2556, amended a set of existing sectoral directives to fit DORA into the wider financial-services framework. Member states still designate the competent authorities and set out their own administrative sanctions regime, which is why enforcement practice differs from country to country.
Much of the operational detail does not sit in the regulation itself but in technical standards — regulatory and implementing technical standards drafted by the three European Supervisory Authorities (EBA, EIOPA and ESMA) and adopted by the European Commission as delegated and implementing regulations. That layer kept moving through 2024 and 2025, including a revision round on the standard covering subcontracting. Anyone drawing conclusions from a summary written a year ago should check the current status on the ESAs' pages.
Who does DORA apply to?
DORA applies to a broad list of EU financial entities — among them credit institutions, payment and e-money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, trading venues, fund managers and central securities depositories — and, through them, to the ICT third-party service providers that serve those entities.
The scope list in the regulation is explicit and long, and it contains carve-outs and proportionality rules: certain small and non-interconnected entities may use a simplified ICT risk management framework, and microenterprises face lighter obligations in several places. Whether a given firm falls into one of those categories is a question for the regulation text and the national competent authority, not for a summary. This page describes criteria; it does not tell you whether you are in scope.
For providers the relevant question is different and much simpler: it is not whether you are a financial entity, but whether your customers are.
Does DORA apply to IT providers directly?
DORA does not impose direct legal obligations on most ICT providers; it reaches them through the contracts their financial-sector customers are required to conclude. The one exception is providers that the European Supervisory Authorities designate as critical ICT third-party service providers, which come under direct EU oversight.
graph TD
A["Do you provide ICT services to an EU financial entity?"] -->|No| B["DORA does not reach you contractually"]
A -->|Yes| C["Do those services support a critical or important function?"]
C -->|No| D["Baseline contractual requirements apply, passed down by your customer"]
C -->|Yes| E["Enhanced requirements: audit rights, exit strategy, quantified service levels"]
E --> F["Have the ESAs designated you as a critical ICT third-party provider?"]
F -->|No| G["Obligations stay contractual and commercial"]
F -->|Yes| H["Direct EU oversight by a Lead Overseer applies"]
The definition of "ICT services" in the regulation is deliberately wide and covers digital and data services provided on an ongoing basis. Hosting, managed infrastructure, SaaS, operations and support all fall inside it comfortably. Read the definitions article before assuming a service is too small or too peripheral to count.
What does DORA actually require?
DORA is usually described in five pillars. The table below groups the substance and names where each pillar touches a provider rather than only the financial entity.
| Pillar | Substance | Effect on a provider |
|---|---|---|
| ICT risk management | Governance, an ICT risk framework, board responsibility, protection and recovery | Your controls become evidence in your customer's framework |
| Incident management | Classification, internal handling and reporting of major ICT-related incidents | Contractual notification duties and timelines pushed down to you |
| Resilience testing | A testing programme; threat-led penetration testing for selected entities | Obligation to cooperate in, and sometimes participate in, testing |
| ICT third-party risk | Register of information, pre-contractual assessment, mandatory contract terms, exit strategies | The bulk of what you will be asked for |
| Information sharing | Voluntary exchange of cyber threat intelligence | Little direct effect |
Two elements deserve extra attention because they generate most of the day-to-day work. The first is the register of information: financial entities must maintain a structured register of all contractual arrangements for ICT services and report it to their competent authority. The implementing standard prescribes the fields, which is why suppliers are suddenly asked for a Legal Entity Identifier, precise data-processing locations and a description of their subcontracting chain. If you cannot supply those, your customer cannot complete its register.
The second is incident reporting. The adopted technical standards set staged deadlines — an initial notification shortly after an incident is classified as major, an intermediate report, and a final report — and financial entities pass equivalent or tighter notice periods into their supplier contracts. The exact hour figures are defined in the relevant regulatory and implementing technical standards and have been amended during the rollout; take them from the current published text rather than from a blog post.
What must an ICT contract contain under DORA?
DORA prescribes a minimum content for every contract on the use of ICT services, and a stricter set on top of it where the service supports a critical or important function of the financial entity. The distinction between those two tiers is the single most important thing for a provider to understand, because it decides how much scrutiny the relationship attracts.
| Requirement | Any ICT service | Critical or important function |
|---|---|---|
| Clear description of services and functions | Yes | Yes |
| Locations of service provision and data processing | Yes | Yes, with change notification |
| Data availability, integrity, confidentiality provisions | Yes | Yes |
| Access to and return of data on termination | Yes | Yes |
| Service level descriptions | Yes | With quantitative performance targets |
| Assistance during ICT incidents | Yes | Yes |
| Termination rights and notice periods | Yes | Yes, plus transition support |
| Rights of access, inspection and audit | Limited | Unrestricted, including for the authority |
| Documented exit strategy | Not required | Required |
| Cooperation in threat-led penetration testing | Not required | Where applicable |
Whether a function is "critical or important" is the financial entity's determination, not yours. In practice you will find out through the contract draft you receive. A provider that already documents data locations, subcontractors, service levels and recovery objectives can answer such a draft in days; a provider that has never written them down will spend months on it.
DORA also allows financial entities to make use of third-party certifications and independent audit reports when assessing suppliers, but not to rely on them indefinitely or as a complete substitute where critical or important functions are concerned. Certifications shorten the assessment; they do not end it.
Matching infrastructure at centron
Security by default: cloud firewalls filter traffic before it reaches the instance, managed centrally. Explore cloud firewalls →
What is a critical ICT third-party service provider?
A critical ICT third-party service provider (CTPP) is a provider formally designated by the European Supervisory Authorities on the basis of criteria set out in DORA — essentially the systemic impact of an outage, the number and importance of the financial entities served, and how substitutable the service is.
Designation changes the legal position fundamentally. A designated provider is supervised directly at EU level by a Lead Overseer — EBA, EIOPA or ESMA, depending on the sector concerned. The Lead Overseer can request information, conduct investigations and on-site inspections and issue recommendations. Where a designated provider does not address them, the framework allows supervisors to require financial entities to suspend or terminate their use of the service, which is the sharpest instrument in the whole regulation. DORA also provides for periodic penalty payments calculated as a share of the provider's average daily worldwide turnover, applied daily up to a capped period; the percentage and the cap are stated in the regulation and should be read there. Designated providers additionally bear oversight fees.
The ESAs began publishing designations in 2025. The authoritative list is the one the ESAs maintain — a provider is a CTPP only if it appears there, and no amount of marketing language makes a provider one or exempts it from being one.
What are the deadlines, and what happens if DORA is ignored?
| Date | What happened or applies |
|---|---|
| 16 January 2023 | Regulation (EU) 2022/2554 entered into force |
| 17 January 2025 | Requirements apply; no general transition period follows |
| During 2025 | First registers of information collected; first CTPP designations published |
| Ongoing | Technical standards adopted, amended and supplemented |
There is no grace period still running for the core obligations. For financial entities, non-compliance is a supervisory matter: competent authorities can order remediation and impose administrative measures and penalties, the detail of which is largely left to national law and therefore varies by member state. Consult the national competent authority — in Germany, BaFin — for the applicable regime.
For a provider that is not designated as critical, the consequence is commercial rather than administrative, and it is not mild. A supplier that cannot supply register data, will not grant audit rights, or refuses the mandatory contract clauses simply cannot be used for the function in question. Vendor assessments in the financial sector have become a filter, and DORA gave that filter a legal basis.
How does DORA relate to NIS2, ISO 27001 and BSI C5?
DORA is sector-specific EU law for finance and takes precedence over NIS2 for entities and requirements within its scope, while ISO/IEC 27001 and the BSI C5 are voluntary schemes that can supply evidence for a DORA assessment but do not by themselves establish compliance with it.
| Framework | Legal status | Primary object | Role in a DORA context |
|---|---|---|---|
| DORA | Binding EU regulation | Operational resilience of financial entities and their ICT supply chain | The obligation itself |
| NIS2 | EU directive, transposed nationally | Cybersecurity across many sectors | Yields to DORA where DORA's requirements apply |
| ISO/IEC 27001:2022 | Voluntary certification | Information security management system | Evidence of governance and controls |
| BSI C5:2020 | Voluntary audit criteria, ISAE 3000 attestation | Security of a specific cloud service | Evidence with transparency data on locations and jurisdiction |
The relationship is complementary, not equivalent. An ISO/IEC 27001 certificate shows that a management system exists and is audited; a BSI C5 attestation describes tested controls for a named service over a stated period, including transparency information a DORA register benefits from. Neither answers questions DORA asks about exit strategies, subcontracting chains or contractual audit rights. centron holds a BSI C5:2020 Type 1 attestation (unrestricted) for ccloud³ / Managed Cloud, as well as ISO/IEC 27001, ISO 9001 and ISO 14001 certifications — useful inputs to a customer's supplier assessment, and no substitute for it.
Where do the binding answers come from?
The binding text is Regulation (EU) 2022/2554 as published on EUR-Lex, together with the delegated and implementing regulations that carry the technical standards. Interpretation and current status come from the European Supervisory Authorities through their Joint Committee, and from the national competent authority — BaFin for Germany — which publishes its supervisory expectations.
This guide describes criteria so you can apply them to your own situation. It is not legal advice, and it cannot tell you whether a specific entity, service or contract falls in or out of scope; that assessment belongs to your legal and compliance function.
If you are preparing a supplier assessment and need the underlying evidence, the attestations and certificates centron provides are available in the Trust Center documentation.
More on compliance
- BSI C5 Explained: Attestation, Type 1 and Type 2
- The CLOUD Act and Its Impact on European Companies
- ISO 27001: Requirements, Process and Effort
- NIS2: Who Is Affected and What Must Be Done?
Testen Sie Ihr Setup auf ccloud³
Registrieren Sie sich in der ccloud³ und erhalten Sie 200 € Startguthaben für Ihr Projekt – z. B. für eine PostgreSQL-VM mit automatischen Backups.