Common Challenges in Meeting Dora Requirements

Last Updated on June 26, 2026 by Narendra Sahoo

When the Digital Operational Resilience Act — formally Regulation (EU) 2022/2554 — entered full application across the European Union on 17 January 2025, many financial institutions were still scrambling to understand its scope, let alone achieve compliance. By 2026, the regulatory environment has shifted dramatically: the European Supervisory Authorities (ESAs) — comprising the European Banking Authority (EBA), the European Securities and Markets Authority (ESMA), and the European Insurance and Occupational Pensions Authority (EIOPA) — are no longer offering implementation guidance and informal tolerance. Active enforcement is underway, and the consequences of falling short have never been more concrete.

The numbers tell a sobering story. According to Deloitte’s Wave 3 DORA Operational Resilience Survey, only 50% of EU financial institutions are estimated to be fully compliant as of early 2026. In the ESAs’ 2024 dry-run exercise for the Register of Information, just 6.5% of nearly 1,000 participating firms passed all 116 data quality checks. Meanwhile, 55% of financial institutions globally admitted they were not adequately prepared for DORA’s January 2025 deadline.

At VISTA InfoSec, we have led DORA gap assessments, ICT risk framework reviews, and third-party risk management programmes for EU financial entities across banking, investment management, and insurance sectors. In this guide, we break down the eight most common — and most consequential — challenges organisations face when meeting DORA requirements, along with practical steps to resolve each one.

What Is DORA, and Why Does It Matter in 2026?

The Digital Operational Resilience Act is a directly applicable EU regulation — not a directive — meaning every provision carries the same legal force across all 27 EU member states without requiring national transposition. It is designed to ensure that financial entities can withstand, respond to, and recover from all types of ICT-related disruptions and threats.

DORA is structured around five core pillars:

1. ICT Risk Management (Articles 5–16) — governance, strategy, ICT risk identification, protection, detection, response, recovery, and communication
2. ICT-Related Incident Reporting (Articles 17–23) — classification of incidents, mandatory reporting to National Competent Authorities (NCAs)
3. Digital Operational Resilience Testing, including Threat-Led Penetration Testing or TLPT (Articles 24–27)
4. ICT Third-Party Risk Management (Articles 28–44) — due diligence, contractual requirements, ongoing monitoring, Register of Information
5. Information and Intelligence Sharing (Article 45) — voluntary participation in threat intelligence sharing arrangements

In 2026, National Competent Authorities (NCAs) in each EU member state have moved beyond planning and guidance into active supervision — cross-checking Register of Information submissions automatically, issuing compulsion payments, and in some cases beginning formal enforcement proceedings.

Who Must Comply with DORA?

DORA’s scope is intentionally broad, covering more than 22,000 financial entities across the EU. These include:

• Banks and credit institutions
• Investment firms and asset managers
• Insurance and reinsurance undertakings
• Payment institutions and electronic money institutions
• Crypto-asset service providers (regulated under MiCA)
• Central securities depositories and central counterparties
• Trading venues and data reporting service providers
• Critical ICT Third-Party Providers (CTPPs) — a category with its own distinct supervisory and penalty regime

One important nuance is proportionality. DORA’s Article 4 allows microenterprises and smaller financial entities to apply a simplified ICT risk management framework. However, “simplified” does not mean “optional” — core requirements around incident reporting, third-party contracts, and basic ICT controls still apply in full.

The 8 Most Common Challenges in Meeting DORA Requirements

Challenge 1: Building and Maintaining the Register of Information (RoI)

If there is one DORA requirement that has caused more operational difficulty than any other, it is the Register of Information. According to Deloitte’s Wave 3 DORA Operational Resilience Survey, 46% of financial institutions named the RoI as the single most challenging DORA requirement. The ESAs’ 2024 dry-run confirmed exactly why: only 6.5% of nearly 1,000 participating firms passed all 116 data quality checks.

The Register of Information is a comprehensive, structured inventory of all ICT third-party service arrangements — covering direct contracts, subcontractors, and additional supporting ICT components. The most common failure points identified in the ESA dry-run include:

• Incomplete contract data and missing service level details
• Inability to identify and document subcontractor relationships beyond tier-1 vendors
• Incorrect criticality classifications for ICT services
• Inconsistent data formats and metadata across business units
• Unclear ownership of additional ICT components and supporting systems

The underlying problem is structural. Most financial institutions manage third-party contracts across multiple disconnected systems — procurement platforms, legal contract management tools, and spreadsheets — with no single source of truth. Building the Register of Information requires not just data collection, but a fundamental restructuring of how third-party relationships are documented, owned, and governed.

Practical steps to address this:

1. Appoint a dedicated RoI owner with cross-functional authority spanning procurement, legal, and IT
2. Implement a centralised contract management system capturing all mandatory DORA data fields
3. Map all subcontractor relationships for critical ICT services — not just tier-1 vendors
4. Conduct quarterly data quality reviews against the ESA’s published validation criteria
5. Align your RoI structure with the ESA’s published reporting templates to avoid dry-run failures

Challenge 2: Integrating DORA into Existing ICT Risk Management Frameworks

DORA’s ICT Risk Management requirements under Articles 5–16 are detailed and prescriptive. They require financial entities to implement a comprehensive ICT Risk Management Framework (ICTRMF) covering governance, strategy, identification, protection, detection, response, recovery, learning, evolving, and communication. For organisations already operating under ISO 27001, NIST CSF, or the EBA Guidelines on ICT and Security Risk Management, this sounds manageable — until you examine the specific gaps.

ISO 27001 certification, for example, does not automatically satisfy DORA’s ICT Risk Management requirements. There are meaningful overlaps, but also material gaps — particularly around the requirements for a dedicated ICT strategy document approved by the management body (Article 6), formal ICT risk tolerance statements (Article 5), and the detailed Business Continuity Planning and Disaster Recovery requirements under Articles 11–12.

Organisations with a well-implemented ISO 27001 framework typically need 3–4 months to bridge the gap to DORA compliance. Those without a formal security framework should plan for 12–18 months of structured implementation work.

Challenge 3: Server Hardening and ICT Security Requirements Under Article 9

Article 9 of DORA requires financial entities to implement robust technical security measures — including stringent controls on network security, access management, encryption, patch management, and physical security. Server hardening is a core component: the process of reducing a system’s attack surface by disabling unnecessary services, enforcing least-privilege access, and applying security configuration baselines.

What makes this difficult in practice is the scale and heterogeneity of most financial institution environments. A mid-size bank may operate hundreds of servers across on-premise data centres, private cloud, and public cloud platforms — each with different operating systems, application stacks, and existing security configurations. Achieving and maintaining a hardened baseline across all of these without disrupting business operations requires systematic planning and tooling.

Key hardening requirements under DORA Article 9 include:

• Regular software and OS updates with a documented patch management process and defined remediation SLAs
• Disabling unnecessary network ports, services, and protocols
• Multi-factor authentication (MFA) enforced for all privileged access
• Network segmentation to limit lateral movement in the event of a breach
• Encryption of data in transit and at rest using current cryptographic standards
• Automated vulnerability scanning with defined remediation timelines
• Documented configuration baselines with deviation detection and alerting

Challenge 4: Third-Party and Vendor Risk Management (Articles 28–44)

Third-party ICT risk management is one of the most substantive and operationally complex components of DORA, governed by Articles 28–44. Financial entities must implement a comprehensive TPRM programme covering pre-contract due diligence, mandatory contractual provisions under Article 30, ongoing monitoring of critical third-party providers, concentration risk assessment, and incident response coordination with third parties.

Article 30’s mandatory contract provisions are a frequent stumbling block. These include requirements for exit strategies, audit rights, service continuity obligations, data protection requirements, and incident reporting cooperation. In our DORA gap assessment work with EU financial entities, we consistently find that existing ICT contracts with vendors often lack between 30–45% of Article 30’s mandatory provisions. Re-negotiating these contracts requires a structured vendor engagement programme — in one client engagement with an EU investment firm, this process took approximately 90 days for a portfolio of 47 critical ICT contracts.

The emergence of Critical Third-Party Provider (CTPP) designation adds another dimension of complexity. CTPPs — those deemed systemically important to EU financial stability — face direct ESA supervision and penalties of up to €5 million plus 1% of average daily global turnover for each day of continued non-compliance. Financial entities contracting with CTPPs must understand how this designation affects their own risk posture and due diligence obligations.

Challenge 5: Threat-Led Penetration Testing (TLPT) Under Article 26

Threat-Led Penetration Testing is one of the most technically demanding — and least well-understood — DORA requirements. Under Article 26, financial entities identified as significant by their National Competent Authority are required to conduct TLPT at least every three years. TLPT is fundamentally different from standard penetration testing: it is a red-team exercise based on actual threat intelligence, targeting the live production environment of the financial entity, conducted by accredited external testers.

DORA mandates the use of the TIBER-EU framework, developed by the European Central Bank, as the methodology for TLPT exercises. A compliant TLPT exercise involves:

• A formal threat intelligence phase delivered by an accredited Threat Intelligence Provider (TIP)
• A red team testing phase delivered by an accredited Red Team Provider (RTP), targeting live production systems
• NCA notification and approval before testing commences
• A formal remediation plan addressing all findings
• A formal attestation submitted to the NCA upon completion

A compliant TLPT exercise typically takes 6–9 months end-to-end and can cost €150,000–€500,000 depending on institutional size and scope. Many financial entities currently designated for TLPT are significantly underprepared for both the timeline and the cost.

Challenge 6: Meeting ICT Incident Reporting Timelines Under Articles 17–23

DORA’s incident reporting requirements are some of the most operationally demanding in the regulation. Financial entities must classify all ICT incidents against defined materiality thresholds, and for incidents classified as “major”, must meet strict reporting timelines to their National Competent Authority:

Meeting the 4-hour initial notification window is a genuine operational challenge. It requires pre-established incident classification procedures, clearly defined escalation paths, 24/7 response capability, and pre-drafted reporting templates aligned to the ESA reporting format. For institutions without a mature Security Operations Centre (SOC), achieving this consistently is one of the most demanding aspects of DORA compliance.

Challenge 7: Resource Constraints and the Real Cost of DORA Compliance

DORA compliance is a significant investment. According to Deloitte’s Wave 3 DORA Operational Resilience Survey, most EU financial institutions are spending between €2 million and €5 million on DORA compliance, with 39% of entities dedicating 5–7 full-time equivalents (FTEs) to compliance efforts. For smaller institutions operating under DORA’s proportionality provisions, even a simplified compliance programme represents a material resource commitment.

The resource challenge manifests in three distinct ways:

• Financial investment: Technology uplift, gap assessments, third-party audits, TLPT exercises, legal contract reviews, and staff training all carry significant direct costs.
• Human capital: DORA compliance requires expertise spanning ICT risk management, cybersecurity, legal, procurement, and executive governance. Finding professionals who bridge these disciplines is genuinely difficult in the current market.
• Operational disruption: Implementing DORA requirements — particularly server hardening, network segmentation, and third-party contract remediation — requires changes to live production environments. Managing this without business disruption demands careful planning and strong change management.

Challenge 8: Cross-Border and Multi-Jurisdictional Compliance

Financial entities operating across multiple EU member states face an additional layer of complexity: navigating the relationship between DORA’s harmonised EU requirements and the varying supervisory approaches of different National Competent Authorities. While DORA applies uniformly as a regulation, the designation of CTPPs, the selection of entities for TLPT, and the day-to-day supervisory relationship are all managed at national level — and NCA approaches are not identical across member states.

For multinational financial groups, this creates coordination challenges around which entity files incident reports (and to which NCA), how the Register of Information is managed across group structures, and how TLPT exercises are scoped for entities subject to multiple NCA jurisdictions. Establishing a centralised DORA governance function with clear escalation protocols to local compliance teams in each member state is the most effective approach to managing this complexity.

DORA vs NIS2: Key Differences

A question we regularly receive is: “We are already compliant with NIS2 — does that cover DORA?” The short answer is no. While both regulations address cybersecurity and operational resilience, they are meaningfully different in scope, depth, and enforcement:

DORA Non-Compliance Penalties: What Is at Stake

Understanding DORA’s penalty framework is essential context for prioritising compliance investment. The consequences of non-compliance are severe and operate at multiple levels:

Beyond financial penalties, the reputational consequences of public NCA enforcement actions in the financial sector are substantial and long-lasting. Regulatory trust, once damaged, takes years to rebuild.

Strategies for Overcoming DORA Compliance Challenges

Based on experience leading DORA compliance programmes for EU financial entities, the following approaches consistently produce the strongest outcomes:

1. Start with a structured gap assessment. Before investing in remediation, understand precisely where you stand against each DORA pillar. A proper gap assessment maps current controls against DORA requirements, identifies material gaps, and produces a prioritised remediation roadmap with realistic timelines and cost estimates.
2. Build your Register of Information first. Given that it is the number-one compliance challenge and the subject of active ESA scrutiny, the RoI should be the first remediation priority. Use the ESA’s published templates and dry-run validation criteria as your target standard.
3. Appoint a dedicated DORA Programme Manager. DORA compliance spans too many disciplines to be managed as a part-time responsibility. A dedicated programme manager with authority to coordinate IT, legal, procurement, operations, and executive leadership is essential for large and mid-size institutions.
4. Leverage existing frameworks as a foundation. If your organisation has ISO 27001, NIST CSF, or existing EBA compliance, map DORA’s requirements against what you already have. Building on existing controls is typically 30–40% faster and less costly than a greenfield implementation.
5. Engage vendors early on Article 30 contracts. Remediating third-party contracts under Article 30 takes time — vendors need to agree to new terms, legal review adds delay, and negotiations can be protracted. Starting vendor engagement early is critical to avoiding last-minute compliance gaps.
6. Plan your TLPT timeline now. If your organisation is likely to be designated for TLPT, begin the procurement and scoping process immediately. A compliant TIBER-EU exercise takes 6–9 months from start to finish, with significant lead time for NCA notification and accredited provider engagement.
7. Invest in multi-level staff training. DORA compliance is not solely an IT or compliance team problem. Executives must understand their governance obligations under Articles 5–6. Operations teams need to understand incident classification thresholds. Procurement teams need to understand Article 30 contract requirements.

DORA Compliance Checklist for Financial Institutions

Conclusion: Building Resilience That Goes Beyond Compliance

Meeting DORA requirements is genuinely complex — but it is also achievable with the right approach and the right expertise. The financial institutions navigating 2026’s enforcement environment most effectively are those that treated DORA not as a regulatory checkbox but as an opportunity to build measurably stronger operational resilience.

The grace period is over. With only 50% of EU financial institutions estimated to be fully compliant, regulatory attention on the non-compliant half is intensifying. Whether the challenge is your Register of Information, your third-party contracts, your incident reporting capability, or your TLPT programme, the time to act is now.

VISTA InfoSec provides specialist DORA gap assessments, ICT risk management framework reviews, TPRM programme implementations, and DORA staff training for EU financial institutions. Contact us at advisory@vistainfosec.com to discuss your DORA compliance programme.

Frequently Asked Questions About DORA Compliance

Narendra Sahoo

Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.

vistainfosec.com/