Published: Last updated:

DORA: operational ICT resilience in the financial sector

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, is the EU legal framework for the digital operational resilience of the financial sector. It requires financial entities to withstand, respond to and recover from disruptions of their information and communication technology (ICT). DORA entered into force on 16 January 2023 and has applied directly since 17 January 2025.

A note on disambiguation: in software delivery, the acronym DORA refers to the DORA metrics from the DevOps Research and Assessment programme. This page is about something else, the EU financial-market regulation of the same name. The two share only the name, not the subject.

DORA addresses a concrete dependency: banks, insurers, investment firms and other financial entities rely on ICT systems and on a limited number of technology providers for their operations. If a central service fails, through a cyberattack or a provider outage, it can disrupt the delivery of financial services and spill over into other sectors. This page describes what the regulation governs, how it is structured, and why it can be relevant to Swiss actors too.

Scope: who is affected

DORA does not address companies in the abstract but a broad list of financial entities. The European Supervisory Authorities (ESAs) count around 21 types of affected entities, from credit institutions and payment service providers through investment firms, insurance and reinsurance undertakings, to trading venues, crypto-asset service providers and crowdfunding providers. Cutting across these, the regulation reaches critical ICT third-party providers, such as large cloud providers whose failure would have systemic effect.

What matters is the function in the financial system, not the industry label. A proportionality principle runs through the regulation: the extent of the concrete requirements depends on the size, risk profile and complexity of the entity. In addition, the regulation provides a simplified ICT risk-management framework or exemptions for certain narrowly defined types of entities; a simplified regime therefore does not apply automatically to every small or microenterprise.

The five pillars

DORA organises operational resilience into five duty areas. They apply together, not as alternatives:

  • ICT risk management. The management body is responsible for a framework that identifies, protects, detects, contains and recovers from ICT risk. This includes business continuity and recovery strategies. This pillar is the organisational foundation; it overlaps in substance with what disaster recovery and incident response describe on the technical side.
  • Handling and reporting ICT-related incidents. Financial entities must detect and classify ICT incidents and report major ones to the competent authority. The concrete classification thresholds and reporting deadlines are set not by the regulation itself but by the downstream technical standards (Level 2).
  • Digital operational resilience testing. A programme of regular basic tests is foreseen. For certain entities selected by significance, advanced threat-led penetration testing (TLPT), which replays real attack scenarios, is added on top.
  • Managing ICT third-party risk. Outsourcing to ICT providers is subject to minimum contractual requirements. Financial entities maintain a register of information on their contractual arrangements with ICT third-party providers.
  • Information sharing. The regulation lets financial entities exchange insights on cyber threats among themselves, voluntarily and within trusted communities.

Cutting across the five pillars is the oversight of critical ICT third-party providers: the three ESAs (EBA, ESMA, EIOPA) act as a joint Lead Overseer exercising pan-European oversight of those providers designated as critical.

How the pillars connect

The five pillars are not separate projects but contributions to one outcome: a financial entity that withstands an ICT incident and keeps operating. Risk management forms the base, the other pillars build on it:

mindmap
  root((DORA))
    ICT risk management
      Management body accountability
      Controls
    Incidents
      Detect
      Classify
      Report
    Resilience testing
      Baseline tests
      TLPT
    Third parties
      Contracts
      Information register
      ESA oversight
    Information sharing
      Share threats

The diagram shows the logic: ICT risk management carries the other pillars, all of them feed operational resilience, and third-party risk additionally connects to the pan-European oversight of critical providers. It is a reading aid, not a substitute for checking the regulation text.

How the regulation is built

DORA is a two-tier body of rules. The regulation itself states the principles; the detail sits in the downstream technical standards (regulatory and implementing technical standards, RTS and ITS) drafted by the ESAs. That is where the operationally decisive parameters are set, such as the format of the register of information, the reporting process for major ICT incidents, and the methodology for the threat-led tests. Implementing DORA therefore means working not only with the regulation text but with this web of standards. This page deliberately names no individual deadlines or thresholds from the standards, because these are subject to ongoing specification and must be checked against the primary text.

Touchpoints with other regulations

DORA does not stand alone. For the organisational side of information security, ISO 27001 provides an established management framework that many of the ICT risk-management requirements can be mirrored against. The horizontal cybersecurity directive NIS2 pursues a similar resilience goal for a broader range of essential and important entities; for the financial sector DORA is treated as the more specific regime (lex specialis) and takes precedence to that extent. Where an affected system processes personal data, data-protection rules apply independently, in Switzerland the revised Data Protection Act (revFADP). The methodical and technical view of auditable evidence is described on the compliance page; the regulatory logic of a risk-based classification is also familiar from the EU AI Act.

When the obligation reaches an organisation

DORA addresses financial entities, yet the obligation reaches an organisation along several paths, even without a direct EU seat. First, through the value chain: an ICT provider supplying financial entities in the EU can effectively fall within the reach of the third-party obligations through its customers' contractual requirements. Second, through group structures: a financial group with EU subsidiaries meets DORA there directly. Third, through national supervision: in Switzerland, supervisory practice sets its own requirements on operational risk management and operational resilience for banks, for instance through FINMA Circular 2023/1 on operational risks and resilience. These follow a similar resilience idea but are legally distinct from DORA and must be checked case by case against the relevant FINMA circulars and FINMA supervisory practice. Whether and how DORA reaches a specific Swiss actor depends on the particular constellation; this page describes only the mechanics, it makes no determination about any specific company.

Proving operational resilience technically requires visibility into one's own operations.

Where implementation breaks

  • Paper instead of operation. A documented ICT risk management that no one lives in daily work satisfies the form, not the purpose. Resilience shows only in the tested emergency.
  • Third parties invisible. Failing to keep the register of information complete overlooks exactly the dependencies whose risk the regulation aims to steer. Embedded subcontractors slip through the net easily.
  • Tests as a checkbox. Resilience tests that replay known scenarios and carry no consequence train nothing. The value lies in the finding that is found and fixed.
  • Standards overlooked. Reading only the regulation text and ignoring the technical standards (RTS and ITS) misses the operationally decisive requirements.

References

Related topics

Ask AI

These links open external AI services, the conversation and its content are sent to their providers.