DORA Compliance: Technical Requirements for Financial Institutions

What Is DORA and Why It Was Introduced

For most of the past decade, a bank operating across the EU faced a patchwork of inconsistent national cybersecurity requirements. A firm regulated in Germany navigated BaFin's BAIT circular; one in the Netherlands worked with DNB guidelines; a cross-border payment institution pieced together requirements from multiple competent authorities. The result was regulatory arbitrage, duplicated compliance effort, and — more critically — uneven baseline resilience across the financial system.

The Digital Operational Resilience Act (DORA) — EU Regulation 2022/2554 — was designed to end that fragmentation. Published in December 2022 and directly applicable across all EU member states without need for national transposition, DORA establishes a single, unified framework for ICT risk management in financial services. It entered into force on 16 January 2023 and became fully applicable on 17 January 2025. For IT security teams in financial firms, that deadline has passed. The question now is not whether DORA applies — it does — but whether your controls can survive regulatory scrutiny.

DORA's political logic is straightforward: financial stability increasingly depends on operational resilience. The 2017 NotPetya attack, the 2021 Microsoft Exchange exploits, and a string of third-party cloud outages demonstrated that ICT failures cascade across interconnected institutions. Prudential capital buffers cannot absorb a ransomware attack that takes core banking systems offline for seventy-two hours. DORA addresses that gap by treating digital resilience as a prudential requirement, not merely an IT best practice.

---

Who Is In Scope

DORA's scope is deliberately broad. The regulation covers:

• Credit institutions (banks and building societies)
• Payment institutions and electronic money institutions
• Investment firms and trading venues
• Insurance and reinsurance undertakings
• Crypto-asset service providers (CASPs) as defined under MiCA
• Central counterparties, central securities depositories, and other market infrastructure operators
• Credit rating agencies and data reporting service providers
• ICT third-party service providers designated as critical (CTPPs) by the European Supervisory Authorities (ESAs)

Proportionality applies: microenterprises — entities with fewer than ten employees and annual turnover below €2 million — benefit from lighter obligations in specific areas. However, most banks, insurers, and investment firms that would read this article will be subject to the full regime.

One of DORA's most consequential innovations is the direct supervision of critical third-party providers. Cloud hyperscalers, core banking software vendors, and managed security service providers that are designated as CTPPs become subject to oversight by a Lead Overseer (one of the three ESAs — EBA, ESMA, or EIOPA). That designation changes the risk posture of the financial entity: your vendor's controls are now a regulatory matter, not merely a contractual one.

---

The Five Pillars of DORA

1. ICT Risk Management

DORA requires financial entities to maintain a comprehensive ICT Risk Management Framework — a documented, board-approved set of policies, procedures, and controls that covers the full lifecycle of ICT assets. This is not a checkbox document. Regulators expect evidence of:

• A risk appetite statement specific to ICT risk, approved at management body level
• An asset inventory covering all ICT assets and their criticality classification
• Protection and prevention controls — network segmentation, access control, encryption, patch management — documented with ownership
• Detection capabilities — continuous monitoring, log management, anomaly detection — with defined thresholds
• Business Continuity Plans (BCP) and Disaster Recovery (DR) plans tested at least annually, with documented recovery time objectives (RTOs) and recovery point objectives (RPOs) for critical functions

A recurring finding in early DORA readiness assessments is that firms have controls in place but lack the governance documentation regulators expect. The ICT Risk Management Framework must be a living document with version history, board sign-off, and regular review cycles — not a policy PDF last updated before a merger three years ago.

2. ICT Incident Reporting

DORA introduces a harmonized major incident reporting regime that supersedes prior national notification obligations for ICT incidents in financial services. Security teams need to understand both the classification criteria and the reporting timeline.

Classification criteria for major incidents include: number of clients or counterparties affected, geographic scope, duration and service degradation level, economic impact (losses or potential losses), reputational harm, data confidentiality or integrity breach, and criticality of affected services. The ESAs have published Regulatory Technical Standards (RTS) specifying thresholds.

Once an incident is classified as major, the three-stage reporting cycle begins:

Stage	Deadline	Content
Initial notification	Within 4 hours of classification	Incident ID, classification rationale, affected services, preliminary impact
Intermediate report	Within 72 hours	Updated impact assessment, containment measures taken, estimated duration
Final report	Within one month	Root cause analysis, full impact, remediation actions, lessons learned

Reports go to the competent national authority (e.g., BaFin, DNB, FCA for UK-equivalent regimes). The competent authority may forward reports to the ESAs and, for cross-border incidents, to authorities in other member states.

Security operations teams should build incident classification logic into their SIEM and ticketing workflows before an incident occurs. Deciding whether an active breach is "major" under DORA at 2 a.m. under incident pressure is the wrong time to interpret regulation.

3. Digital Operational Resilience Testing

DORA mandates a tiered testing programme that scales with entity size and systemic importance.

All in-scope entities must conduct regular vulnerability assessments — network scans, application security reviews, configuration audits — and scenario-based testing of business continuity and disaster recovery plans.

Significant entities — those identified by competent authorities based on systemic importance — must additionally conduct Threat-Led Penetration Testing (TLPT) at least every three years. See the dedicated TLPT section below for what that entails in practice.

Testing results must be reported to the management body and used to drive a remediation roadmap. The regulation requires that identified vulnerabilities are addressed within agreed timelines and that progress is tracked.

4. ICT Third-Party Risk

This pillar represents one of DORA's most operationally demanding requirements. Financial entities must:

• Maintain a register of all ICT contracts with third-party providers, distinguishing between services supporting critical or important functions and others
• Ensure contracts include mandatory clauses: full service level descriptions, audit rights (including on-site), data portability and return provisions, secure deletion guarantees, cooperation with regulators, and termination rights under defined conditions
• Assess and manage concentration risk — over-reliance on a single provider or a small number of providers for critical functions
• Maintain and test exit strategies for critical third-party services, including documented transition plans that do not assume the departing vendor's cooperation

Where a third-party provider is designated as a CTPP, financial entities must cooperate with oversight activities and cannot be shielded by confidentiality clauses from disclosing contract terms to regulators.

Procurement and vendor management teams need to audit existing contracts against DORA's mandatory clause requirements and re-negotiate or supplement agreements that fall short. For legacy contracts with long initial terms, this is a non-trivial legal exercise that should have started well before January 2025.

5. Information Sharing

DORA encourages — but does not mandate — participation in threat intelligence sharing arrangements between financial entities. The regulation creates a legal basis for firms to exchange cyber threat information, including indicators of compromise, attack patterns, and defensive insights, without inadvertently breaching data protection rules.

In practice, this pillar supports participation in existing ISACs (Information Sharing and Analysis Centers) such as FS-ISAC, and in national-level threat intelligence groups. Regulators view active information sharing as evidence of a mature security culture.

---

TLPT: Threat-Led Penetration Testing in Depth

TLPT is not a standard penetration test. Where a conventional pentest asks a team to find as many vulnerabilities as possible within a time-boxed engagement, TLPT asks: what would a sophisticated, targeted threat actor actually do to this firm?

The methodology rests on three components:

1. Threat intelligence — a bespoke threat intelligence report produced by an approved Threat Intelligence Provider, profiling the most plausible adversaries targeting the specific entity, their known TTPs (Tactics, Techniques, and Procedures), and likely attack scenarios
2. Red team exercise — a skilled red team executes realistic attack scenarios against live production systems (not sandboxes or copies), attempting to achieve realistic objectives such as data exfiltration, fund transfer fraud, or core system disruption
3. Blue team participation — the defensive team (either unaware for a full blind test, or partially informed for a purple team variant) responds, and their detection and response capability is assessed alongside the red team's findings

DORA references the TIBER-EU framework — the Threat Intelligence-Based Ethical Red Teaming framework published by the European Central Bank — as the reference methodology. National implementations (TIBER-DE, TIBER-NL, CBEST in the UK) are aligned with TIBER-EU and are accepted by DORA's mutual recognition provisions: a TLPT conducted under TIBER-EU in one jurisdiction can satisfy requirements in others, reducing duplicated testing burden for cross-border firms.

Running a TLPT requires significant preparation: scoping the critical functions to test, selecting and contracting approved providers, establishing a control team to manage the exercise, and ensuring legal and regulatory notifications are in place before the red team begins. A poorly scoped TLPT that avoids production systems or excludes key business processes will not satisfy regulators.

---

Key Deadlines: What Is Already in Force

DORA became fully applicable on 17 January 2025. There is no transition grace period for the core obligations. However, several Regulatory Technical Standards and Implementing Technical Standards were published in phased batches through 2024 and into 2025, and some operational details — particularly around CTPP designation and TLPT mutual recognition — continue to be refined through ESA guidance.

Firms should treat the full framework as live and audit-ready. Competent authorities across the EU have begun supervisory exercises targeting DORA compliance, and enforcement actions are expected to escalate through 2025 and 2026.

---

Conducting a DORA Gap Analysis

Before committing to a compliance roadmap, run a structured gap assessment against each of the five pillars. A practical approach:

1. Document your current state — for each pillar, map existing policies, controls, and processes against DORA's requirements. Use the RTS and ITS texts, not summaries, as the source of truth.
2. Identify gaps by criticality — distinguish between gaps that are regulatory red lines (missing incident reporting procedures, absent board governance of ICT risk) and those that are enhancement areas (threat intelligence sharing, TLPT programme maturity).
3. Assess third-party contracts — review all ICT contracts for critical and important functions against mandatory clause requirements. This is often the longest-lead item due to re-negotiation timelines.
4. Build a remediation roadmap — assign owners, timelines, and budget. Present to the management body for approval; DORA explicitly requires board-level accountability.
5. Test before regulators do — conduct internal tabletop exercises simulating a major incident report under the 4-hour/72-hour/one-month timeline before you face a real event.

---

Related Reading

DORA does not exist in isolation. If your firm is also working through related security and compliance frameworks, the following guides may be useful:

• Building a PSIRT: Product Security Incident Response — covers incident response programme structure that complements DORA's incident classification and reporting requirements
• TISAX Compliance for Automotive and Finance — relevant for financial firms with automotive sector clients or supply chain exposure requiring TISAX certification alongside DORA

---

DORA raises the floor for ICT resilience across European financial services. For security teams, the practical work is detailed and operationally demanding — but the framework itself is coherent. Firms that treat it as a genuine resilience programme, rather than a documentation exercise, will emerge with measurably stronger security posture, not just a compliance certificate.