January 17, 2025 was the deadline. After a two-year implementation window, the Digital Operational Resilience Act — DORA — became fully applicable across the EU financial sector. Eighteen months on, enforcement is no longer theoretical. Supervisory bodies have issued findings, remediation demands, and in some cases, sanctions. If your organization touches EU financial services and you still don't have a clear picture of what DORA requires, that's a critical gap.
This guide cuts through the noise. It covers the full DORA regulation summary, who oversees it, how the regulatory technical standards actually work, what the UK position looks like post-Brexit, and how organizations are operationalizing compliance in 2026.
What Is DORA? A Regulation Summary That Actually Makes Sense
The Digital Operational Resilience Act (Regulation EU 2022/2554) is a horizontal EU regulation targeting ICT risk management across financial entities. Before DORA, financial sector entities were subject to fragmented national guidance on operational resilience — a patchwork that left significant gaps in how institutions managed ICT risk, third-party dependencies, and incident reporting. DORA harmonizes all of that into one binding framework.
The five core pillars of DORA are:
- ICT Risk Management — A formal ICT risk management framework must exist, covering identification, protection, detection, response, and recovery. This maps closely to NIST CSF 2.0's core functions, though DORA adds financial-sector specificity.
- ICT-Related Incident Management and Reporting — Entities must classify, manage, and report significant ICT incidents to competent authorities using standardized templates and timelines.
- Digital Operational Resilience Testing — Basic testing for most entities, with Threat-Led Penetration Testing (TLPT) — modeled on TIBER-EU — required for systemic institutions.
- ICT Third-Party Risk Management — Contractual requirements, concentration risk analysis, and exit strategy obligations for all critical ICT third-party providers (CTPPs).
- Information and Intelligence Sharing — Voluntary frameworks for sharing cyber threat information between financial entities.
DORA applies to roughly 22,000 financial entities across the EU — banks, insurance companies, investment firms, crypto-asset service providers, payment institutions, and more. Critically, it also applies to ICT third-party service providers who support those entities, including cloud providers, data analytics platforms, and software vendors.
What Institution Oversees DORA?
This is the question most practitioners get wrong. DORA doesn't create a single new supervisory authority. Instead, oversight operates on two levels.
At the national level, competent authorities — the same bodies that supervise financial institutions for prudential purposes — oversee DORA compliance. In Germany, that's BaFin. In France, the ACPR. In Ireland, the Central Bank of Ireland. These authorities conduct supervisory reviews, request documentation, and can impose sanctions for non-compliance.
At the EU level, the three European Supervisory Authorities (ESAs) — the European Banking Authority (EBA), the European Insurance and Occupational Pensions Authority (EIOPA), and the European Securities and Markets Authority (ESMA) — share joint oversight responsibilities. They jointly developed the DORA Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS), and they continue to issue guidance and Q&As as the framework matures.
There's also a specific oversight regime for Critical ICT Third-Party Providers (CTPPs). The ESAs designate which third-party providers qualify as critical — based on systemic importance, substitutability, and interdependence — and the lead overseer (one of the three ESAs, depending on the financial sector) conducts direct supervisory engagement with those CTPPs. This is a significant shift: cloud providers like AWS, Azure, and Google Cloud are now directly subject to EU financial supervisory scrutiny.
DORA Regulatory Technical Standards: What's Actually In Them
The DORA Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) are where the abstract regulation becomes operational reality. The ESAs published multiple batches of standards; understanding their content is non-negotiable for compliance teams.
RTS on ICT Risk Management
This standard specifies the detailed requirements for the ICT risk management framework. It requires entities to maintain an up-to-date information asset register — essentially a Cloud Inventory equivalent for all ICT assets — classify assets by criticality, and document interdependencies between business functions and ICT systems. Threat identification must be continuous and structured around a recognized threat taxonomy. Think MITRE ATT&CK as the reference frame for financial sector threat actors.
RTS on Incident Classification
One of the most operationally complex standards. Entities must classify ICT-related incidents and cyber threats against five criteria: number of clients affected, duration, geographic spread, data losses, and economic impact. The classification triggers different reporting timelines: an initial notification within four hours for major incidents, an intermediate report within 72 hours, and a final report within one month. Getting this wrong means late reports to regulators — which carries its own supervisory risk.
RTS on TLPT
Threat-Led Penetration Testing under DORA is not a standard pen test. TLPT follows the TIBER-EU methodology — intelligence-driven red team exercises targeting an institution's live production environment. The RTS specifies who can conduct TLPT (accredited testers only), how scope is defined, and how results must be reported. For most organizations without mature red team programs, this is a significant uplift. TLPT is mandatory only for entities classified as significant by their national competent authority, but others may voluntarily opt in.
RTS on ICT Third-Party Risk
Contract templates, mandatory clauses, and concentration risk frameworks. The standard requires entities to maintain a register of all ICT third-party arrangements and identify which ones support critical or important functions. For those that do, enhanced contractual provisions apply — audit rights, security requirements, business continuity obligations, and termination rights. The practical challenge here is vendor negotiation: hyperscalers don't typically accept bespoke contract terms, which is why the ESAs have engaged directly with major cloud providers.
DORA and the UK: What's the Position Post-Brexit?
Short answer: DORA does not apply in the UK. The UK left the EU before DORA's final publication, so it was never transposed into UK law. UK-authorized financial firms are not required to comply with DORA unless they also operate within the EU or provide services to EU-regulated entities that are themselves subject to DORA's third-party requirements.
The UK's equivalent framework is the Operational Resilience Policy developed by the Bank of England, the Prudential Regulation Authority (PRA), and the Financial Conduct Authority (FCA). UK firms must identify important business services, set impact tolerances, and demonstrate they can remain within those tolerances under severe but plausible scenarios — a conceptually similar outcome to DORA, but with different mechanics and no equivalent to the CTPP oversight regime.
UK firms in scope of both regimes — typically large international banks with EU branches or subsidiaries — face dual compliance obligations. The good news: there's significant conceptual overlap. The bad news: the operational specifics diverge enough that a single compliance program won't satisfy both without deliberate design.
Operationalizing DORA: Where Most Firms Are Struggling in 2026
Post-deadline enforcement has surfaced predictable pain points. Here's where organizations are consistently falling short:
Third-Party Risk Registers Are Incomplete
DORA requires a register of all ICT third-party arrangements — not just the big cloud providers. Shadow IT, legacy vendor relationships, and departmental SaaS tools routinely escape the scope of initial registers. Without comprehensive Cloud Inventory coverage and continuous asset discovery, organizations are filing incomplete registers with their competent authorities. That's an enforcement risk.
Incident Classification Gets Miscalibrated
The five classification criteria interact in complex ways. A ransomware incident that affects 200 internal users but doesn't touch customer data might not meet the threshold for major incident reporting under one reading — but duration and economic impact criteria might push it over. Organizations without clear internal playbooks that map incident characteristics to DORA classification thresholds are making ad-hoc decisions under pressure. That's how late reports happen.
ICT Risk Framework Lacks Technical Depth
Regulators aren't satisfied with policy documents that describe a risk framework in the abstract. They want evidence: vulnerability scan outputs, threat detection logs, patch management records, configuration baselines. Tools like VM Scans and CSPM aren't just useful for security — they generate the audit evidence that supervisors expect to see when they review an ICT risk framework under DORA.
TLPT Readiness Is Underestimated
Organizations that have never run a TIBER-style exercise consistently underestimate the preparation required. You need an intelligence phase (typically 6-8 weeks), a testing phase (8-12 weeks), and a remediation and closure report. The lead time from engagement to final report is routinely 6+ months. Organizations that haven't started scoping TLPT engagements yet are already behind the curve for the next supervisory cycle.
DORA and the Broader Compliance Ecosystem
DORA doesn't exist in isolation. It explicitly references and intersects with several other frameworks and regulations that financial entities must already navigate.
NIS2: Financial entities subject to DORA are carved out of NIS2 for the sectors where DORA applies — DORA is considered lex specialis. But the overlap in technical requirements (incident reporting, supply chain risk) means a well-designed DORA program provides significant NIS2 coverage as a byproduct. Our Blog covers NIS2 in detail for non-financial sectors.
GDPR: ICT incidents under DORA frequently involve personal data, triggering parallel GDPR notification obligations (72 hours to the supervisory authority under Article 33). Organizations need incident response workflows that feed both DORA's incident reporting pipeline and GDPR's data breach notification process simultaneously.
EBA Guidelines on Outsourcing: The EBA outsourcing guidelines that predated DORA remain relevant for aspects not fully superseded, particularly around governance of outsourced arrangements. DORA's third-party risk RTS builds on — rather than replaces — that prior guidance.
The practical implication is that DORA compliance can't live in a silo. It needs to be integrated into a broader Compliance program that maps controls across overlapping frameworks, avoids duplication of effort, and surfaces conflicts before they create audit findings.
Technical Controls That Map Directly to DORA Requirements
Abstract compliance language needs to translate into operational controls. Here's a practical mapping of key DORA requirements to concrete technical capabilities:
The ICT risk management framework requires continuous asset visibility and classification. That means automated discovery of cloud resources, containers, and endpoints — the kind of coverage provided by a unified Cloud Inventory platform. Static point-in-time asset registers don't satisfy the continuous monitoring intent of the regulation.
Protection controls under DORA's ICT risk management pillar require patch management, configuration hardening, and access control. CIS Benchmarks are a reasonable baseline for configuration hardening. Patch cadence needs to be demonstrable through scan history — tools providing VM Scans generate that historical record automatically.
Detection controls require network monitoring, anomaly detection, and log management. SIEM integration, EDR coverage, and cloud-native detection rules covering the most relevant MITRE ATT&CK techniques for financial sector threat actors (APT groups targeting SWIFT, ransomware operators, insider threats) are the baseline expectation.
For code-level security — especially relevant for financial entities building or operating their own software — SAST tooling and Secret Detection should be embedded in CI/CD pipelines. Hardcoded credentials in source code are a recurring finding in ICT security audits and represent exactly the kind of preventable control failure that regulators flag.
Recovery capabilities require tested, documented, and achievable RTO/RPO targets for critical functions. Business continuity tests must be conducted at least annually for critical functions, with results documented and reviewed at governance level.
Where to Get the DORA Regulation PDF
The authoritative source for the DORA regulation PDF is the Official Journal of the European Union. Regulation (EU) 2022/2554 was published in the Official Journal on December 27, 2022. The full text — including all recitals, articles, and annexes — is freely available on EUR-Lex at eur-lex.europa.eu. The ESAs maintain a dedicated DORA section on their respective websites where all finalized RTS, ITS, and Q&As are published. For practitioners, the EBA's DORA implementation page is probably the most comprehensive single reference point for consolidated RTS/ITS documents.
Be cautious of third-party summaries and unofficial PDFs. The devil is in the specific wording of the RTS annexes, and paraphrased versions frequently omit or soften critical obligations. Go to the primary source.
Building a DORA-Ready Security Architecture
DORA compliance isn't a one-time project. It's an ongoing operational state that requires tooling, process, and governance to sustain. Organizations that are treating DORA as a checkbox exercise are going to face repeat findings as supervisors mature their inspection methodologies.
The organizations getting this right in 2026 share a few characteristics: they've mapped DORA requirements to specific technical controls with named owners; they're generating continuous compliance evidence rather than assembling it retrospectively before an audit; and they've integrated DORA obligations into their broader Vulnerability Management and risk governance processes.
At SECRAILS, we work with financial sector organizations navigating exactly this challenge — connecting the regulatory obligations of DORA to the technical controls and evidence generation that supervisors actually scrutinize. The gap between a DORA policy document and a DORA-compliant operational posture is significant, and closing it requires both the right tooling and the right expertise.