DORA — The Complete Global Guide to Digital Operational Resilience Act

Financial Entities Covered by DORA

The Proportionality Principle

DORA does not treat a community credit union the same as a global systemically important institution. Article 4 establishes the proportionality principle: financial entities must tailor their compliance approach based on size, risk profile, and operational complexity. Microenterprises — those with fewer than 10 employees and an annual turnover below €2 million — are exempt from certain requirements, including the digital operational resilience testing programme under Article 24.

What proportionality does not do is remove the obligation to comply. It adjusts the depth and formality of the approach, not the requirement to have one. Competent authorities explicitly assess proportionality when reviewing ICT risk management frameworks.

Practitioner Note

Many firms discovered during gap analysis that their existing ICT risk controls, while broadly sound, were neither documented nor structured in the way DORA requires. Gap analysis under DORA must compare your current state against each of the five pillars specifically — a generic IT audit does not substitute for a DORA gap assessment.

Pillar 1 — ICT Risk Management (Articles 5–16)

Every financial entity must maintain a sound, comprehensive, and well-documented ICT risk management framework as part of its overall risk management system. Article 6 specifies that the framework must include strategies, policies, procedures, ICT protocols, and tools necessary to protect all information assets and ICT assets — including computer software, hardware, servers, data centres, and physical premises.

The framework must include a digital operational resilience strategy that explains how it supports business objectives, establishes risk tolerance levels, sets measurable security objectives (including KPIs and KRIs), and outlines a communication strategy for ICT-related incidents. The management body — not just the IT department — is directly accountable for approving this strategy and monitoring its execution.

Article 9 requires financial entities to identify all ICT assets and classify information. Article 10 mandates detection capabilities. Articles 11–13 cover business continuity and disaster recovery planning. Article 15 governs learning and evolving — the framework must be updated when incidents occur or when the risk environment changes. Outsourcing the verification of compliance is permitted, but the financial entity remains fully responsible.

Pillar 2 — ICT-Related Incident Management and Reporting (Articles 17–23)

Financial entities must define, establish, and implement an ICT-related incident management process capable of detecting, managing, and notifying incidents (Article 17). This requires a documented classification scheme that distinguishes minor incidents from major ones — a classification that determines whether regulatory reporting is triggered.

Major ICT-related incidents must be reported to the relevant competent authority under a structured three-phase timeline: an initial notification, an intermediate report, and a final report. DORA also introduced voluntary reporting for significant cyber threats — even where no incident has materialised — which is a forward-looking requirement that many firms underestimated during implementation.

The incident management process must be documented in a dedicated policy, tested periodically, and integrated with the business continuity arrangements under Pillar 1. Post-incident reviews must feed back into the ICT risk management framework — creating a closed loop between detection, response, and improvement.

Pillar 3 — Digital Operational Resilience Testing (Articles 24–27)

Article 24 requires all financial entities (except microenterprises) to establish, maintain, and periodically review a sound and comprehensive digital operational resilience testing programme. This programme must be integrated into the ICT risk management framework and must cover a range of assessment types — from basic vulnerability assessments and network security testing to advanced scenario-based testing.

For systemically significant entities, Article 26 introduces Threat-Led Penetration Testing (TLPT) — the most demanding testing requirement in DORA. TLPT simulates real-world attack scenarios using intelligence-led methodologies. It must be conducted by qualified external testers against live production systems. A dedicated control team lead must be appointed (per JC 2024 29, Article 4) to manage day-to-day TLPT execution.

Where ICT third-party providers are included in the TLPT scope, the financial entity remains fully responsible. Pooled TLPT — where multiple financial entities share a single test against a common critical provider — is expressly permitted and may be the practical approach for concentrated supply chains.

Pillar 4 — Management of ICT Third-Party Risk (Articles 28–44)

This is the pillar that changes the relationship between financial entities and their technology vendors most fundamentally. Under Article 28, financial entities must manage ICT third-party risk as an integral component of their overall ICT risk management framework — not as a separate procurement exercise. At all times, regardless of what a vendor contract says, the financial entity remains fully responsible for regulatory compliance.

Specific obligations include: maintaining a complete information register of contractual arrangements with ICT third-party providers (at individual, consolidated, and sub-consolidated levels); conducting preliminary assessments of ICT concentration risk; ensuring mandatory contractual provisions are in place for all critical or important function contracts; and establishing exit strategies for every critical third-party relationship.

The risk assessment must consider the type of services provided, the location of the provider and where services are actually delivered from, the nature of data shared, whether the provider is subject to EU regulatory oversight, and the potential impact of a disruption. Concentration risk — particularly where multiple financial entities depend on the same handful of cloud hyperscalers — is an explicit concern in the regulation.

The Oversight Framework and the Lead Overseer

DORA's Oversight Framework (Articles 31–44) introduces direct regulatory supervision of Critical ICT Third-Party Providers (CTPPs) — the hyperscalers, core banking vendors, and payment infrastructure providers on which the financial system most depends. A Lead Overseer, drawn from EBA, ESMA, or EIOPA depending on the CTPP's primary client base, holds direct powers of inspection, information request, and penalty imposition.

The Oversight Forum — a sub-committee of the Joint Committee of the ESAs — coordinates the programme across sectors. CTPPs designated as critical must cooperate fully with the Lead Overseer, including accepting on-site inspections. A CTPP from outside the EU that is designated as critical must establish an EU subsidiary within 12 months of designation.

Pillar 5 — Information and Intelligence Sharing (Article 45)

Article 45 enables — and encourages — financial entities to exchange cyber threat information and intelligence with one another. This includes indicators of compromise, tactics, techniques and procedures (TTPs), cybersecurity alerts, and configuration tools. Participation is voluntary, but the intention is to create a collective early-warning ecosystem across the EU financial sector.

Information-sharing arrangements must be designed with appropriate safeguards: data must be handled responsibly, confidentiality must be preserved, and the arrangements must be compatible with data protection law. Participating in an information-sharing arrangement does not transfer liability — each entity remains responsible for its own ICT risk management.

Fundamental Nature

Where They Overlap

ISO 22301 and DORA share significant conceptual territory. Both require understanding business impact, identifying critical functions, maintaining plans for disruption, testing those plans, and continually improving. DORA's ICT risk management framework (Articles 5–16) mirrors the structure of a BCMS — assess risks, implement controls, test, review, improve.

The PECB DORA Lead Manager training explicitly references the concept of organisational resilience (from ISO 22316), business continuity planning, and disaster recovery — acknowledging that DORA's operational continuity requirements (Articles 11–13) are conceptually grounded in business continuity management practice.

For more on the ISO 22301 scope definition process — which determines which functions and organisational units fall inside your BCMS — see our guide: Organisational and physical boundaries, dependency rules, and justifying exclusions under ISO 22301 Clause 4.3.

Where They Diverge

ISO 22301 is sector-agnostic and technology-agnostic. It is a management system standard built around the Plan-Do-Check-Act cycle with high-level requirements that organisations implement in ways appropriate to their context. DORA is prescriptive: it specifies what must be in the ICT risk management framework, what the incident reporting timelines are, which contracts must contain which clauses, and how critical third-party providers will be supervised.

ISO 22301 covers all threats to business continuity — natural disasters, power failures, public health emergencies, supply chain disruptions — not just ICT. DORA is exclusively focused on ICT and digital risk. A financial entity certified to ISO 22301 has demonstrated strong business continuity practices, but that certification does not substitute for DORA compliance — nor does DORA compliance substitute for ISO 22301 certification where that is required by contract, insurer, or regulator.

The practical implication: firms pursuing both should run them as an integrated programme, not parallel silos. The DORA ICT risk management framework and the ISO 22301 BCMS share governance structures, risk assessment methodology, and testing requirements. Running them together reduces duplication and demonstrates a higher level of resilience maturity to both regulators and auditors.

Also building your ISO 22301 programme?

Read the ISO 22301 Complete Global Guide or explore our certification courses:

DORA and NIS 2 Directive

Both DORA and the NIS 2 Directive aim to enhance digital resilience and reduce cyber incidents across the EU. The key distinction: DORA includes a lex specialis provision — where DORA applies, it takes precedence over NIS 2 for financial entities. This was a deliberate design choice to avoid regulatory duplication and ensure that the more specific and demanding DORA framework is the operative standard for the financial sector.

DORA and GDPR

DORA builds on GDPR requirements but does not override them — both frameworks continue to apply in parallel. DORA focuses on information system security from an operational resilience perspective; GDPR governs personal data protection. They intersect significantly: an ICT incident that compromises data availability or integrity may trigger both a DORA major incident report and a GDPR personal data breach notification. Compliance teams must manage both notification obligations simultaneously, with different authorities and different timelines.

DORA and the Cyber Resilience Act (CRA)

The EU Cyber Resilience Act (CRA), which came into force in late 2024 with a 36-month implementation window, applies to manufacturers, dealers, and importers of products with digital elements — across all sectors. DORA applies to the financial sector. Where an ICT product used by a financial entity falls under the CRA, both frameworks may apply to different aspects of the same supply chain relationship. The CRA focuses on product cybersecurity by design; DORA focuses on how financial entities manage the operational risk of using those products.

Phase 1 — Context, Gap Analysis, and Governance

Before any controls are implemented, map your entity's context: which legal entities are in scope, what functions are critical, who your material ICT third-party providers are, and what your current state of ICT risk management looks like against each of the five DORA pillars. Gap analysis is the foundation — it identifies the delta between where you are and where the regulation requires you to be, and it quantifies the investment in time, money, and human resources required. At the same time, establish the governance structure: the management body must understand its DORA responsibilities and approve the ICT risk management framework.

Phase 2 — ICT Risk Management Framework

Build or upgrade the ICT risk management framework to meet Article 6 requirements. This means documented policies, a digital operational resilience strategy, asset identification and classification, detection capabilities, business continuity and disaster recovery arrangements, and a mechanism for post-incident learning. The framework must be demonstrably integrated into the overall risk management system — not a standalone IT document.

Phase 3 — Incident Management and Reporting

Establish the incident management process and classification scheme. Map every major incident classification criterion from JC 2023 83 against your existing incident response procedures. Identify the notification workflows — which authority, which timelines, which templates. Test the process before you need it.

Phase 4 — Third-Party Risk and Register of Information

Build the register of information (per JC 2023 85 ITS templates) for all contractual arrangements with ICT providers. Conduct preliminary ICT concentration risk assessments. Review all critical or important function contracts against the DORA mandatory contractual provisions list. Establish exit strategies for each critical provider. This phase often takes longer than expected — the data gathering from business units and procurement teams is invariably the bottleneck.

Phase 5 — Testing Programme

Design and execute the digital operational resilience testing programme. Start with the basic tests — vulnerability assessments, network security testing, gap analyses — before advancing to scenario-based and open-source intelligence testing. For entities in scope for TLPT, plan the timeline carefully: from scoping to execution to remediation to regulatory validation can take nine to twelve months.

Phase 6 — Monitoring, Audit, and Continual Improvement

Establish the performance measurement and compliance reporting cycle (drawing on ISO 37301 principles, which DORA training explicitly references). Run internal audits of the ICT risk management framework. Conduct management reviews. Document improvements in a continual improvement register that tracks each change: description, priority, initiation date, completion date, and responsible owner. The continual improvement cycle is not optional — it is what transforms a point-in-time compliance exercise into sustainable digital operational resilience.

Practitioner Note

At reconn, we have seen entities underestimate two things consistently: the volume of documented information DORA requires, and the effort involved in getting third-party contracts reviewed and renegotiated. Both deserve dedicated resources — not best-effort work alongside existing BAU responsibilities. A dedicated DORA programme manager with the right certification is the single most effective investment a mid-sized financial entity can make at this stage.