The Digital Operational Resilience Act — Regulation (EU) 2022/2554, universally shortened to DORA — has applied since 17 January 2025. The compliance date is behind us. The supervisory phase is not.
What has changed in the eighteen months since application is the nature of the question. In 2024 the question was "are we in scope and what do we need to build?" In 2026 it is "show me the evidence." That is a different exercise, and firms that treated DORA as a documentation project are discovering the gap.
What DORA Actually Is
DORA is a regulation, not a directive. It applies directly in every EU member state without national transposition, which is the single most important structural fact about it. There is no local implementing act to soften the edges, and there is no meaningful scope for national divergence in the primary text.
It applies to roughly twenty categories of financial entity — credit institutions, payment and e-money institutions, investment firms, insurance and reinsurance undertakings and intermediaries, institutions for occupational retirement provision, crypto-asset service providers, crowdfunding providers, trade repositories, central counterparties, and more. It also reaches, through a distinct oversight regime, ICT third-party service providers designated as critical.
The obligations organise into five pillars:
| Pillar | Core obligation | Where firms typically fall short |
|---|---|---|
| ICT risk management | Documented framework, board-approved, reviewed at least annually | Framework exists; asset and dependency mapping does not |
| Incident management | Classify, report major incidents on a three-report timeline | Classification thresholds untested against real incidents |
| Resilience testing | Risk-based programme; TLPT for designated entities | Testing scope not tied to critical or important functions |
| Third-party risk | Register of information, contractual minimums, exit plans | Registers assembled once and never maintained |
| Information sharing | Voluntary threat-intelligence arrangements | Rarely a supervisory issue; low priority |
The Proportionality Trap
DORA is explicitly proportionate. Article 4 requires entities to implement the rules taking into account their size, overall risk profile, and the nature, scale and complexity of their services. A simplified ICT risk management framework is available to certain smaller entities.
Proportionality is not a discount. It is a shift in burden. A firm claiming a lighter framework has to be able to explain, on the record, why its profile justifies that position — which requires exactly the risk assessment the lighter framework was supposed to avoid. In practice, the smallest firms that handle proportionality well do a serious, short assessment once and refresh it annually. The ones that handle it badly assert proportionality in a policy sentence and have nothing behind it.
Critical or Important Functions: The Load-Bearing Definition
Almost every calibrated obligation in DORA hangs off one concept: the critical or important function. Testing scope, third-party contractual requirements, exit planning depth, incident classification — all of it scales from this determination.
A function is critical or important where a disruption would materially impair financial performance, or the soundness or continuity of services and activities, or where discontinuation, defect or failure would materially impair continued compliance with authorisation conditions and obligations.
Two failure modes recur. The first is over-inclusion: every system is critical, so the register is unusable and the testing programme is unaffordable. The second is under-inclusion driven by cost: functions are quietly excluded because including them would trigger contractual renegotiation with an incumbent provider. The second is the one that fails supervisory review, because the determination logic is either undocumented or visibly reverse-engineered from the desired answer.
Document the determination as a decision, with the criteria applied, the evidence considered, and the dissenting view where there was one. A file that records reasoning survives challenge; a file that records only conclusions does not.
What Supervisors Are Asking For
Across national competent authorities, the recurring requests are consistent and unglamorous:
- The ICT asset inventory, with dependencies mapped to business functions — not a CMDB export, a mapping.
- The register of information, with evidence of maintenance since the last submission.
- Incident classification decisions for incidents that were assessed and found non-major, not just the ones reported.
- Board minutes showing substantive ICT risk discussion, with challenge recorded.
- Exit plans for critical or important outsourced functions that have been tested or at least walked through.
Notice that four of the five are evidence of an ongoing process rather than a document. That is the shift from build to supervision.
Where DORA Sits Against Everything Else
DORA does not sit alone. It overlaps with NIS2 for entities in scope of both, with the EBA and EIOPA outsourcing guidelines it partly absorbs, and with the UK operational resilience regime for groups operating on both sides of the Channel. Treating each as a separate programme duplicates effort and produces inconsistent registers. The cluster article on DORA versus NIS2 and the UK regime sets out how to run one control set against three rulebooks.
Key Takeaways
- DORA is a directly applicable regulation; there is no national implementing act to negotiate against.
- The critical-or-important-function determination is load-bearing — almost every scaled obligation depends on it, and the reasoning must be documented.
- Proportionality shifts the evidential burden rather than removing it.
- Supervisory focus in 2026 is on evidence of ongoing process, not on the existence of policy documents.
- The five pillars are interdependent: registers feed testing scope, testing feeds incident readiness, incidents test classification thresholds.
Frequently Asked Questions
Does DORA apply to firms outside the EU? Not directly, but it reaches them in two ways. An EU subsidiary or branch of a non-EU group is in scope in its own right, and a non-EU ICT provider serving EU financial entities will be pulled into DORA-compliant contractual terms by its clients — and, if designated critical, into direct oversight.
Is a single group-wide DORA framework acceptable? Yes, and it is usually the right design, provided each in-scope legal entity's management body has approved it and can demonstrate entity-specific application. A group framework that no local board has meaningfully considered is a common finding.
How often must the ICT risk management framework be reviewed? At least annually, and additionally upon major ICT-related incidents and following supervisory instructions or findings from resilience testing. The trigger-based reviews are the ones firms most often omit.
About the author
Jonas Mohamed Osman Abdelghafour is a risk and compliance expert advising banks, insurers, payment institutions and asset managers on operational resilience, ICT and third-party risk, financial crime and enterprise governance across EU and UK regimes. He works at the point where digital operational resilience obligations meet the evidence a board and a supervisor actually ask for. See qualifications and services, or get in touch to discuss an engagement.
*This article discusses regulatory frameworks in general terms and is not legal advice. Jurisdictional interpretation should be confirmed with qualified counsel.*
Frequently asked questions
What DORA Actually Is?
DORA is a regulation, not a directive. It applies directly in every EU member state without national transposition, which is the single most important structural fact about it. There is no local implementing act to soften the edges, and there is no meaningful scope for national divergence in the primary text.
What should risk leaders know about the Proportionality Trap?
DORA is explicitly proportionate. Article 4 requires entities to implement the rules taking into account their size, overall risk profile, and the nature, scale and complexity of their services. A simplified ICT risk management framework is available to certain smaller entities.
What should risk leaders know about critical or Important Functions: The Load-Bearing Definition?
Almost every calibrated obligation in DORA hangs off one concept: the critical or important function. Testing scope, third-party contractual requirements, exit planning depth, incident classification — all of it scales from this determination.
What Supervisors Are Asking For?
Across national competent authorities, the recurring requests are consistent and unglamorous:
Where DORA Sits Against Everything Else?
DORA does not sit alone. It overlaps with NIS2 for entities in scope of both, with the EBA and EIOPA outsourcing guidelines it partly absorbs, and with the UK operational resilience regime for groups operating on both sides of the Channel. Treating each as a separate programme duplicates effort and produces inconsistent registers. The cluster article on [DORA versus NIS2 and the UK regime](/insights/dora-vs-nis2-uk-operational-resilience) sets out how to run one control set against three rule...