DORA.
The EU regulation on digital operational resilience in finance: scope, main obligations and ongoing evidence.
- Regulation (EU) 2022/2554
- By Derya Altinay
- As of: 10/22/2026
- Reading time: 8 min.
Short answer.
DORA is the EU regulation on digital operational resilience in the financial sector. Since 17 January 2025, it has required financial entities in scope to manage ICT risks, incidents, resilience testing and provider dependencies robustly. Duties depend on role and scope; a general certificate does not replace ongoing compliance.
The DORA regulation governs ongoing operations.
DORA stands for Digital Operational Resilience Act and refers to Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. The regulation has applied since 17 January 2025. Its aim is to enable financial services to continue and recover even during significant ICT disruptions. The European Commission treats prevention, limiting impacts and recovery together as a resilience task.
DORA goes beyond defending against cyberattacks. Technical failures, unusable recovery procedures and dependencies on external services can also impair financial services. How business owners, technology teams and service providers cooperate is therefore decisive. A collection of security policies alone does not show whether a payment process will actually work again after a disruption.
Supplementary regulatory and implementing technical standards detail the regulation. The Commission's official register includes, for example, legal acts on incident reporting and subcontracting. Implementation therefore requires the applicable final rules and requirements of the competent supervisor. An old checklist or general reporting calendar does not replace this examination.
Which financial entities and service providers DORA affects.
DORA covers certain financial-sector legal entities under Article 2 of Regulation (EU) 2022/2554. Examples include credit institutions, payment institutions, investment firms and insurance undertakings, subject to the statutory exceptions. The labels FinTech, start-up or SME do not decide the question. In its final answer DORA 136–3193, EIOPA explains that classification starts with the entity type and shared ICT cannot be excluded solely on the basis of individual activities.
An ordinary ICT third-party service provider has a different role from a financial entity in scope. Financial customers may require contractual commitments, incident support and robust evidence. This is distinct from explicit designation as a critical ICT third-party service provider by the European Supervisory Authorities under Article 31 DORA. Supporting a customer's critical function alone does not result in that designation, as ESMA's information on the oversight framework explains.
Proportionality means a reasoned design of obligations based on the entity and its risks. It is not a general exemption for small businesses. The simplified ICT risk management framework under Article 16 DORA requires separate examination. Record the role, possible exceptions, competent authority and grounds for classification together before determining implementation scope.
DORA requirements connect six work areas.
DORA requirements link management, risk management and verifiable operations. The following overview groups the main areas of the regulation; cyber threat information sharing is voluntary. ESMA describes these topics and points to the respective technical standards for detail.
Management and responsibility.
Under Article 5 DORA, the management body is responsible for ICT risk management. This includes a framework in which decisions, responsibilities and necessary resources align. Engaging external services does not remove the financial entity's responsibility. Management must retain visibility of material risks and outstanding decisions.
ICT risk management and continuity.
Articles 5 to 16 DORA address the ICT risk management framework, including the special rules for the simplified framework. Identification, protection, detection, response, recovery and learning belong together. The reference point is the financial function concerned, with its systems and dependencies. A documented recovery objective needs matching technical and organisational capabilities.
Handle and report incidents.
Articles 17 to 23 DORA govern ICT-related incidents and their reporting. Owners must assess impacts, make the relevant classification and organise the necessary reports. Additional detail comes from the applicable technical standards. A supplier outage must therefore first be assessed substantively, rather than automatically adopting the same reporting status for every regulatory framework.
Test digital operational resilience.
Articles 24 to 27 DORA address resilience testing. Different test types answer different questions: a crisis exercise tests decisions, while a recovery test tests technical assumptions. Threat-led penetration testing, or TLPT, concerns selected financial entities. It is not a blanket requirement for every financial service provider or each of its suppliers.
Manage ICT third-party risks.
Articles 28 to 30 DORA connect provider risks, contractual requirements and the financial entity's own responsibility. The register of information on contractual ICT arrangements is distinct from an ordinary supplier list. Particular attention is needed for support of critical or important functions, dependencies, contractual cooperation and viable exit options. Article 31 onwards addresses separate oversight of critical providers.
Share threat information selectively.
Article 45 DORA enables arrangements for sharing cyber threat information. Participation is voluntary and requires clear confidentiality and use rules. Information sharing supplements internal security operations; it replaces neither incident assessment nor required reporting to the competent authority.
Implementing DORA: from role to verified capability.
Clarify role and responsibilities.
Document scope, exceptions, supervisory relationship and responsible people for the relevant legal entity, so that subsequent work rests on a reasoned classification.
Record financial functions and dependencies.
Connect important functions with the systems, information and external services actually used, to identify possible disruption impacts and shared dependencies.
Assess risks and arrangements.
Work with business, technology and procurement teams to check whether controls, provider commitments and contracts support required continuity and where management decisions are needed.
Practise incident handling and recovery.
Use suitable scenarios to exercise detection, assessment, escalation and recovery, including necessary cooperation with providers, and document the results.
Maintain evidence and track changes.
After significant changes and new findings, review whether responsibilities, registers, procedures and tests still align and identified weaknesses have actually been resolved.
DORA evidence arises from ongoing operations.
DORA compliance is demonstrated through traceable decisions and verifiable implementation. Depending on the applicable duty, this includes risk assessments, continuity arrangements, incident records, test results and ICT agreement documentation. Evidence should show which legal entity and function it concerns and what was actually examined. A test record listing unresolved problems does not confirm that those problems have already been fixed.
Competent authorities supervise financial entities within the statutory framework, including under Article 46 onwards DORA. This differs from European oversight of expressly designated critical ICT third-party service providers under Articles 31 to 44. ESMA describes this oversight as complementary to financial entities' own responsibility and existing supervision. A general DORA certificate with a uniform validity period does not replace these relationships and duties.
DORA and other frameworks.
For financial entities in scope, DORA is a sector-specific Union legal act in relation to NIS2 in the relevant areas; this does not create a blanket exemption of every financial group or its supply chain from all BSIG obligations. ISO 27001 can provide organisational structure for an ISMS, but does not replace DORA requirements and evidence. GDPR duties require separate assessment, particularly when a disruption also affects personal data.
In Secani.
Secani includes an editorial DORA catalogue based on Regulation (EU) 2022/2554 with selected supplementary legal acts. Profile details distinguish, among other things, confirmed financial entities and the full and simplified frameworks. These details support documented work; they do not make an automatic legal classification. The catalogue is neither an official translation nor confirmation of DORA compliance.
Start with one legal entity and one function.
First choose a relevant legal entity and a specific financial function. Assemble its classification, responsibilities, system dependencies, service agreements and latest test results. Then review with the responsible people which statements are already substantiated and what decision is needed next. The detailed blog guide expands on this starting point.
Sources.
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
- European Commission: Cyber resilience
- European Commission: delegated and implementing acts on DORA
- ESMA: DORA, main areas and technical standards
- ESMA: oversight of critical ICT third-party service providers
- EIOPA: DORA Q&A 136–3193 on Article 2
- Commission guidelines on Article 4 NIS2, 2023/C 328/02
Frequently asked questions.
No. The legal entity, its statutory category and possible exceptions under Article 2 DORA are decisive. A market label or small company size alone establishes neither applicability nor exemption.
No. Designation as a critical ICT third-party service provider takes place under the European oversight framework in Article 31 DORA. A customer relationship or support for a customer's critical function alone does not replace that designation.
No. Threat-led penetration testing under Article 26 DORA concerns selected financial entities. Other applicable resilience testing requirements must still be examined separately.
No. An ISO 27001 certificate confirms an ISMS within the stated scope and does not replace statutory DORA duties. The applicable requirements, actual implementation and supporting evidence remain decisive.
Bring responsibility and evidence together.
See how Secani supports work on regulatory requirements.
This page explains DORA in general terms and does not replace a case-specific legal examination. Applicable legal acts and the competent supervisor's requirements take precedence.