DORA, explained for the teams who have to comply.
DORA — Regulation (EU) 2022/2554, the Digital Operational Resilience Act — is the EU's ICT-resilience law for the financial sector. As a regulation it is directly applicable, no national transposition needed, and it has applied since 17 January 2025. It reaches twenty types of financial entities and the ICT providers that serve them.
Who is in scope
Twenty types of financial entities, plus the ICT providers that serve them.
Article 2(1) lists the in-scope entities, points (a) to (t): credit institutions; payment institutions and account information service providers; electronic 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 and management companies; data reporting service providers; insurance and reinsurance undertakings and their intermediaries; institutions for occupational retirement provision; credit rating agencies; administrators of critical benchmarks; crowdfunding service providers; and securitisation repositories. Point (u) adds ICT third-party service providers.
Article 2(3) carves out, among others, occupational pension schemes with 15 or fewer members and insurance intermediaries that are micro, small or medium-sized enterprises. For every financial entity in scope, Article 4 applies the rules proportionately to your size, risk profile, and the nature, scale and complexity of your services — a small payment institution and a systemic bank do not carry identical programmes.
If you are an ICT vendor rather than a financial entity, DORA still reaches you two ways: through the Article 30 clauses your financial-sector customers must put in every contract, and through designation as a critical ICT third-party service provider under Article 31, which brings direct oversight by an ESA Lead Overseer. Designation turns on systemic impact, reliance by systemic institutions, and substitutability — not on provider size.
The five pillars
Five blocks of duties, each anchored in a specific chapter of the regulation.
ICT risk management — Articles 5 to 16
The management body defines, approves and oversees the ICT risk framework, bears the ultimate responsibility for ICT risk, approves the budget, and keeps its own knowledge current through regular training (Article 5). The framework itself is documented, reviewed at least yearly (microenterprises: periodically), audited on a regular basis for all but microenterprises, and carries a digital operational resilience strategy with a defined risk tolerance (Article 6). Article 16 gives a named set of small entities a simplified framework in place of the full Articles 5 to 15.
Incident classification and reporting — Articles 17 to 23
You classify ICT incidents on the Article 18 criteria — clients affected, duration, geographical spread, data losses, criticality of services, economic impact. A major incident triggers Article 19: an initial notification, an intermediate report when the status changes, and a final report after root-cause analysis, on templates and time limits set by the Article 20 technical standards. Clients whose financial interests are hit are informed without undue delay.
Resilience testing — Articles 24 to 27
Every financial entity other than a microenterprise runs a risk-based testing programme and tests all systems supporting critical or important functions at least yearly (Article 24). Entities the authority identifies also run threat-led penetration testing at least every three years, on live production systems, with an external tester at least every third test (Article 26).
ICT third-party risk — Articles 28 to 30
Outsourcing never outsources responsibility: you remain fully answerable for compliance regardless of contract (Article 28(1)). You maintain a register of information over all ICT contracts, report yearly on new arrangements and hand the authority the full register on request, run pre-contract due diligence, and hold exit strategies for critical services (Article 28(3) to (8)). Every contract carries the Article 30 minimum clauses.
Information sharing — Article 45
Financial entities may exchange cyber-threat information and intelligence within trusted communities, on arrangements that protect confidentiality and competition law.
Two enforcement tracks
Financial entities answer to national authorities; critical ICT providers answer to an EU Lead Overseer.
| Financial entity | Critical ICT third-party provider | |
|---|---|---|
| Supervised by | The national competent authority for your licence (bank, insurance, securities supervisor), with powers to inspect, investigate and order remediation (Article 50). | A Lead Overseer — EBA, ESMA or EIOPA — after designation by the ESAs on the Article 31 criteria: systemic impact, reliance by systemic institutions, substitutability. |
| Penalties | Set by Member State law — effective, proportionate and dissuasive; no EU-wide ceiling in the regulation. Authorities can reach members of the management body personally (Article 50(3), (5)). | Periodic penalty payments of up to 1% of average daily worldwide turnover, charged daily for up to six months, published unless disclosure would damage the markets (Article 35(6) to (10)). |
| Third-country rule | You may only keep using a third-country provider designated critical if it establishes an EU subsidiary within 12 months (Article 31(12)). | Designation is published on a yearly ESA list; providers not on it can request designation (Article 31(9), (11)). |
A regulation, and the sector carve-out
Directly applicable since 17 January 2025 — and for financial entities, it displaces NIS2.
Article 64 makes DORA binding in its entirety and directly applicable in all Member States, applying from 17 January 2025. You do not wait for a national implementation the way NIS2 requires — the regulation is the text you are held to, supplemented by the regulatory and implementing technical standards the European Supervisory Authorities drafted for incident reporting, the register of information, TLPT and subcontracting.
For financial entities, DORA is the sector-specific law that NIS2 defers to: where DORA's requirements are at least equivalent, the matching NIS2 provisions do not apply (NIS2 Article 4 — see our NIS2 explainer). A bank builds its programme to DORA. An ICT vendor serving that bank meets DORA through its contracts — and possibly NIS2 in its own right as a digital provider.
From article text to cited gap analysis
Every answer grounded in the regulation, in the AI client your team already uses.
The fastest way to see where you stand: a DORA gap analysis is one of the workflow types on the Free tier — one run a month on a system you describe, reported as a watermarked document with every finding cited to the article. The sample gap analysis shows the deliverable shape end to end.
For the third-party pillar — where most of the contract work lands — the Article 28 working mapping walks the obligations subsection by subsection against ISO 27001 and SCF controls, and the financial-sector page anchors the wider DORA duties. Threat modeling that doubles as compliance evidence — mapping each threat to the measure it satisfies — is covered in this walkthrough.
Questions teams ask about DORA
If your question is not here, email us — every message gets a human answer.
Does DORA apply to my company?
DORA applies to twenty types of financial entities listed in Article 2(1)(a) to (t) — credit institutions, payment institutions, account information service providers, e-money institutions, investment firms, crypto-asset service providers and issuers of asset-referenced tokens, central securities depositories, central counterparties, trading venues, trade repositories, fund managers, data reporting service providers, insurance and reinsurance undertakings and intermediaries, occupational pension institutions, credit rating agencies, critical-benchmark administrators, crowdfunding providers, and securitisation repositories — plus, under point (u), the ICT third-party service providers that serve them. Article 2(3) carves out, among others, small occupational pension schemes (15 or fewer members) and insurance intermediaries that are micro, small or medium-sized enterprises. If you sell ICT services to banks or insurers, DORA reaches you through your customers' contracts even before any designation as critical.
Is DORA a regulation or a directive — do I need to wait for national law?
DORA is a regulation: Article 64 makes it binding in its entirety and directly applicable in every Member State, and it has applied since 17 January 2025. There is no transposition to wait for, unlike NIS2. Member States still play two roles: they lay down the administrative penalties under Article 50, and their competent authorities supervise. The technical detail — incident-report templates and time limits, the register-of-information template, TLPT methodology — sits in regulatory and implementing technical standards the European Supervisory Authorities drafted under the regulation.
What are the five DORA pillars?
The regulation groups its obligations into five blocks: ICT risk management (Articles 5 to 16 — governance, a documented risk-management framework, and a digital operational resilience strategy); ICT incident management, classification and reporting (Articles 17 to 23); digital operational resilience testing (Articles 24 to 27, up to threat-led penetration testing); ICT third-party risk management (Articles 28 to 30, plus the Union oversight framework for critical providers in Articles 31 to 44); and information-sharing arrangements on cyber threats (Article 45).
What are the DORA incident-reporting deadlines?
Article 19(4) sets the structure: an initial notification, an intermediate report when the incident's status changes significantly or on the authority's request, and a final report once the root-cause analysis is complete. The regulation itself does not put hour figures on those steps — Article 19(4) defers the time limits and templates to the technical standards developed under Article 20. Article 19(3) adds a client-facing duty: where a major incident affects clients' financial interests, you inform them without undue delay, together with the measures taken. Significant cyber threats may be notified voluntarily under Article 19(2).
Who has to run threat-led penetration testing (TLPT)?
Not everyone. Every financial entity other than a microenterprise runs a risk-based resilience testing programme, and tests all systems supporting critical or important functions at least yearly (Article 24). On top of that, the competent authority identifies specific entities — weighing sector impact, financial-stability concerns and ICT risk profile — that must run TLPT at least every three years on live production systems (Article 26). Internal testers are allowed, but every third test needs an external one, and significant credit institutions must always use external testers. The RTS follows the TIBER-EU framework.
What must our ICT contracts contain under DORA?
Article 30(2) sets the minimum content of every ICT-service contract — among it: a full description of the services with the conditions for any subcontracting of critical functions, data-processing locations with advance notice of changes, data-protection provisions, access and recovery of data on exit or insolvency, service levels, incident assistance at a pre-agreed cost, cooperation with authorities, termination rights with minimum notice, and conditions for the provider's participation in your security-awareness training. Contracts supporting critical or important functions add Article 30(3): precise quantitative service-level targets, notice duties, contingency-plan testing, participation in your TLPT, unrestricted audit and inspection rights, and a mandatory transition period on exit. Article 28(3) requires you to maintain a register of information covering all ICT contracts, report yearly on new arrangements, and hand over the full register when your authority asks.
What are the DORA fines?
For financial entities, DORA sets no EU-wide fine ceiling. Article 50 leaves administrative penalties to Member State law, requiring them to be effective, proportionate and dissuasive, and lets authorities apply penalties to members of the management body personally. So the exposure depends on where you are supervised. The one figure in the regulation targets critical ICT third-party service providers: a Lead Overseer can impose a periodic penalty payment of up to 1% of average daily worldwide turnover, charged daily for up to six months, to compel compliance (Article 35(6) to (8)).
We already comply with NIS2 — does DORA still apply?
For financial entities, DORA takes priority. NIS2's Article 4 treats DORA as sector-specific Union law: where DORA's requirements are at least equivalent, the matching NIS2 provisions do not apply to those entities. In practice a bank or insurer builds to DORA, not NIS2 — while a fintech that is not one of the Article 2 entity types may still land in NIS2 as a digital provider. The two laws share DNA (risk measures, staged incident reporting, management accountability), but DORA is stricter on testing, third-party contracts and the register of information.
See where you stand on DORA
A free-tier run produces a cited DORA gap analysis of a system you describe — one row per obligation, each anchored to its article. Start there, then bring your own documents on a paid plan.