DORA: What It Requires and Who It Applies To

What is DORA?

DORA is Regulation (EU) 2022/2554 on digital operational resilience for the financial sector. The European Parliament and the Council of the EU adopted it on November 14, 2022. It entered into force on January 16, 2023 and became fully applicable on January 17, 2025, giving financial entities a two-year implementation window.

European regulators spent years watching IT outages at major banks, ransomware attacks on payment processors, and cloud provider incidents cascade into customer harm. DORA's purpose is to make the EU financial system resilient to ICT-related disruptions by setting harmonized requirements across all 27 member states, replacing a patchwork of national rules with a single, directly applicable regulation.

The three European Supervisory Authorities (EBA, ESMA, and EIOPA) jointly developed the technical standards that give DORA its operational specificity. Those standards cover incident classification thresholds, penetration testing methodology, ICT contract requirements, and the content of a digital operational resilience strategy document. The full regulatory package runs to fourteen regulatory technical standards and four implementing technical standards, published in batches through 2024.

DORA intersects with several other EU frameworks. Firms must coordinate their DORA incident reporting procedures with GDPR (EU) breach notification timelines, since the same IT failure can trigger obligations to both the financial supervisor and the data protection authority. The EU AI Act (EU) adds a parallel documentation layer for AI systems embedded in core ICT infrastructure. And the proposed PSD3 (EU) incorporates DORA's requirements by reference for payment institutions rather than creating a new regime.

One distinction worth stating plainly: DORA is not guidance. It is directly applicable law. Firms cannot rely on a national supervisor taking a lenient view of implementation. The text is the standard.

Who does DORA apply to?

DORA's scope is wider than most EU financial regulations. Article 2 lists covered entity types:

• Credit institutions (banks, savings banks, cooperative banks)
• Payment institutions, including those previously exempt under PSD2
• Electronic money institutions
• Investment firms regulated under MiFID II
• Crypto-asset service providers (CASPs) under MiCA (EU), where that regime overlaps with DORA's operational risk obligations
• Central counterparties, central securities depositories, and trade repositories
• Alternative investment fund managers and UCITS management companies
• Insurance and reinsurance undertakings subject to Solvency II, above the threshold
• Occupational pension funds with 15 or more members
• Credit rating agencies and benchmark administrators
• Critical ICT third-party service providers (CTPPs), designated by the ESAs

That last category is new and consequential. DORA reaches outside the financial sector to bring cloud providers, data analytics vendors, and other technology firms under direct ESA oversight if they provide services systemic enough to qualify as critical. Microsoft, Amazon Web Services, Google Cloud, and IBM have all been identified in supervisory discussions as likely CTPP candidates. Once designated, they face direct oversight from a lead ESA and a specific penalty regime.

There is a proportionality provision. Microenterprises (under 10 staff and EUR 2 million annual turnover) face simplified requirements on ICT risk management and testing. But incident reporting, the mandatory ICT contract clauses, and information sharing provisions apply at full weight regardless of size.

Jurisdictionally, DORA covers the EU. UK entities are not directly subject to it. The Bank of England, PRA, and FCA set parallel operational resilience requirements through PS6/21 and PS7/21, with a final compliance deadline of March 31, 2025.

What does DORA require?

DORA's obligations organize into five pillars:

1. ICT risk management framework. Firms must maintain a documented ICT risk management framework, approved by the management body. Article 5 places ultimate accountability at board level. The framework must cover asset identification, protection, detection, response, and recovery. It requires an ICT strategy with a three-year horizon, a current asset inventory classified by criticality, business continuity plans tested at least annually, and defined recovery time objectives (RTOs) and recovery point objectives (RPOs) for all critical systems.

2. ICT-related incident management and reporting. Firms must maintain a dedicated incident management process and classify incidents against the EBA's quantitative thresholds. For major incidents, the reporting timeline is strict: initial notification to the competent authority within 4 hours of classifying the incident as major (and no later than 24 hours after first becoming aware), an intermediate report within 72 hours, and a final report within one month. The EBA's Implementing Technical Standard on incident reporting sets numeric thresholds for client impact, geographic scope, transaction volumes, and outage duration.

3. Digital operational resilience testing. All covered entities must run a basic testing program: vulnerability assessments, network security tests, and scenario-based tests annually at minimum. Significant entities face an additional obligation: Threat-Led Penetration Testing (TLPT) every three years on live production systems, conducted by certified external testers using the TIBER-EU framework developed by the ECB. Testers use actual adversarial techniques against production infrastructure, not synthetic test environments.

4. ICT third-party risk management. Every ICT service contract must contain mandatory clauses covering security and service-level requirements, audit rights for the financial entity and competent authorities, incident notification obligations from the provider, data location and portability requirements, and exit strategies. Firms must maintain a register of all ICT contracts and report significant contracts to regulators. The third-party risk management requirements here are more prescriptive than the US approach; for comparison see SR 23-4 (US-FRB), which operates under guidance rather than statute.

5. Voluntary information sharing. DORA explicitly provides a legal basis for firms to share cyber threat intelligence with each other and with competent authorities, within confidentiality arrangements. This isn't mandatory, but supervisors expect it in practice and it's increasingly referenced in examination findings.

What evidence do regulators expect?

Supervisors examining DORA compliance want documentation across all five pillars. Here is what that means on an audit day:

ICT risk management:

• Board-approved ICT strategy document, dated within the last three years
• Current asset inventory with criticality classifications, reviewed at least annually
• Business impact analysis results, showing which systems are critical and why
• Defined RTOs and RPOs for every critical system
• Business continuity test records for the last 12 months, including failure findings and remediation

Incident management:

• Incident classification methodology, with clear cross-reference to EBA threshold definitions
• Records of all major incidents reported, with timestamps demonstrating the 4-hour and 72-hour deadlines were met
• Post-incident review reports for each major incident

Resilience testing:

• Annual testing schedule with completion evidence
• Vulnerability assessment and penetration test results for the last three years
• For significant entities: TLPT scope documents, tester credentials and certification, test results, and a remediation tracker showing how findings were addressed
• Evidence the tests covered live production systems

Third-party risk:

• Complete ICT contract register, covering all ICT service providers
• Contract copies showing mandatory DORA clauses are present, including audit rights and exit provisions
• Exit plans for critical ICT providers, confirmed executable at last test
• Due diligence records for each critical provider, updated at contract renewal

Governance:

• Board minutes showing management body engagement with ICT risk, at least quarterly
• Named individual at executive level accountable for ICT risk
• Training completion records for ICT risk topics across relevant staff

Supervisors have flagged one recurring problem: policies that describe controls that don't exist in practice. If your recovery plan says four-hour RTO and your last actual test took three days, the written plan makes things worse, not better.

Common failure modes

The ESAs' supervisory convergence work and pre-application reviews have identified consistent weaknesses across institutions:

• Incomplete asset inventories. Most banks catalog their primary data centers and core platforms. They miss shadow IT, business-unit SaaS subscriptions, APIs connected to third parties without central IT awareness, and legacy systems that predate current governance. An ICT risk framework is only as good as the asset list it covers.

• Untested recovery objectives. Setting a four-hour RTO in a policy document and then never running a realistic recovery exercise against a major production system. When real outages happen, dependencies surface that the tabletop exercise never exposed.

• Vendor contracts missing mandatory clauses. Existing contracts predating January 2025 frequently lack audit rights clauses, data location provisions, and exit strategy terms. Remediating thousands of contracts across global vendor bases in two years was a genuine operational challenge, and many firms entered DORA's application date with gaps they're still closing.

• Delaying incident classification. Firms that held a potential major incident at "monitoring status" while doing internal triage before notifying the supervisor. The 4-hour clock runs from classification, and using internal review time to avoid triggering that clock is itself a compliance failure.

• Scoped TLPT exercises. Some firms attempted to confine threat-led penetration tests to secondary or non-critical systems, avoiding the most sensitive production environments. Supervisors have pushed back directly. DORA's intent is adversarial testing of systems whose failure would cause real harm.

Formal DORA enforcement cases are not yet published, given the January 2025 start date. The ECB's TIBER-EU assessments from 2021 through 2024 provide the clearest precedent on what regulators consider acceptable scope and quality for threat-led testing. The ECB's TIBER-EU implementation guidance sets out the minimum standards in detail.

Penalties for non-compliance

DORA operates a two-track penalty regime, depending on who is being sanctioned.

Financial entities face penalties set by national competent authorities. Unlike GDPR, DORA does not specify a maximum fine as a percentage of global turnover. Article 50 requires member states to ensure their competent authorities can impose "effective, proportionate, and dissuasive" administrative penalties. Member states have implemented this with different caps, but the practical expectation in the EBA's supervisory convergence guidance is alignment with existing sectoral frameworks. In Germany, BaFin can impose fines of up to EUR 5 million for natural persons and up to EUR 5 million or twice the economic benefit for legal entities. In France, the ACPR's existing powers allow penalties of up to 10% of net banking income. The numbers vary by jurisdiction.

Supervisors can also impose non-monetary measures: requiring specific remediation actions, restricting business activities pending compliance, or publishing the identity of non-compliant firms. In EU financial markets, public naming tends to generate more immediate board attention than a monetary fine.

Critical ICT third-party providers (CTPPs) face a penalty regime written directly into DORA. The lead ESA can impose periodic penalty payments of up to 1% of the CTPP's average daily worldwide turnover, for up to six consecutive months. In the extreme case, the lead ESA can recommend that financial entities terminate their contracts with the CTPP. For a cloud provider generating EUR 30 billion in annual revenue, 1% of daily turnover is approximately EUR 800,000 per day. That's a meaningful number.

The operational risk dimension connects DORA breaches directly to BCBS 323 (BCBS). A material DORA breach that generates a significant customer-affecting incident may simultaneously trigger Pillar 2 capital add-ons from the ECB under the Supervisory Review and Evaluation Process. The EBA's DORA supervisory convergence programme outlines how national supervisors are expected to approach examination and enforcement.

Related regulations and frameworks

DORA sits within a broader architecture of EU and international requirements. Understanding the relationships matters for building compliance programs that don't duplicate effort or leave gaps.

EU internal:

NIS2 (Directive (EU) 2022/2555): The Network and Information Security Directive 2 covers cybersecurity for "essential entities" broadly across sectors. Financial entities subject to DORA are explicitly carved out from NIS2's incident reporting obligations, because DORA is the sector-specific lex specialis. But NIS2 still applies to ICT suppliers that aren't designated as CTPPs, and to the supervisory authorities themselves. Firms need to map which of their vendors falls under which framework. The NIS2 Directive text sets out the carve-out explicitly in Article 4.

GDPR: A personal data breach arising from an ICT incident creates parallel reporting obligations under GDPR (72 hours to the data protection authority) alongside DORA's incident reporting chain (4 hours initial, 72 hours intermediate). Firms need coordinated procedures. Two separate incident response workflows that don't talk to each other produce inconsistent notifications and create examination risk.

PSD3: The proposed PSD3 incorporates DORA's operational resilience requirements by reference for payment institutions. Once adopted, it won't add new ICT obligations; it confirms that payment institutions already covered by DORA won't face a second parallel regime.

International equivalents:

The UK's operational resilience framework (PS6/21, PS7/21) requires UK banks to identify important business services, set impact tolerances, and test them. It's principles-based rather than prescriptive, which means more supervisory discretion in both directions.

In the US, SR 23-4 (US-FRB) sets guidance on third-party risk management for Federal Reserve-supervised entities, and BCBS 239 (BCBS) addresses the risk data aggregation capabilities that sit underneath any serious operational resilience program. Neither is a direct equivalent to DORA, and the US market has no single statute that consolidates ICT risk, incident reporting, and third-party oversight the way DORA does.

Singapore's MAS Technology Risk Management Guidelines share DORA's emphasis on recovery objectives and incident reporting but operate as guidelines rather than statute, giving MAS supervised entities more flexibility in implementation.

How FluxForce supports DORA compliance

FluxForce's regulatory compliance automation capabilities map directly to DORA's core obligations. Aiden Flux and Nova Sentinel monitor ICT events in real time, generate audit-ready incident records with full decision trails, and flag anomalies against configurable classification thresholds. The platform's third-party risk monitoring tracks signals from critical ICT vendors and surfaces contract-level gaps before an examiner does. Every action produces documented evidence, supporting both the incident classification timeline DORA mandates and the board-level reporting your management body needs. Request a demo to see how FluxForce handles DORA's operational resilience requirements end to end.