DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — is the EU's single rulebook for how financial entities manage information and communication technology risk. It applies from 17 January 2025.
The short answer
DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — is the EU's single rulebook for how financial entities manage information and communication technology risk. It **applies from 17 January 2025**.
It replaces a patchwork of sector guidance with one directly applicable regulation covering five areas: ICT risk management, incident management and reporting, resilience testing, third-party risk, and information sharing. It also creates something new in EU financial regulation — a **direct oversight regime for the technology providers themselves**, not only for the financial entities that use them.
Because it is a Regulation rather than a Directive, it applies directly in every Member State without national transposition. There is no local version to look up.
Who is in scope
Article 2 lists around twenty categories of financial entity. Among them: credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, trade repositories, managers of alternative investment funds, management companies, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, and crowdfunding service providers.
**And critically — ICT third-party service providers.** DORA reaches providers in two ways: indirectly, through mandatory contractual requirements imposed on their financial-entity customers; and directly, for those designated as **critical ICT third-party service providers**, who fall under an EU-level oversight framework.
**Proportionality exists but is narrow.** Article 16 provides a simplified ICT risk management framework for certain small and non-interconnected entities. It reduces the framework's formality; it does not exempt anyone from having one.
**If you sell technology to EU financial institutions, DORA reaches your contracts** even if you are not a financial entity and not established in the EU. This is the part most technology vendors discover late, usually through a customer's contract renewal.
The five pillars
**1. ICT risk management — Articles 5 to 15**
The framework sits under the **management body**, which bears final responsibility. It must cover identification of ICT-supported business functions and their supporting assets (Article 8), protection and prevention (Article 9), detection mechanisms (Article 10), response and recovery including a communication policy (Article 11), backup and restoration (Article 12), and learning from incidents (Article 13).
The governance point is not decorative. Article 5 places the framework's approval, oversight and accountability with the management body by name, and requires its members to keep sufficient knowledge up to date.
**2. ICT-related incident management and reporting — Articles 17 to 23**
Entities must define a management process for ICT-related incidents, **classify them against criteria set out in the Regulation and specified further in delegated acts**, and report those meeting the *major* threshold to their competent authority.
Reporting is staged — an initial notification, an intermediate report, and a final report. **The specific windows are set in delegated and implementing acts adopted under the Regulation, not in the Article text.** Read the current acts before writing a runbook, and record the date on which you read them.
Article 19 also provides for voluntary notification of significant cyber threats.
**3. Digital operational resilience testing — Articles 24 to 27**
Every in-scope entity runs a testing programme proportionate to its size and risk profile, covering the range from vulnerability assessments to scenario-based testing.
**A subset goes further.** Entities identified by their competent authority must conduct **threat-led penetration testing** under Article 26 — live testing against production systems, following a threat-intelligence-led methodology, at least every three years. Testers must satisfy requirements set in Article 27.
This pillar has no NIS2 equivalent. It is the clearest example of DORA being more demanding than the general regime.
**4. ICT third-party risk — Articles 28 to 30**
The most operationally heavy pillar for most entities.
For arrangements supporting **critical or important functions**, Article 30(3) adds further mandatory provisions.
Detail: DORA ICT third-party risk and the register of information.
**5. Information sharing — Article 45**
Financial entities may exchange cyber threat information and intelligence among trusted communities. This pillar is **permissive, not mandatory** — it removes legal uncertainty rather than creating an obligation.
- **Article 28** sets general principles and requires a **register of information** on all contractual arrangements for the use of ICT services, maintained at entity, sub-consolidated and consolidated level. It also requires exit strategies.
- **Article 29** requires assessment of **ICT concentration risk** before entering an arrangement — including whether the provider is easily substitutable.
- **Article 30** prescribes the **contractual clauses** that must appear in every ICT services contract: full service descriptions, data processing and storage locations, availability and security requirements, assistance during ICT incidents, cooperation with authorities, termination rights, exit strategies, and rights of access, inspection and audit.
The oversight framework — what makes DORA unusual
Articles 31 to 44 establish something no previous EU financial regulation had: **direct EU oversight of technology providers**.
Providers designated as critical ICT third-party service providers are assigned a **Lead Overseer** from among the European Supervisory Authorities — EBA, ESMA or EIOPA. The Lead Overseer can conduct investigations and inspections, issue recommendations, and — where a provider does not comply — the authorities can ultimately require financial entities to suspend or terminate their use of that provider.
That last power is the one to understand. **The enforcement lever runs through the customer relationship.** A provider that ignores the framework risks its financial-sector customers being instructed to leave.
How DORA interacts with NIS2
Most DORA entities are also nominally NIS2 entities — banking and financial market infrastructures sit in NIS2 Annex I.
**NIS2 Article 4 resolves it.** Where a sector-specific Union act imposes cybersecurity risk-management or incident-notification obligations at least equivalent in effect, that act applies instead. **DORA is that act.** For ICT risk management and ICT incident reporting, DORA displaces NIS2 Articles 21 and 23.
The direction is often stated backwards. It is not that DORA compliance "counts towards" NIS2 — it is that NIS2 stands down in favour of DORA for those subject areas. What NIS2 retains depends on your national transposition.
Full treatment: which instrument governs when DORA and NIS2 both apply.
What to establish first
1. **Confirm you are in Article 2 scope**, and whether Article 16's simplified framework applies to you. 2. **Build the register of information.** It is the longest lead-time artefact and the one supervisors ask for first. 3. **Identify your critical or important functions.** Nearly every other obligation is scoped by this determination. 4. **Read the current delegated acts on incident classification and reporting windows** before designing the runbook. 5. **Minute the management body's approval of the framework.** Article 5 makes this an accountability requirement, not a formality — and the same minute evidences NIS2 Article 20 for any group entity still under NIS2.
Tools available on NexCyber
- Free applicability assessment — confirm DORA scope under Article 2
- Compliance responsibility mapper — RACI by role
- Penalty calculator — exposure by regulation
Further reading
→ DORA × NIS2 — which instrument governs when both apply → DORA ICT third-party risk and the register of information → Threat-led penetration testing under DORA Article 26 → One evidence set across five EU regulations → DORA regulation overview
*This is regulatory information, not legal advice, and nothing here constitutes a compliance guarantee. Incident classification criteria and reporting windows are set in delegated and implementing acts that are amended over time — verify against the current text. Consult your competent authority or a qualified adviser.*
This is an educational explainer. For the canonical regulation reference, see the dedicated DORA page — or run an assessment to see how it applies to your product.