Financial servicesEurope & UK

DORA

Keep digital resilience work ready for review

Connect ICT risk, resilience testing and third-party oversight to evidence your financial organisation can explain.

Full title
Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (Digital Operational Resilience Act)
Issued by
European Parliament and Council of the European Union, with technical standards developed by the European Supervisory Authorities (EBA, EIOPA, ESMA)
In application
Entered into force 16 January 2023. Applies from 17 January 2025.
Applies to
Twenty types of EU financial entity, and critical ICT third-party service providers designated for EU-level oversight
Nature
An EU regulation, directly applicable, supplemented by binding regulatory and implementing technical standards
Structure
9 chapters and 64 articles. Five pillars: ICT risk management, incidents, testing, third-party risk and information sharing.

Overview

What DORA requires

The Digital Operational Resilience Act sets one set of rules for how EU financial entities manage ICT risk. Before DORA, ICT requirements were spread across sectoral rules and guidelines. DORA brings them into a single regulation that applies directly across banking, payments, insurance, investment and market infrastructure, and it has applied since 17 January 2025. A companion directive, Directive (EU) 2022/2556, amended sectoral directives to align them.

The regulation rests on five pillars. Financial entities must have an ICT risk management framework that the management body approves and is accountable for. They must classify ICT-related incidents and report major ones to their competent authority. They must test their digital operational resilience, and some must carry out threat-led penetration testing. They must manage the risk from ICT third-party service providers, keep a register of all contractual arrangements and include specific terms in contracts. And they may share cyber threat information within trusted communities.

DORA also creates direct EU-level oversight of ICT providers that are critical to the financial sector. The European Supervisory Authorities designate critical ICT third-party service providers and a Lead Overseer supervises each one. The ESAs published the first list of designated providers on 18 November 2025. Financial entities remain fully responsible for the risk of the services they use, whether or not the provider is designated.

The regulation is applied proportionately, according to the size, risk profile and nature of each entity. Much of the detail sits in Level 2 acts: technical standards on the ICT risk management framework, incident classification and reporting, the register of information, contractual policy, subcontracting and threat-led penetration testing. For entities in scope of both, DORA applies in place of the cybersecurity risk management and reporting rules of NIS 2.

Who it applies to

DORA applies to the financial entities listed in Article 2, including:

  • Credit institutions, payment institutions, account information service providers and electronic money institutions
  • Investment firms, crypto-asset service providers and issuers of asset-referenced tokens
  • Central securities depositories, central counterparties, trading venues, trade repositories and data reporting service providers
  • Managers of alternative investment funds and UCITS management companies
  • Insurance and reinsurance undertakings, insurance intermediaries and institutions for occupational retirement provision
  • Credit rating agencies, administrators of critical benchmarks, crowdfunding service providers and securitisation repositories
  • ICT third-party service providers designated as critical, and indirectly every ICT provider that serves EU financial entities through contract terms

Some entities are excluded in Article 2(3), and microenterprises and certain smaller entities apply a simplified ICT risk management framework under Article 16. Indian IT and technology companies supplying EU financial entities are affected through the contractual, register and oversight requirements their customers must meet.

Structure

How the regulation is organised

64 articles in 9 chapters. Chapters II to VI carry the five pillars. Level 2 technical standards supplement each pillar.

Chapter I

General provisions (Articles 1 to 4)

Subject matter, scope and definitions (Articles 1 to 3)
The requirements covered, the twenty categories of financial entity, exclusions, and definitions such as ICT risk, major ICT-related incident and critical or important function.
Proportionality (Article 4)
Requirements are implemented taking into account size, overall risk profile, and the nature, scale and complexity of services and activities.
Chapter II

ICT risk management (Articles 5 to 16)

Governance and organisation (Article 5)
The management body defines, approves, oversees and is responsible for the ICT risk management framework, and its members keep their ICT knowledge current through training.
ICT risk management framework (Article 6)
Strategies, policies, procedures, protocols and tools to protect information and ICT assets, a digital operational resilience strategy, independent control functions and regular internal audit. Reviewed at least yearly and after major incidents.
Systems, identification, protection and detection (Articles 7 to 10)
Resilient ICT systems, identification and classification of functions, assets and dependencies, protection and prevention measures, and prompt detection of anomalous activity.
Response, recovery and backup (Articles 11 and 12)
ICT business continuity policy, response and recovery plans that are tested, and backup policies with restoration and recovery procedures.
Learning and communication (Articles 13 and 14)
Post-incident reviews, threat awareness and training, and crisis communication plans.
Harmonisation and simplified framework (Articles 15 and 16)
Detail set by technical standards, now Delegated Regulation (EU) 2024/1774, and a simplified framework for smaller entities.
Chapter III

ICT-related incidents (Articles 17 to 23)

Incident management process (Article 17)
Detect, manage and notify ICT-related incidents, record all incidents and significant cyber threats, and assign roles.
Classification (Article 18)
Classify incidents using criteria such as clients affected, duration, geographic spread, data losses, criticality of services and economic impact. Thresholds are in Delegated Regulation (EU) 2024/1772.
Reporting (Article 19)
Report major ICT-related incidents to the competent authority through an initial notification, intermediate report and final report, and inform clients where their financial interests are affected. Significant cyber threats may be notified voluntarily.
Templates, centralisation and feedback (Articles 20 to 22)
Standard content and templates, now Delegated Regulation (EU) 2025/301 and Implementing Regulation (EU) 2025/302, the possibility of a single EU hub, and supervisory feedback.
Payment-related incidents (Article 23)
The incident rules also apply to operational or security payment-related incidents at credit, payment, account information and e-money institutions.
Chapter IV

Digital operational resilience testing (Articles 24 to 27)

Testing programme (Article 24)
A risk-based testing programme carried out by independent internal or external testers. ICT systems and applications supporting critical or important functions are tested at least yearly.
Tests of tools and systems (Article 25)
A range of tests, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, scenario-based tests, compatibility and performance testing, end-to-end testing and penetration testing.
Threat-led penetration testing (Article 26)
Entities identified by competent authorities carry out TLPT at least every three years, on live production systems, covering critical or important functions. Detail is in Delegated Regulation (EU) 2025/1190.
Requirements for testers (Article 27)
Suitability, reputation, certification and professional indemnity requirements for TLPT testers, and conditions for using internal testers.
Chapter V

ICT third-party risk (Articles 28 to 44)

General principles (Article 28)
A strategy and policy on ICT third-party risk, a register of information on all contractual arrangements, pre-contract assessment and due diligence, and exit strategies for services supporting critical or important functions.
Concentration risk (Article 29)
Assess concentration risk before contracting, including the risks of subcontracting chains and providers in third countries.
Key contractual provisions (Article 30)
Minimum contract terms for all ICT services, and additional terms for services supporting critical or important functions, such as service levels, notice periods, participation in testing, audit rights and exit arrangements.
Oversight of critical providers (Articles 31 to 44)
Designation of critical ICT third-party service providers, the Oversight Forum and Lead Overseer, oversight powers including inspections and recommendations, periodic penalty payments of up to 1% of average daily worldwide turnover, oversight fees and international cooperation.
Chapters VI to IX

Information sharing, supervision and final provisions (Articles 45 to 64)

Information-sharing arrangements (Article 45)
Financial entities may exchange cyber threat information and intelligence within trusted communities, and notify competent authorities of their participation.
Competent authorities (Articles 46 to 49)
Supervision by sectoral competent authorities, cooperation with NIS 2 structures, and cross-sector exercises and communication.
Penalties and remedial measures (Articles 50 to 56)
Member States lay down administrative penalties and remedial measures, may impose criminal penalties, and publish administrative penalties.
Delegated acts and final provisions (Articles 57 to 64)
Exercise of delegation, review clauses, amendments to sectoral regulations, entry into force and application from 17 January 2025.

Implementation roadmap

How to implement it, step by step

A practical sequence for a financial entity building or maturing its DORA programme.

  1. 1

    Confirm scope and proportionality

    Confirm the entity type under Article 2, whether the simplified framework under Article 16 applies, and which group entities are in scope.

    OutputsScope assessmentProportionality rationale
  2. 2

    Identify critical or important functions

    Map business functions, the ICT assets and providers that support them, and which functions are critical or important.

    OutputsFunction mapICT asset inventory
  3. 3

    Establish the ICT risk management framework

    Approve the framework and the digital operational resilience strategy at management body level, assign control functions and align policies with Delegated Regulation (EU) 2024/1774.

    OutputsApproved frameworkResilience strategyPolicy set
  4. 4

    Set up incident classification and reporting

    Build a process to record all incidents, classify them against the thresholds and meet the reporting deadlines for major incidents.

    OutputsIncident procedureClassification methodReporting templates
  5. 5

    Build the register and remediate contracts

    Record every ICT contractual arrangement in the register of information, assess concentration risk and bring contracts up to the Article 30 terms.

    OutputsRegister of informationContract gap remediation
  6. 6

    Run the testing programme

    Test systems supporting critical or important functions at least yearly, close findings, and prepare for TLPT if the competent authority has identified the entity.

    OutputsTesting programmeTest reportsRemediation tracker
  7. 7

    Test continuity and exit plans

    Test business continuity, response and recovery plans, and document exit strategies for critical or important services.

    OutputsContinuity test resultsExit plans
  8. 8

    Review and report to the management body

    Review the framework at least yearly and after major incidents, audit it internally and report to the management body.

    OutputsAnnual reviewInternal audit report

Audit and evidence guide

What auditors look for, and the evidence to keep

DORA is supervised by each financial entity’s national competent authority, through ongoing supervision, requests for information and on-site inspections. Critical ICT third-party service providers are overseen directly by a Lead Overseer from the ESAs. There is no DORA certificate.

What reviewers look for

  • Management body approval, oversight and training on ICT risk
  • A documented ICT risk management framework, reviewed at least yearly
  • An inventory of functions, ICT assets and dependencies, with critical or important functions identified
  • Incident records showing classification decisions and reporting times
  • A complete and accurate register of information
  • Contracts with the Article 30 terms, and concentration risk assessments
  • Testing programme results and remediation of findings
  • TLPT, where the entity has been identified for it
  • Tested business continuity, response and recovery plans, and exit strategies
  • Independent control functions and internal audit of the framework

Key timelines

Application of DORAFrom 17 January 2025
Initial notification of a major incident4h from class., max 24h
Intermediate report72h after initial notice
Final report1 month after intermediate
Review of ICT risk management frameworkAt least yearly
Testing of systems supporting critical or important functionsAt least yearly
Threat-led penetration testing, where requiredAt least every 3 years
Register of informationKept current; on request

Evidence to keep, by area

Examples to guide your evidence library. Your auditor or regulator decides what is sufficient.

Governance

  • Management body approvals and minutes
  • Digital operational resilience strategy
  • Training records for management body members

ICT risk management

  • ICT risk management framework
  • Function and asset inventory
  • Risk assessments
  • Annual review report

Incidents

  • Incident register
  • Classification records
  • Initial, intermediate and final reports
  • Post-incident reviews

Testing

  • Testing programme
  • Vulnerability and penetration test reports
  • TLPT documentation, where required
  • Remediation tracker

Third parties

  • Register of information
  • Due diligence and concentration risk assessments
  • Contracts with Article 30 terms
  • Exit strategies

Continuity

  • ICT business continuity policy
  • Response and recovery plans
  • Backup and restoration tests

Areas that often need attention

  • A register of information that is incomplete or inconsistent with actual contracts
  • Contracts for critical or important services without the required terms
  • Incident classification that cannot show when the entity became aware and when it classified
  • Management body approval recorded once but no evidence of ongoing oversight
  • Testing that skips some systems supporting critical or important functions
  • Exit strategies that exist on paper but have not been tested for feasibility
  • Subcontracting chains for critical services not identified

How Netra helps

Where each part of the work lives in Netra

Netra loads DORA as requirements, tasks and policies, so each pillar of the regulation is worked through and evidenced on one record.

Framework obligations owned and scheduled

Task Engine

Requirements arrive as tasks with owners and due dates. Recurring tasks cover annual reviews, yearly testing and continuity tests.

Position against each chapter and article

Compliance Centre

Status is derived from completed tasks and evidence. Work done for ISO 27001 or NIS 2 counts here too where the same control applies.

ICT risk management policies

Policy Hub

A policy library generated at onboarding, with a policy score that rises as the work behind each policy is done.

ICT risk assessment and treatment

Risk Manager

A risk register with inherent and residual heatmaps. Risks come down as the linked treating tasks are completed.

ICT third-party providers

Third-Party Risk

Find vendors from what Accounts and Purchase pay, assess them through a vendor portal and record each decision with a rating.

ICT assets supporting critical functions

Asset Management

Assets are linked to the tasks and controls that protect them.

Internal audit and supervisory reviews

Audit Centre

Run internal and regulatory audits end to end, with findings and corrective actions, using evidence held in a tamper-evident vault.

Reporting to the management body

Dashboard & Reports

A live Posture Score and a one-click board report for DORA built from current data.

Netra organises DORA work and evidence. It does not by itself establish compliance, it is not a reporting channel to competent authorities, and it does not produce the register of information in the ESA reporting format or perform TLPT. Netra is not a SIEM or incident detection tool.

Common questions

More questions about Netra

Related frameworks

View all frameworks
Security

NIS 2

Connect cyber-risk responsibilities across your organisation

Security

ISO 27001:2022 (Security Controls)

Make security controls visible through completed work

Financial services

RBI CTRRAF 2026 - Commercial Banks

Connect bank-wide cyber governance with reviewable evidence

See DORA in Netra

See how Netra connects your framework requirements with tasks, evidence and audit follow-up.