When a faulty CrowdStrike update froze roughly 8.5 million Windows devices in July 2024, banks and payment platforms discovered that an ICT dependency they never contracted with directly could still take them offline. That is exactly the systemic fragility DORA now makes a legal obligation to manage. If you already run a business continuity programme, DORA compliance is less a rebuild than an alignment exercise, and the firms that treat it as a cybersecurity checkbox are the ones that will struggle in an examination.
The rest of this guide unpacks what DORA actually requires, who it captures, the deadlines that start running the moment an incident is classified, and how to map your existing business impact analyses and plans onto its five pillars.
What is DORA compliance?
DORA compliance means meeting the legally binding requirements of the Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied directly across all member states since 17 January 2025. It requires financial entities to prove they can withstand, respond to, and recover from information and communication technology (ICT) disruptions, treating operational resilience as a board-level duty.
That definition matters because DORA does not behave like a directive. It needs no national transposition. The obligations land identically in Frankfurt, Dublin, and Milan, and the full text of Regulation (EU) 2022/2554 runs to 64 articles across six operative chapters.
DORA at a glance: purpose and legal status
DORA sits inside the EU's wider digital finance package. The official EUR-Lex summary confirms it has applied since 17 January 2025 and is scheduled for review by 17 January 2028. Its stated goal is narrow and specific: ensure that entities central to the financial system can keep operating through ICT disruption, whatever the trigger.
Because it is a regulation and not a directive, there is no grace period hidden in national law. A firm in scope was expected to be compliant on day one. That is a different posture from the phased implementation windows practitioners were used to under earlier operational-risk regimes.
Why DORA raises the bar beyond a cybersecurity checkbox
DORA reframes ICT risk as a cross-functional, board-accountable discipline rather than an IT problem to be delegated downward. The requirements are given teeth by a body of regulatory and implementing technical standards (RTS and ITS) developed jointly by the European Supervisory Authorities; the EBA's DORA hub hosts the full set covering the ICT risk framework, incident classification, the register of information, and threat-led testing.
The scale of what is in scope is now measurable. The first annual ESA report recorded 3,383 major ICT-related incidents across EU financial sectors in 2025, an average of 0.18 per entity subject to the regulation. That number is not a projection. It is the reporting baseline supervisors will use to judge whether your incident volumes look plausible.
DORA is one strand of the EU's compliance and regulatory resilience agenda, sitting alongside cyber and critical-infrastructure law that overlaps at the edges.
Who must comply with DORA
DORA's scope is unusually broad. It captures the obvious financial entities and, for the first time in EU law, the critical ICT providers those entities depend on. Proportionality softens the burden for the smallest firms without exempting them.
The 20 categories of financial entities
Article 2 of DORA sets out the scope, and ESMA confirms the regulation reaches 20 categories of financial entities in the ESA remit. Banks, insurers and reinsurers, investment firms, payment and e-money institutions, crypto-asset service providers, trading venues, and central securities depositories are all captured.
Size is not an escape hatch. A small payment institution is in scope; the intensity of what it must do scales with its risk profile, but the obligation itself does not disappear. Non-EU providers serving EU entities are pulled in indirectly through the contractual requirements their EU clients must impose.
Critical ICT third-party providers (CTPPs)
The genuinely new machinery is the oversight regime for critical ICT third-party providers. Under Article 31, the ESAs designate cloud, data, and infrastructure providers whose failure would ripple across the financial system, and each designated provider is assigned a Lead Overseer with examination powers.
In November 2025 the ESAs designated the first 19 Critical ICT Third-Party Providers. That designation matters to in-scope firms too: it tells you which of your dependencies now sit under direct European supervision, and where concentration risk is most acute.
Proportionality and the simplified framework
Proportionality is written into the regulation. Article 4 scales obligations to an entity's size, risk profile, and the nature of its services, and microenterprises may follow the simplified ICT risk management framework set out in Articles 15 and 16.
Do not mistake proportionality for a carve-out. A microenterprise still needs a documented framework, still reports major incidents, and still manages its ICT contracts. The simplified route reduces the depth of the paperwork, not the existence of the duty.
The Five Pillars of DORA Requirements
DORA's obligations are organised into five interlocking pillars that trace the whole ICT risk lifecycle, from governance through to recovery and information exchange. Each pillar maps to a specific chapter and article range, which is useful when you need to locate an obligation precisely rather than argue about it in the abstract. This structure also underpins the DORA five pillars breakdown many teams use as a working reference.
Pillar 1: ICT risk management (Articles 5-16)
Chapter II, Articles 5 to 16, requires a documented ICT risk management framework owned by the management body. It spans identification, protection and prevention, detection, response and recovery, and learning.
The accountability point is sharp. The framework belongs to the board, not the CISO's inbox. Personal responsibility for the ICT risk framework is not delegable to the IT function, which is a marked shift for firms used to treating this as a technical control set.
Pillar 2: ICT-related incident reporting (Articles 17-23)
Chapter III, Articles 17 to 23, requires firms to classify incidents against materiality thresholds and report major ones to their competent authority using harmonised templates and time limits. The data feeds the annual ESA incident report referenced above.
Harmonisation is the practical gain here. Before DORA, a cross-border group could face several incident-reporting regimes with different clocks. The single set of templates and deadlines reduces that duplication, though it also raises the floor for what counts as an acceptable notification.
Pillar 3: Digital operational resilience testing (Articles 24-27)
Chapter IV, Articles 24 to 27, sets a baseline testing duty for every entity and a more demanding threat-led penetration testing (TLPT) obligation for significant entities. Baseline testing covers vulnerability assessments, scenario-based tests, and reviews of ICT tools. TLPT simulates real adversary behaviour against live systems.
Pillars 4 and 5: Third-party risk (Articles 28-44) and information sharing (Article 45)
Chapter V, Articles 28 to 44, requires full lifecycle management of ICT third-party contracts, including mandatory contractual clauses, exit strategies, and the register of information, and it establishes the CTPP oversight regime. Chapter VI, Article 45, provides for voluntary cyber threat intelligence sharing between entities.
The third-party pillar is where most mature BCM programmes have the largest gap, because supplier registers built for procurement rarely carry the contractual and concentration data DORA expects.
DORA Incident Reporting: Classification and Time Limits
Incident reporting is where programmes stumble, because the clocks start running fast and they run against the moment of classification, not the moment you finish your root-cause analysis. Getting the thresholds and deadlines right is a discipline you rehearse before you need it, not something you improvise at 2am.
Classifying a major incident
The materiality thresholds sit in Commission Delegated Regulation (EU) 2024/1772, which specifies the criteria — clients and counterparties affected, data losses, duration and downtime, geographical spread, economic impact, and criticality of services affected. The same RTS distinguishes a major incident from a significant cyber threat, which carries a lighter, voluntary notification path.
Reporting is standardised across the EU through the templates in Commission Implementing Regulation (EU) 2025/302. Using them well means your classification logic has to be wired into detection, not bolted on afterwards.
The reporting clock: 4 hours, 24 hours, 72 hours, one month
The joint ESA technical standards on major incident reporting set the deadlines, deliberately aligned with NIS2 to cut duplicate filings. The reporting RTS, Regulation (EU) 2025/301, specifies what each report must contain.
| Report | Deadline | Trigger |
|---|---|---|
| Initial notification | 4 hours after classification, and no later than 24 hours after detection | Incident classified as major |
| Intermediate report | 72 hours | After initial notification, or on material status change |
| Final report | 1 month | After the incident is resolved and root cause is known |
Consider how that clock would have run in the field. When LockBit ransomware hit ION Group's Cleared Derivatives division on 31 January 2023, the attack affected 42 clients and forced European and US banks and brokers to process derivatives trades manually, and a major futures exchange delayed settlement. Under DORA, the affected in-scope firms would have been classifying, notifying within hours, and filing an intermediate report inside three days — all while running manual fallback. The lesson practitioners take from ION is that your notification workflow has to function when your primary systems, and a critical vendor, are simultaneously down.
Resilience Testing and the TIBER-EU Framework
DORA mandates a tiered testing regime, and the top tier is threat-led penetration testing for the most significant institutions. Understanding where the baseline duty ends and TLPT begins is the difference between a proportionate testing programme and an over-engineered one.
Baseline testing versus TLPT
Every entity must run a regular ICT testing programme under Articles 24 to 27. TLPT is reserved for entities identified by their supervisors as significant enough to warrant it, and it simulates genuine adversary tactics against production systems rather than test environments.
That distinction is where firms misjudge scope. Not every regulated entity needs TLPT. Assuming you do, and building for it prematurely, burns budget you could spend closing baseline gaps.
How TIBER-EU aligns with DORA TLPT
The ECB updated its TIBER-EU framework in February 2025 to align with the DORA TLPT technical standards, and the wider TIBER-EU framework sets out the threat-intelligence, red-teaming, and reporting phases. In November 2025 the ECB published an SSM implementation guide setting supervisory expectations for significant institutions under Articles 26 and 27.
The practical takeaway: if you already run TIBER-aligned red-team exercises, you are most of the way to the DORA testing expectation. If you do not, TLPT is not something you stand up in a quarter.
How DORA Relates to BCM, ISO 22301, and NIS2
DORA does not exist alone. It sits over established business continuity practice and alongside overlapping EU cyber law, and untangling the relationships is essential to avoid either double-work or gaps.
DORA and NIS2: the lex specialis principle
DORA is lex specialis for the financial sector. Where DORA's requirements are more specific than the NIS2 Directive (EU) 2022/2555, DORA takes precedence for the entities it covers. NIS2 remains the baseline for the other critical sectors it addresses, and the European Commission's NIS2 page tracks its transposition status.
For a financial group with mixed activities, the practical job is mapping which entity falls under which regime. Get that wrong and you either report twice or miss an obligation entirely.
Where ISO 22301 and BCM fit
Business continuity is a holistic process. It begins with a business impact analysis, informs the development of business continuity plans and recovery strategies, and helps an organisation keep critical operations running during and after disruption. DORA extends that discipline into ICT-specific and third-party dimensions; it does not retire the BIA.
ISO 22301:2019 is the reference point here. Clause 8 — covering the BIA, continuity strategies, and plans maps directly onto DORA's recovery objectives, and a well-run ISO 22301 business continuity management system gives you most of the artefacts DORA asks to see. The firms treating DORA as a fresh start are the ones ignoring the continuity work they already have.
The same logic applies to firms operating across jurisdictions. If you already meet FCA operational resilience requirements in the UK or run an APRA CPS 230 operational risk programme in Australia, the underlying discipline transfers even though the specific clauses differ.
Aligning your BCM programme with DORA
For a firm with a mature BCM programme, DORA is an alignment and extension exercise, not a ground-up build. This section moves from the inputs you already hold, through the analytic steps, to the artefacts and decisions a supervisor expects to see.
See how Fortiv is tailored for financial institutions who meet DORA
Inputs: existing BIAs, BCPs, and third-party inventories
Start with what you have. Your current BIA outputs and recovery time objectives, your supplier and cloud contract inventories, your incident logs, and your testing evidence are the raw material for the ICT risk framework under Articles 5 to 16.
Most programmes find the BIA data is strong and the third-party data is weak. Procurement inventories tell you who you pay. They rarely tell you which supplier underpins which critical function, or where two nominally separate vendors share the same underlying cloud region.
Analytic steps: mapping artefacts to the five pillars
Here is a workable sequence for a mid-market firm mapping its existing programme onto DORA:
- Inventory every BIA and BCP artefact and tag each to the pillar it supports.
- Identify the critical or important functions those artefacts protect.
- Map each function to the ICT services and third parties it depends on.
- Build the register of information required under Article 28(3), capturing every contractual arrangement for ICT services.
- Assess concentration risk under Article 29, flagging where several critical functions rest on one provider.
- Gap-analyse each pillar against the evidence you can actually produce today.
- Prioritise remediation by function criticality, not by ease.
A firm running this exercise typically discovers that its BIA already answers most of Pillar 1's questions, while the register and concentration analysis are net-new work. That is the shape of the effort: extend, do not replace. Robust critical dependency identification is usually the load-bearing step here.
Artefacts and decisions: the evidence supervisors expect
The deliverables a supervisor will look for are concrete: an ICT risk framework document, a current register of information, a documented testing programme, incident procedures, and contract remediation decisions including exit strategies under Articles 28 to 30. Board sign-off is the accountability record that ties it together.
Maintaining a live register by hand across hundreds of contracts is where teams drown. This is where AI-assisted tooling earns its place parsing contracts to populate register fields, flagging where a mapped dependency has no exit clause, and surfacing concentration before it becomes a finding. The Business Continuity Institute's 2025 Horizon Scan found cyber security rated the top long-term concern at 63.6%, with AI governance emerging at 30.5% — practitioners are adopting the tools and worrying about governing them at the same time. Whichever way you tool it, the register has to be submission-ready, not reconstructed in a panic before an examination.
Sector Nuance: Banking, Payments, and Insurance
DORA lands differently across financial sub-sectors. Banking and payments carry the heaviest concentration and third-party exposure; insurance faces its own data and outsourcing pressures. The practical pressure points are not evenly distributed.
Banking and payments: concentration and manual fallback
The credit and payments sectors reported the majority of the 3,383 major incidents logged in 2025. Heavy reliance on a small number of shared ICT providers creates systemic concentration risk, and manual fallback plans get tested for real when a common dependency fails.
That is precisely what the CrowdStrike outage on 19 July 2024 demonstrated. A faulty Falcon sensor content update pushed to Windows endpoints sent roughly 8.5 million machines into boot loops. Recovery required manual intervention on each affected device. Banks could not process transactions, some individuals did not receive pay, and the fault sat with a vendor most affected firms had no direct contract with. DORA's third-party pillar exists to make exactly that dependency visible and contractually governed before it fails.
Lessons from operational resilience failures
Older incidents still earn their place when they illustrate the same lesson. TSB's 2018 platform migration is the canonical example of inadequate operational resilience: the migration caused immediate technical failures affecting all branches and 5.2 million customers, disruption persisted for months, and the FCA and PRA jointly fined TSB £48.65m in December 2022, with total incident costs exceeding £330 million. The PRA framed it as an operational resilience failing, not merely a technology one.
TSB shows the cost of botched change management inside your own estate; CrowdStrike shows the cost of a dependency outside it. DORA targets both, which is why testing and third-party oversight are the two pillars firms cannot treat lightly.
DORA penalties and how to prepare for an assessment
Non-compliance carries real financial and personal consequences, and supervisors are already exercising oversight powers over designated providers. Knowing the enforcement regime is the motivation; a disciplined readiness path is the response.
Penalties and enforcement
National competent authorities set administrative penalties for financial entities, while critical ICT third-party providers face a distinct regime. Under Article 35(6) of DORA, a Lead Overseer can impose periodic penalty payments of up to 1% of the provider's average daily worldwide turnover, applied daily for up to six months, to compel compliance. The management body of a financial entity remains personally accountable for the ICT risk framework.
Demonstrating readiness for a DORA assessment
Demonstrating readiness comes down to evidence you can produce on demand:
- Maintain a live evidence pack mapping each control to its article and the relevant RTS or ITS.
- Keep the register of information current and submission-ready.
- Run and document testing cycles on schedule.
- Rehearse the incident notification timeline against the 4-hour, 72-hour, and one-month deadlines.
- Record board review and sign-off as the accountability trail.
The EBA's technical standards hub is the source of truth for what each control must contain. The gap most self-assessments leave open is specificity: reference the actual article and RTS, not a generic checklist, because that is the level at which an examiner will engage.
Discover how Fortiv's operational resilience solutions help financial services teams align their BCM programme with DORA's ICT risk requirements →
