If your organization touches financial services in the EU, or provides technology to one that does, there is a regulation on your radar right now that you cannot afford to misread. The Digital Operational Resilience Act (DORA), formally known as Regulation (EU) 2022/2554, became fully enforceable on January 17, 2025. No phase-in period. No grace period for stragglers. Just a hard deadline followed by active enforcement from national regulators across all 27 EU Member States.
The good news: a structured gap analysis is your clearest path from “not sure where we stand” to “audit-ready and confident.” I will walk you through exactly how to run one.
What Is DORA, and Who Does It Apply To?
DORA is an EU regulation that establishes a single, harmonized framework for digital operational resilience across the financial sector. Before it existed, operational resilience requirements were fragmented across member states and sector-specific rules, leaving firms exposed in inconsistent and unpredictable ways.
Today, DORA applies to over 22,000 financial entities and Information and Communications Technology (ICT) service providers operating in the EU. The scope is wider than most people expect. It covers banks, insurers, investment firms, payment institutions, electronic money institutions, crypto-asset service providers, crowdfunding platforms, and more — 20 categories of financial entity in total. Critically, it also reaches non-EU ICT providers if their services are critical to EU-based financial institutions. A cloud provider headquartered in the US serving a Frankfurt bank? DORA applies.
The regulation is built around five core pillars. Understanding them is the foundation of any gap analysis.
| DORA Pillar | Regulation Chapter | Key Focus |
|---|---|---|
| ICT Risk Management | Chapter II (Articles 5–16) | Governance, risk frameworks, business continuity |
| Incident Reporting | Chapter III (Articles 17–23) | Classification, timelines, reporting to authorities |
| Resilience Testing | Chapter IV (Articles 24–27) | Vulnerability assessments, threat-led penetration testing |
| Third-Party Risk Management | Chapter V (Articles 28–44) | Vendor oversight, contracts, exit strategies |
| Information Sharing | Article 45 | Voluntary cyber threat intelligence exchange |
What Is a DORA Gap Analysis?
A gap analysis is a structured assessment that compares your organization’s current ICT risk management practices against what DORA actually requires. Think of it as holding your existing documentation, processes, and controls up to each article of the regulation and asking: “Does what we do today meet this standard? If not, how far off are we?”
The output is a prioritized list of compliance gaps, paired with a remediation roadmap. It is not a one-time checkbox exercise. DORA’s Article 6 requires that your ICT risk management framework undergo regular internal auditing, with formal follow-up processes for findings. The gap analysis is the starting point for that ongoing discipline.
Here is why getting it right early matters: non-compliance carries fines of up to 2% of total annual worldwide turnover for financial entities, plus personal liability for board members of up to EUR 1,000,000. Critical ICT third-party providers face separate penalties reaching EUR 5,000,000, with daily fines of up to 1% of average daily worldwide turnover for continued non-compliance. Public disclosure of breaches is also on the table, which means reputational damage that outlasts any fine.
How to Run a DORA Gap Analysis: Five Practical Steps
Step 1: Establish Your Scope and Entity Profile
Before you assess anything, you need to know exactly which DORA requirements apply to your organization. DORA applies the proportionality principle: Article 4 explicitly states that requirements under Chapters III, IV, and V scale to an entity’s size, risk profile, and the nature and complexity of its operations. Microenterprises, for example, face a simplified ICT risk management framework under Article 16.
Start by documenting your entity type, your total assets under management, and your dependency on third-party ICT services. This profile shapes which articles are mandatory for you and at what depth.
Step 2: Map Your Current ICT Risk Management Framework
Pillar One is where most organizations discover their biggest gaps. DORA’s Article 5 places direct accountability on the management body, which must bear ultimate responsibility for ICT risk, set clear roles for ICT functions, and maintain sufficient knowledge to understand and assess ICT risk. If your board cannot articulate your ICT risk tolerance level, that is a gap.
Under Article 8, financial entities must identify, classify, and document all ICT-supported business functions, information assets, and dependencies. This mapping must be reviewed at least annually. Pull your existing asset registers and business continuity plans, then test them against that standard. Gaps here often reveal missing documentation, outdated classifications, or no formalized recovery time and recovery point objectives (RTOs and RPOs) for critical functions.
Step 3: Assess Incident Management Readiness
Chapter III of DORA requires that you have mechanisms in place to detect, classify, escalate, and report ICT-related incidents within defined timeframes. There are three reporting stages: an initial notification, an intermediate report, and a final report, each with specific timelines set by the European Supervisory Authorities (EBA, EIOPA, and ESMA).
When assessing this pillar, review whether your current incident response procedures align with DORA’s classification taxonomy for major incidents. Ask whether your team knows the difference between a significant cyber threat (voluntary notification) and a major ICT incident (mandatory reporting). If the answer is “sort of,” that is a gap that needs closing before a real incident forces the answer.
Step 4: Review Resilience Testing Coverage
DORA’s Chapter IV introduces a two-tier testing regime. Basic testing covers vulnerability assessments, network security assessments, and scenario-based tests. Advanced testing requires Threat-Led Penetration Testing (TLPT) for significant financial entities. TLPT simulates real-world adversary behavior against your live systems and must involve your critical ICT third-party providers.
Conduct an inventory of your current testing activities. Map them to the DORA testing categories and note where coverage is missing or where test frequency falls short. Pay particular attention to whether your disaster recovery and business continuity tests actually simulate DORA-defined extreme scenarios, including ICT failures caused by third-party outages.
Step 5: Audit Third-Party ICT Contracts
Pillar Four is frequently the most labor-intensive part of any gap analysis, and the one most organizations underestimate. Chapter V requires that every contractual arrangement with a third-party ICT provider for critical or important functions include specific provisions: defined service levels, audit rights, termination rights, data security requirements, and documented exit strategies.
You will need to build or verify your Register of Information (RoI), a mandatory register of all ICT third-party service provider arrangements. The deadline for submitting RoI data to national competent authorities was April 30, 2025. If your register is incomplete, patchy, or missing key contractual terms, that is a gap with an active regulatory clock attached.
Common Gaps Found Across Financial Entities
Based on the pattern of supervisory focus emerging across EU Member States in 2025 and 2026, the most common gaps fall into three clusters.
- Governance accountability. Boards that have delegated ICT risk entirely to technology teams, without maintaining demonstrable knowledge and oversight of their own, fail Article 5. Senior management training logs and board-level ICT risk reporting packs are the evidence regulators want to see.
- Incomplete third-party mapping. Many organizations have contracts with dozens of ICT sub-contractors that they have never formally assessed against DORA’s concentration risk standards. Article 28 requires not just oversight of your direct providers but an understanding of the wider supply chain dependency.
- Untested recovery capabilities. Having a business continuity plan on paper is not the same as a tested, functioning one. DORA requires documented evidence of testing outcomes, including lessons learned and formal remediation tracking.
Turning Gap Analysis Into a Remediation Roadmap
Once your gap analysis is complete, organize findings by pillar and score them against two dimensions: regulatory severity and implementation effort. A gap in incident reporting timelines (high severity, moderate effort) ranks above a missing RTO documentation for a non-critical system (moderate severity, low effort) in most cases.
Build a quarterly roadmap that covers at least 12 months. Assign ownership at a named individual level, not a team level. Regulators conducting enforcement reviews increasingly expect to see traceable accountability for each remediation action.
Keep the roadmap a live document. DORA’s internal audit requirement under Article 6 means your gap analysis is not a one-time project but the baseline for continuous compliance monitoring.
A Final Word
DORA is not designed to punish organizations that are genuinely working toward resilience. It is designed to ensure that working toward resilience is the default posture of every financial entity operating in Europe. A well-run gap analysis is the most practical signal you can send, to regulators and to your own leadership, that you take that posture seriously.
If you are starting your DORA gap analysis today, begin with scope definition and the Pillar One governance review. Those two steps will surface the highest-priority findings fastest, and they will set the tone for everything that follows.
