Most firms are treating DORA like GDPR: get a consultant, document the framework, move on. That worked for data privacy. It won't work for a regulation built around one premise: that financial entities will be attacked, and regulators want proof the system won't collapse when they are. Here's what DORA actually requires, where enforcement stands in 2026, and why compliance and resilience are not the same thing.
There’s a familiar playbook in financial services compliance. Regulation arrives. Consultants get hired. Frameworks get documented. A box gets ticked. Everyone moves on.
It worked well enough for GDPR. It’s the wrong approach for DORA, and regulators are now making that clear.
The Digital Operational Resilience Act came into force on January 17, 2025. Fourteen months on, only 1 in 3 firms were confident they could meet the deadline at all, according to McKinsey. Deloitte’s survey found just 50% of institutions expected full compliance by the end of 2025, with 38% pushing their target back to 2026. By July 2025, a Censuswide survey of 404 senior IT decision-makers across UK, France, Germany, and the Netherlands found 96% of EMEA financial services organizations still believe their resilience falls short of what DORA actually requires.
This is not a GDPR-style compliance sprint with a long tail of administrative catch-up. DORA is operationally focused. It’s built around one uncomfortable premise: financial entities will be attacked, and regulators want proof that those attacks won’t bring the system down with them.
Here’s what it actually requires.
The short answer: more organizations than most people assume.
Over 21,000 financial entities across the EU are in scope. Banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, central counterparties. If your organization touches EU financial infrastructure, DORA almost certainly applies.
The angle that regularly gets missed: ICT third-party service providers are also in scope, but not all in the same way. DORA creates two distinct categories of exposure.
The first is direct supervision. A small number of providers have been designated as Critical ICT Third-Party Providers (CTPPs) and are subject to direct EU regulatory oversight, covered in the next paragraph.
The second is broader and affects far more organizations. DORA requires every financial entity to identify which of its functions are critical or important and then assess every ICT provider that supports or contributes to those functions. Providers in that category become subject to specific contractual obligations, audit rights, and oversight requirements imposed by the financial entity itself. If you’re a cloud platform, software vendor, managed service provider, or data analytics provider contributing to any function a financial entity has classified as critical or important, DORA’s requirements flow directly to you through contract.
Where a financial entity runs a critical or important function entirely in-house, DORA’s ICT risk management obligations still apply in full.
Supply chain attacks are now the primary vector for compromising financial infrastructure. Direct attacks on financial institutions are hard. Attacking a software provider that serves fifty of them is considerably easier. DORA’s third-party framework is designed to close that gap systematically, not just flag it as a risk.
The ESAs formalized direct supervision on November 18, 2025, publishing the first list of 19 Critical ICT Third-Party Providers (CTPPs), including Amazon Web Services, Google Cloud, Microsoft, Oracle, and SAP. These providers are now subject to direct EU oversight: annual risk assessments, on-site inspections, and mandatory reporting to regulators.
If your organization either relies on these providers or sits anywhere in the supply chain of a firm that does, DORA’s third-party requirements should already be on your risk register.
DORA is structured around five core requirements. Here’s what they mean operationally, without the regulatory wrapper.
ICT risk management
Your board has to own this. Not delegate it, own it. DORA requires a documented ICT risk management framework approved at management body level, with clear accountability, regular review, and evidence that it actually shapes decisions. The management body approves the framework, reviews it at least annually, and is personally accountable if it fails.
Personal liability for senior executives who fail to adequately oversee ICT risk is live across multiple jurisdictions, with fines reaching up to €1,000,000 in some member states depending on the conditions set out in national implementing legislation. DORA itself does not set a harmonised figure at the EU level; the specific amounts vary by country. Board minutes are being reviewed for evidence that digital resilience appears as a standing agenda item.
ICT incident reporting
Major ICT-related incidents must be reported to your national competent authority within prescribed timeframes. Under DORA, a major ICT-related incident is an actual event that has a high adverse impact on your critical or important functions.
This is a specific defined term and should not be confused with a significant cyber threat, which is a separate category under Article 19. Significant cyber threats, meaning threats that haven’t yet caused disruption but meet certain criticality criteria, are subject to voluntary notification only. The mandatory reporting obligation is triggered by actual major incidents, not anticipated ones.
The timeline works as follows: an initial notification must be submitted within 4 hours of classifying the incident as major, and no later than 24 hours after first detection, whichever comes first. That 24-hour backstop matters: it prevents entities from delaying classification to avoid triggering the reporting clock. An intermediate report follows within 72 hours of classification, and a final report within one month. If your incident response process wasn’t built around these specific triggers and timeframes, it isn’t compliant.
Digital operational resilience testing
Every DORA-covered entity must run an annual program of threat-led, risk-based testing.
The scope is comprehensive: it covers all ICT systems supporting critical or important functions, not a selected subset. In practice, for most financial institutions, this encompasses significantly more systems than a traditional security testing scope would include. Tests must be approved by the management body, and the results must feed back into the ICT risk management framework at governance level. Regulators are specifically flagging situations where security testing exists as a technical exercise, disconnected from board oversight. That gap is now a compliance failure, not just a best-practice shortfall.
For institutions designated by their competent authority, DORA Article 26 adds a further requirement: Threat-Led Penetration Testing (TLPT). Designation is a formal notification process; competent authorities identify which institutions fall in scope based on systemic importance and risk profile. If you haven’t been notified, you aren’t currently in scope for TLPT, though that can change as supervisory priorities evolve. TLPT is an intelligence-led, full-scope red team exercise conducted on live production systems, with the defending team completely unaware. The first mandatory TLPT deadline is January 17, 2028. The technical implementation of TLPT follows the TIBER-EU framework, with country-specific guidance published by each member state’s central bank or competent authority. The next post in this series covers what a full TLPT cycle looks like in practice and why the lead time is shorter than most firms think.
ICT third-party risk management
This is currently the single biggest compliance failure point across the sector. 46% of institutions cited the Register of Information as their most challenging DORA requirement, per Deloitte survey data. The Register is a comprehensive, machine-readable inventory of all ICT third-party contracts, including sub-outsourcing chains, submitted annually to NCAs in a specific format.
The FCA reported that more than 40% of all cyber incidents it received in 2025 involved a third-party provider. That’s not a supply chain edge case. It’s the primary attack vector, and DORA’s third-party requirements exist precisely because of it. DORA’s response is to make that exposure a matter of documented, supervised accountability rather than an internal risk management preference.
Information Sharing
DORA actively encourages financial entities to share cyber threat intelligence with each other and with regulators. This isn’t optional. It’s a structural shift in how the sector is expected to operate: less competitive secrecy around threat data, more collective early warning. The ESAs are currently assessing whether a single EU hub for ICT incident reporting should be established permanently.
2025 was broadly a supervised transition year. Regulators focused on reviewing frameworks and identifying gaps, giving tolerance to firms demonstrating good faith effort on documentation. That period is over.
In 2026, NCAs shifted to active enforcement. BaFin announced formal follow-up audits through 2026 and 2027, specifically targeting the quality of information registers, documented ICT risk frameworks with board sign-off, and TLPT follow-through. Across the EU, national supervisors are now using automated systems to cross-reference Register of Information submissions, identify inconsistencies with incident reporting histories, and issue supervisory follow-up without waiting for firms to self-report.
The penalty framework is not theoretical. Financial entities face fines of up to 2% of total annual worldwide turnover. Critical ICT third-party providers face up to €5 million. In Italy and Ireland, the ceiling rises to €20 million or 10% of turnover. An EBA peer review on DORA implementation is scheduled for Q3 2026, the first formal cross-EU supervisory comparison of implementation quality. The results will be instructive for any firm that spent 2025 on documentation alone.
The instinct to treat DORA like GDPR is understandable. GDPR was large, complex, and ultimately navigable with solid documentation and a data protection officer. Most firms got through it without structural operational change.
DORA is different in one critical respect. It’s not primarily about what data you hold or how you process it. It’s about whether your organization can survive a serious, sustained attack on its systems.
That’s a technical question. No amount of policy writing answers it.
96% of EMEA financial services organizations believe their resilience falls short of what DORA demands. The firms that are genuinely ahead aren’t just the ones with the tidiest information registers. They’re the ones that have tested their systems under realistic attack conditions and know where the gaps actually are.
The firms that will struggle aren’t necessarily the ones who ignored DORA. Most attempted it. They’re the ones that built a compliance program capable of satisfying an auditor but haven’t yet proved they can hold up when someone is actively trying to get in.
That distinction matters, because DORA doesn’t ask whether you have a framework. It asks whether it works.
Sources
This is the first post in a four-part series on DORA and what genuine operational resilience looks like in practice. The next post focuses on DORA’s testing mandate specifically: what TLPT under Article 26 actually requires, who it applies to, and why the assumption that your existing penetration testing program already covers it is one of the most costly misconceptions in the market right now.