What is Digital Operational Resilience Act (DORA) compliance?

Introduction

If your organisation sits anywhere inside the EU's financial system, the Digital Operational Resilience Act (DORA) is the regulation that turns cyber resilience from a board-deck aspiration into a set of concrete, supervised obligations. The European Parliament and Council adopted DORA as Regulation (EU) 2022/2554 on 14 Dec. 2022, and it has applied across all 27 member states since 17 Jan. 2025. There’s no transposition layer between you and the text; the regulation lands directly into your operations.

The reason DORA exists is that financial supervisors spent the last decade watching ICT incidents do more damage to systemic stability than most credit shocks. Before DORA, each member state and sectoral regulator handled cyber and operational resilience differently, which left painful gaps around incident reporting timelines, third-party concentration risk, and resilience testing. DORA closes those gaps by giving you one rulebook covering ICT risk management, incident classification and reporting, resilience testing, third-party risk, and information sharing. This is supplemented by a growing family of Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS).

Applicability and scope

DORA applies to a broad range of financial entities operating in or serving the EU. The following categories are in scope under Article 2:

CTPPs become directly supervised by a Lead Overseer under the regulation’s oversight framework. Micro-enterprises receive a lighter, proportionate version of most obligations, but are not exempt.

Compliance levels and requirements

The DORA is structured around five substantive pillars sitting inside nine chapters: ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing. Surrounding them are a scope and definitions chapter, a chapter setting out competent authorities, one delegating power to the Commission to issue RTS, and one handling transitional provisions. The pillars are not optional menu items; they are interlocking obligations the management body is accountable for, and each is fleshed out further by the European Supervisory Authorities (ESAs) through their RTS and ITS.

Chapter I: General provisions

This is the chapter where you confirm whether DORA applies to you and on what terms. It defines the financial entities in scope under Article 2, sets the proportionality principle under Article 4 that lets you scale obligations to your size and risk profile, and lays out the definitions you’ll rely on throughout the rest of the regulation. Read this carefully because the entity categorisation drives almost every downstream obligation, including which RTS apply, which thresholds you measure against, and whether you fall under the simplified regime.

The four building blocks Chapter I gives you before the substantive obligations begin:

• Subject matter (Article 1): One regulation covering ICT risk, incident reporting, resilience testing, third-party risk, and information sharing.
• Scope (Article 2): Roughly 20 categories of financial entity, plus designated critical ICT third-party providers.
• Definitions (Article 3): Harmonised meanings for ICT risk, ICT-related incident, ICT third-party service, TLPT, and CTPP.
• Proportionality (Article 4): Obligations scale with an entity’s size, risk profile, and nature of services.

Chapter II: ICT risk management

This is the chapter where the regulation tells you how to build the ICT risk management framework your management body will personally answer for. Article 5 makes the management body itself responsible for defining, approving, and overseeing the framework, which is a step-change from older guidelines where boards could delegate this comfortably to the CISO. Articles 6 through 16 then walk you through the framework’s content: Identification, protection and prevention, detection, response and recovery, learning, communication, and the simplified regime for smaller entities.

Chapter III: ICT-related incident management, classification, and reporting

This is where DORA puts you on a clock. Chapter III is the heart of incident management; It tells you to build a process that detects, logs, classifies, and reports ICT-related incidents, and it sets the criteria, thresholds, and reporting templates you have to use. Major ICT-related incidents trigger mandatory regulator notifications, with initial, intermediate, and final reports on timelines your runbooks have to be fast enough to meet. Significant cyberthreats can also be reported on a voluntary basis under Article 19.

Chapter IV: Digital operational resilience testing

This is the chapter where the regulation makes you prove your controls actually work. Articles 24 to 27 require every in-scope entity to run a digital operational resilience testing programme proportionate to its size and risk profile, covering vulnerability assessments, scans, source-code reviews, scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing. Significant entities identified by their competent authority then face a second, stricter layer: Threat-led penetration testing (TLPT) every three years, conducted under the TIBER-EU-aligned RTS.

Chapter V: Management of ICT third-party risk

This is the chapter that cannot be delegated to procurement. Chapter V makes clear that any ICT service that is outsourced remains the financial entity’s responsibility, and it sets the contractual, monitoring, and exit-strategy obligations that must be placed around every ICT third-party provider. Articles 28 through 30 cover the principle, the register of information that must be maintained on all ICT third-party arrangements, and the minimum contractual provisions. Articles 31 through 44 then introduce something genuinely new in EU financial regulation: A direct Oversight Framework over critical ICT third-party providers (CTPPs), run by a Lead Overseer (ECB, EBA, ESMA, or EIOPA, depending on sector).

Chapter VI: Information-sharing arrangements

This is the shortest substantive chapter and the only one where the regulation invites rather than orders. Article 45 lets you exchange cyberthreat information and intelligence with other financial entities, including indicators of compromise, tactics, techniques and procedures, cybersecurity alerts, and configuration tools, provided the sharing happens within trusted communities and complies with data protection law. Notification of arrangements to your competent authority is required, but participation itself remains voluntary. The point is collective defence: A threat that hits one of your peers this morning is highly likely to hit you this afternoon.

Chapter VII: Competent authorities

This is the chapter that tells you who is going to ask you difficult questions. Articles 46 through 56 designate the competent authorities for each financial entity category, set out their supervisory powers, and establish the cooperation arrangements between them and the ESAs (EBA, ESMA, EIOPA) plus the European Systemic Risk Board. Penalties and administrative sanctions sit here too. Each member state has to make sure its national regime is sufficiently dissuasive, and the chapter sets out the criteria competent authorities apply when deciding what to fine.

Challenges of implementing DORA

Getting to DORA compliance demands sustained effort across the whole organisation. The regulation requires financial entities to evidence resilience across the full ICT life cycle, on reporting timelines that are often tighter than most firms run today.

• Designing a coherent resilience strategy
  You’ll need a digital operational resilience strategy that holds together across every business unit, every geography, and every critical ICT dependency. That strategy has to reconcile ICT risks against internal goals and external supervisory expectations, and the bar is higher than the older EBA and EIOPA ICT guidelines most teams have been working from. The management body owns it personally under Article 5, which means board education usually has to happen before the documentation does.
• Hitting the incident reporting clock

  Even if your security team already handles incidents well, DORA will push your runbooks. Major incidents have to be classified against tightly defined criteria and reported to your competent authority in initial, intermediate, and final stages on timelines set by the RTS. Your detection, triage, and decision pathways have to compress, and the legal, regulatory, and communications steps that used to happen on a calendar week now happen on a calendar day.

• Expanding your testing programme

  Most financial entities run penetration tests; few run them across the full inventory of ICT systems supporting critical or important functions, and fewer still run TLPT against the TIBER-EU-aligned standard the regulation imports. Building that testing capacity, whether through internal teams or external testers, takes time, money, and competent authority engagement. Also, the three-year TLPT cycle means there’s no quiet year on the schedule.

• Mapping and managing third-party concentration

  Chapter V probably forces the biggest change to how you procure and supervise ICT services. You’ll need a complete register of information covering every ICT third-party arrangement, contractual provisions that meet Article 30’s minimum content, exit strategies you can actually execute, and continuous monitoring rather than once-a-year vendor reviews. If you depend heavily on a small number of providers, the concentration risk surfaces explicitly and you may have to diversify.

• Coordinating across competent authorities and jurisdictions

  If you operate in more than one member state, you’ll deal with more than one competent authority, plus the relevant ESA, plus (for major incidents at a designated CTPP) the Lead Overseer. Keeping those channels aligned, deduplicating reports, and managing inconsistent supervisory expectations during the first years of application is a real operational burden, particularly while the RTS family is still being finalised.

Benefits of implementing DORA

The work of getting to DORA compliance pays off in ways that go beyond the regulatory tickbox, especially because the regulation aligns surprisingly well with what an honest ICT risk programme should already look like.

• Operational resilience you can actually point to
  By the time you’re DORA-compliant, you’ve inventoried your ICT-supported business functions, mapped their third-party dependencies, set recovery objectives the board has approved, and rehearsed your continuity plans against severe-but-plausible scenarios. That’s a meaningful uplift on most pre-2025 baselines, and it makes the kinds of incidents that used to take you down for days into incidents that take hours.
• Harmonised supervision instead of patchwork
  Before DORA, a pan-EU financial group answered to different ICT expectations in every member state. After DORA, you answer to one set of obligations, supplemented by ESA-level RTS and ITS. The harmonisation reduces the compliance overhead for cross-border groups significantly, and it cuts the time your central function spends translating one regulator’s expectations into another’s.
• Genuine third-party accountability
  Chapter V gives you contractual leverage you probably didn’t have before. Audit rights, sub-outsourcing controls, security obligations, exit terms, and the Oversight Framework over CTPPs mean your bigger providers can no longer treat you as a price-taker on resilience terms. The asymmetry that used to favour the largest cloud and ICT vendors flattens out, which is healthy for systemic stability.
• Stronger management body engagement
  DORA’s Article 5 puts the ICT risk framework on the management body’s desk personally. That sounds like a burden, and at first it is, but it ends up being a benefit. ICT investment cases get heard, security budgets stop being the variable cost of last resort, and resilience trade-offs are made at the level of the organisation that actually has the authority to make them.
• Easier conversations with auditors, regulators, and customers
  Once your controls map cleanly to DORA, audits stop being scrambles. Your team can point auditors at the register of information, the incident reporting log, the testing programme reports, and the management body’s framework approval, rather than rebuilding the paper trail every cycle. Customers and counterparties asking about your resilience can be answered with documents that already exist.

Best practices

If you’re aiming for more than minimum compliance, a few practices pay off over the longer run and make the next supervisory cycle much easier.

Governance and framework design

• Get your management body genuinely engaged with the ICT risk framework early; Article 5’s personal accountability is easier to discharge when board members have seen the framework evolve rather than being asked to approve a finished artefact.
• Map your DORA framework to the controls you already run under NIS 2, ISO 27001, the EBA ICT and security risk management guidelines, or the EIOPA equivalent, so you’re not running three parallel programmes.
• Treat the proportionality principle in Article 4 as a design tool, not a loophole; document why each obligation scales the way it does for your entity.
• Refresh your digital operational resilience strategy annually and present material changes to your management body for reapproval.

Incident response and testing

• Rehearse the Article 19 reporting timeline end-to-end at least twice a year, including the legal, communications, and executive sign-off steps, not just the technical response.
• Build your testing programme around the inventory of critical or important functions and tie test scope changes to changes in that inventory, so coverage doesn’t drift over time.
• For TLPT, engage your competent authority early in the scoping conversation; mutual recognition under Article 26 works better when supervisors have been included from the start.
• Run post-incident reviews against Article 13 expectations and feed lessons back into your ICT risk framework on a documented cycle.

Third-party oversight and information sharing

• Treat the register of information as a live operational system, not a once-a-year submission; build it on the systems your procurement and architecture teams already use so it stays accurate.
• Renegotiate contracts with material ICT providers as they come up for renewal to meet Article 30’s minimum content, rather than waiting for a regulator-driven catch-up exercise.
• Build a real, testable exit strategy for every ICT service supporting a critical or important function, including for cloud providers where the migration cost is non-trivial.
• Join a trusted financial-sector information-sharing community under Article 45, notify your competent authority of the arrangement, and feed your own intelligence in rather than just consuming others’.

Going forward

DORA is the regulation that will define what operational resilience means in the EU financial sector for the rest of the decade. For your organisation, the cost of treating it as a documentation exercise is high: weak incident classification means missed reporting deadlines, weak third-party arrangements mean supervisory recommendations you cannot ignore, and weak testing means resilience claims your management body cannot defend in front of a competent authority. The regulation does not give you the option of opting out of any of the five pillars, and the supervisory toolkit (including direct fines, periodic penalty payments, and CTPP oversight) is genuinely teeth-bearing.

The way to approach DORA is as a long-term capability you’re building, not a project you’re closing. The first year of application is about reaching baseline compliance; the second and third are about making the controls actually work under stress, integrating them with your wider security and risk programmes, and using the resilience improvements to strengthen the conversations you have with customers, counterparties, auditors, and the management body. Treated that way, the regulation pays back the investment, and your organisation comes out of the cycle more defensible than it went in.