DORA — the EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554 — is enforceable law requiring financial firms operating in the EU to manage ICT risk with the same rigor they apply to financial risk. It applies to a defined set of financial entities and their critical technology providers, has been fully applicable since January 17, 2025, and is organized around five pillars: ICT risk management, incident reporting, resilience testing, third-party ICT risk, and voluntary information sharing.
If you’re a continuity or resilience leader being asked “are we DORA compliant?” — or evaluating firms selling “DORA compliance services” — this guide covers what the regulation demands, what’s enforceable now, what good support looks like, and how DORA maps to your ISO 22301 / FFIEC program.
Does DORA apply to us?
DORA applies to financial entities operating in the EU — a defined list that includes credit institutions, payment and e-money institutions, investment firms, insurers and reinsurers, crypto-asset service providers, central securities depositories, trading venues, and others. If your firm is regulated as a financial entity in any EU member state, assume DORA applies until you’ve confirmed otherwise with legal counsel.
Two groups outside the EU should still pay attention. First, third-country firms serving EU clients: DORA’s expectations follow the regulated activity. Second, ICT providers to financial entities: DORA reaches you through your customers. Their contracts with you must contain specific provisions (Article 30), you must be listed in their register of ICT third-party providers (Article 28), and if you’re designated a Critical ICT Third-Party Provider (CTPP), you fall under direct EU-level oversight by a Lead Overseer from one of the European Supervisory Authorities (EBA, ESMA, or EIOPA).
The regulation is proportionate by design. Microenterprises get a simplified ICT risk management framework (Article 16), and testing intensity scales with the firm’s risk profile. Proportionality is not an exemption — it calibrates how much of the framework applies, not whether it does.
What are the five pillars?
DORA’s requirements cluster into five areas. A compliance program that doesn’t address all five has a gap by construction.
1. ICT risk management (Articles 5–16). The foundation. Financial entities must maintain a sound, comprehensive, well-documented ICT risk management framework: risk identification, protection and prevention, detection, response and recovery, and learning and evolving. The management body holds ultimate responsibility — this is a board-level obligation, not a delegation to IT. Key artifacts include the ICT risk management policy, business impact analyses for ICT-supported functions, and an ICT business continuity policy with response and recovery plans that are tested and maintained.
2. ICT-related incident management, classification, and reporting (Articles 17–23). Firms must classify ICT incidents against defined criteria and report major incidents on a fixed clock: an initial notification within 4 hours of classification (and no later than 24 hours from awareness), an intermediate report within 72 hours, and a final report within one month. The classification decision and its timestamp are a regulated artifact — your criteria and decision process must be defined before the incident, not improvised during it. Article 19(3) separately requires informing clients without undue delay when a major incident affects their financial interests.
3. Digital operational resilience testing (Articles 24–27). A risk-proportionate testing program covering vulnerability assessments, network security assessments, scenario-based testing, and — for firms designated as significant — threat-led penetration testing (TLPT) conducted at least every three years. TLPT is red-team testing against live production systems under a controlled framework, and it’s the most demanding item in the pillar. The testing program must produce findings, and findings must produce remediation with tracked closure. A test that finds nothing and changes nothing is a compliance artifact, not a resilience program.
4. Managing ICT third-party risk (Articles 28–44). Before signing a contract, firms must assess the risk of the ICT arrangement; contracts must contain the full set of required provisions (Article 30), including audit rights, security requirements, and exit provisions; and firms must maintain a register of information on all ICT third-party service providers, distinguishing those supporting critical or important functions. Concentration risk must be assessed — where multiple critical functions depend on one provider, or providers share common subcontractors, that dependency is itself a risk to manage. At the EU level, the most systemically important providers are designated as CTPPs subject to direct oversight: the ESAs published the first list of 19 designated providers in November 2025, including the major cloud hyperscalers, market-data providers, and large systems integrators. Non-compliance at the CTPP level can draw periodic penalty payments of up to 1% of average daily worldwide turnover.
5. Information sharing (Article 45). Voluntary cyber-threat intelligence sharing within trusted communities. The only explicitly voluntary pillar — but supervisors notice who participates, and sharing firms tend to detect faster.
What should DORA compliance services actually deliver?
The search term that brings buyers here — “DORA compliance services” — covers an enormous range of offerings, from serious programs to rebadged gap analyses. Here’s what a credible engagement actually contains, pillar by pillar. Use it as a scope checklist when evaluating proposals.
Gap assessment against the five pillars. The starting point is a structured assessment of your current state against each pillar’s requirements — not a generic “maturity score,” but a requirement-by-requirement mapping with evidence. Demand to see the requirement list they assess against. If it doesn’t reference specific DORA articles and the relevant technical standards (the RTS/ITS on incident reporting, the register of information, contractual provisions), it’s a vibes exercise.
ICT risk management framework build or uplift. Policies, the ICT risk management strategy, integration with your enterprise risk framework, and the management-body governance artifacts — what the board approves and what it receives. Board accountability is the point.
Incident classification and reporting process. This is where most firms are weakest. The deliverable: documented classification criteria aligned to the regulatory thresholds, a decision workflow that starts the 4-hour clock on time, reporting templates matching the ITS formats, and at least one exercised run-through. Ask the provider when they last ran a classification drill with a client. If the answer is vague, move on.
Resilience testing program. A multi-year testing plan proportionate to your risk profile, including TLPT scoping where applicable. For TLPT, confirm the provider understands the TIBER-EU-derived framework expectations and has actually run threat-led tests in financial services — generic pen-test shops are not the same thing.
Third-party register and concentration-risk work. Building the register of information is laborious data work: every ICT provider, every arrangement, mapped to critical or important functions, with contract reviews against Article 30 provisions. Then the concentration analysis on top. This is the engagement component most worth paying for, because it’s the one firms consistently underestimate. Ask how many registers the provider has built and what their data model looks like.
Remediation tracking. Findings without tracked closure are decoration. The program should include a remediation register with owners, dates, and evidence of completion — verified by the provider, not self-attested.
Red flags in providers. Walk away from: fixed-price “DORA certification” (no such scheme exists for financial entities); assessments that never look at your actual contracts; testing programs with no TLPT capability sold as “DORA testing”; and any provider that can’t name the articles behind their checklist. Serious providers talk in articles and evidence. Weak ones talk in maturity levels.
How does DORA map to ISO 22301 and FFIEC expectations?
If you already run an ISO 22301-aligned business continuity program or operate under FFIEC business continuity expectations, you’re not starting from zero — but DORA is not a relabeling of either.
Where they overlap. Your BIA work, recovery strategies, and exercise program map directly onto DORA’s ICT risk management and testing pillars. FFIEC’s business continuity examination expectations — governance, risk assessment, business impact analysis, testing, and third-party management — rhyme with DORA’s structure. A mature program under either framework already produces many of the artifacts DORA requires.
Where DORA goes further. Three differences matter. First, the reporting clock: neither ISO 22301 nor FFIEC imposes a 4-hour regulatory notification with a classification timestamp as a compliance artifact. Second, contractual specificity: Article 30’s required contract provisions and the register of information go well beyond typical third-party risk management — your existing vendor inventory almost certainly isn’t sufficient. Third, direct oversight of your providers: the CTPP regime means your most critical vendors are supervised by EU authorities directly, and your program has to account for what that oversight does and doesn’t cover. It doesn’t replace your own due diligence.
The practical mapping exercise. The highest-value first step is a mapping table: each DORA requirement, the existing control or artifact that satisfies it, and the gap. In most firms, ICT risk management and testing map cleanly, incident reporting needs a rebuild, and third-party risk needs the most new work. Do the mapping before buying anything — it tells you exactly which provider services you actually need.
What’s enforceable right now?
As of 2026, DORA is live law, and the supervisory machinery around it is operating:
- Full application since January 17, 2025. All five pillars are in force for in-scope financial entities.
- Incident reporting is active. Competent authorities are receiving major-incident notifications on the 4-hour/72-hour/one-month clock.
- Registers of information are filed. Financial entities submitted their ICT third-party registers; supervisors are using them to assess concentration risk across the sector.
- CTPP oversight is underway. The first 19 critical providers were designated in November 2025 and are now subject to Lead Overseer supervision, including examinations and recommendations.
- National penalties apply. Member states have set penalties for non-compliance by financial entities; these are national-law instruments, so the specific exposure depends on your competent authority’s regime.
If your program still treats DORA as a 2025 project that got extended, that framing is two years out of date. Supervisors have moved from “are you preparing?” to “show me the evidence.”
FAQ
Is DORA the same as NIS2? No. NIS2 (Directive (EU) 2022/2555) is the horizontal cybersecurity directive covering essential and important entities across sectors; DORA is the sector-specific regulation for financial services. Where both could apply, DORA generally takes precedence for financial entities as the more specific regime — but confirm with counsel, because the boundary cases are real.
Does DORA apply to our US parent or only the EU subsidiary? DORA applies to the financial entity operating in the EU. In practice, group-level ICT arrangements — shared platforms, group outsourcing, centralized incident response — pull the parent’s operations into scope functionally, because the EU entity must demonstrate control over the ICT risk of everything it depends on. Most groups end up running a group-aligned DORA program.
What happens if we miss the 4-hour notification? The technical standards include a delayed-notification process — notify as soon as possible and explain the delay. A missed deadline with a documented reason is a very different supervisory conversation than one discovered in an examination. Build the delay-notice path into the procedure.
Do we need TLPT? Only if your firm is designated as subject to it — TLPT applies to financial entities meeting the significance criteria, conducted at least every three years. If you’re unsure whether you’re in scope, that’s a question for your competent authority, not your pen-test vendor.
Can one provider do our whole DORA program? They can coordinate it, but be skeptical of single-vendor soup-to-nuts offers. The testing pillar (especially TLPT) and the legal work on Article 30 contract remediation are specialist disciplines. A credible prime contractor will name their specialist subcontractors rather than claiming to do everything in-house.