What is DORA Compliance? The Definitive Guide for Financial Services

The Digital Operational Resilience Act - DORA - is the European Union's answer to a simple but critical question: what happens when the technology that financial services depend on fails?

Banks go offline. Payment systems freeze. Insurance claims cannot be processed. Trading halts. In a sector where technology underpins virtually every operation, a single ICT failure can cascade into a systemic crisis.

DORA (Regulation (EU) 2022/2554) is a binding regulation that establishes a comprehensive framework for digital operational resilience across the entire EU financial sector. It entered into force on 16 January 2023 and became fully applicable on 17 January 2025.

If you work in compliance, risk management, or IT security at a financial institution, this guide covers everything you need to know: what DORA requires, who it applies to, the five core pillars, enforcement mechanisms, and concrete steps to achieve and maintain compliance.

Why DORA Exists

Before DORA, the EU's approach to ICT risk in financial services was fragmented. Different directives and national regulations addressed pieces of the problem - MiFID II covered some operational resilience, PSD2 addressed payment security, Solvency II touched on IT governance for insurers - but there was no unified framework.

This fragmentation created three problems:

1. Inconsistent standards. A bank in Germany faced different ICT risk requirements than one in France, despite operating in the same single market.
2. Regulatory gaps. Critical third-party providers (cloud platforms, data centres, core banking software vendors) fell outside the direct supervision of financial regulators.
3. Reactive, not proactive. Existing rules focused on what to do after an incident, not on building systemic resilience before one occurs.

DORA addresses all three. It creates a single, harmonised framework that applies to financial entities and their critical ICT third-party service providers across all 27 EU member states. Because DORA is a regulation (not a directive), it applies directly - no national transposition required.

Who Must Comply with DORA?

DORA's scope is deliberately broad. Article 2 defines 21 categories of financial entities that fall under DORA, including:

Banking and Credit

• Credit institutions (banks)
• Payment institutions
• Electronic money institutions
• Account information service providers

Investment and Trading

• Investment firms
• Trading venues
• Central securities depositories
• Central counterparties
• Trade repositories

Insurance and Pensions

• Insurance and reinsurance undertakings
• Insurance intermediaries
• Institutions for occupational retirement provision (IORPs)

Asset Management

• Management companies (UCITS)
• Alternative investment fund managers (AIFMs)

Other

• Crypto-asset service providers (under MiCA)
• Crowdfunding service providers
• Credit rating agencies
• Securitisation repositories

Additionally, DORA introduces a critical new element: direct oversight of critical ICT third-party service providers (CTPPs). The European Supervisory Authorities (EBA, ESMA, EIOPA) can designate cloud providers, data analytics firms, and other technology vendors as "critical" and subject them to direct regulatory oversight. This is unprecedented in EU financial regulation.

The proportionality principle

DORA applies proportionally. Article 4 states that financial entities must implement requirements "taking into account their size and overall risk profile, and the nature, scale and complexity of their services, activities and operations."

In practice, this means a small payment institution with 20 employees is not expected to implement DORA at the same depth as a G-SIB (Global Systemically Important Bank). However, every covered entity must address all five pillars - the depth and sophistication of implementation varies, not the scope.

The 5 Pillars of DORA

DORA is structured around five core pillars. Each addresses a distinct dimension of digital operational resilience.

Pillar 1: ICT Risk Management (Articles 5-16)

This is the foundation. DORA requires every financial entity to establish and maintain a comprehensive ICT risk management framework that is:

• Documented - with formal policies approved by the management body
• Integrated - into the entity's overall risk management framework (not a separate IT silo)
• Continuously updated - reviewed at least annually and after major incidents

The framework must cover:

Identification (Article 8): Maintain an inventory of all ICT assets, systems, and processes. Map dependencies between business functions and the ICT systems that support them. Identify all ICT risks and document risk tolerance levels.

Protection and Prevention (Article 9): Implement security policies, access controls, encryption, network security, and patch management. DORA is specific here - it requires policies on identity and access management, strong authentication, cryptographic key management, and network security.

Detection (Article 10): Deploy mechanisms to detect anomalous activities, including cybersecurity events and ICT-related incidents. Multiple layers of detection controls are required.

Response and Recovery (Article 11-12): Establish ICT business continuity policies, disaster recovery plans, and crisis communication procedures. Recovery time and point objectives must be defined for all critical functions.

Learning and Evolving (Article 13): Conduct post-incident reviews. Update the risk management framework based on lessons learned, threat intelligence, and industry developments.

The management body's role is emphasised throughout. Article 5(2) makes the board of directors (or equivalent) ultimately responsible for the ICT risk management framework. They must approve it, oversee its implementation, and demonstrate adequate knowledge of ICT risks. This is not something you can delegate entirely to the IT department.

Pillar 2: ICT Incident Reporting (Articles 17-23)

DORA creates a harmonised incident reporting framework across the EU financial sector. Previously, a bank might need to report the same incident to different authorities under different rules. DORA streamlines this.

Classification. Financial entities must classify ICT-related incidents based on criteria defined in Article 18, including:

• Number of clients/counterparties affected
• Duration of the incident
• Geographical spread
• Data losses
• Impact on critical services
• Economic impact

Reporting obligations. For major ICT-related incidents, entities must submit:

1. Initial notification - within 4 hours of classifying the incident as major (and no later than 24 hours after detection)
2. Intermediate report - within 72 hours of the initial notification
3. Final report - within one month of the intermediate report

Reports go to the relevant competent authority (e.g., BaFin in Germany, FCA in the UK for firms with dual reporting, the ECB for significant institutions directly supervised).

Voluntary reporting. DORA also encourages (but does not mandate) reporting of significant cyber threats, even if no incident has occurred.

Practical implication: Your incident response procedures need to be fast, well-rehearsed, and connected to your reporting chain. Four hours from classification to initial notification leaves no room for confusion about who reports what to whom.

Pillar 3: Digital Operational Resilience Testing (Articles 24-27)

This pillar is where penetration testing enters the picture. DORA requires two levels of testing:

Basic testing (Article 25) - required for all financial entities:

• Vulnerability assessments and scans
• Open-source analyses
• Network security assessments
• Gap analyses
• Physical security reviews
• Questionnaires and scanning software solutions
• Source code reviews where feasible
• Scenario-based tests
• Compatibility testing
• Performance testing
• End-to-end testing
• Penetration testing

Basic testing must be performed regularly (at least annually for critical systems), by qualified testers, and results must feed back into the ICT risk management framework.

Advanced testing - TLPT (Article 26) - required for significant financial entities:

Threat-Led Penetration Testing follows the TIBER-EU framework and must:

• Be conducted at least every three years
• Cover critical or important functions
• Be performed on live production systems
• Include threat intelligence phases
• Use qualified external testers (red team providers)
• Be scoped and overseen by the competent authority

TLPT is the most demanding testing requirement in DORA. It simulates real-world, intelligence-led attacks against your production systems, including social engineering, physical access attempts, and multi-stage attack campaigns.

How automated penetration testing fits: Article 25 testing is where automated penetration testing platforms deliver enormous value. Running continuous automated pentests against your web applications, APIs, and infrastructure satisfies the "regular penetration testing" requirement with verifiable evidence. For Article 26 TLPT, human-led red teaming is required, but automated tools can support the process by identifying initial attack surfaces and validating remediation.

Pillar 4: ICT Third-Party Risk Management (Articles 28-44)

Financial services run on third-party technology. Core banking platforms, cloud infrastructure, market data feeds, payment processing networks - all provided by third parties. DORA recognises this dependency and creates the most comprehensive third-party ICT risk framework in any financial regulation.

Key requirements:

Register of information (Article 28(3)): Maintain a register of all contractual arrangements with ICT third-party service providers. This register must be available to competent authorities upon request. The ESAs have published detailed templates (ITS on the Register of Information) specifying exactly what must be recorded.

Pre-contractual assessment (Article 28(4-5)): Before entering into any ICT outsourcing arrangement, assess whether the provider can support compliance with DORA, evaluate concentration risk, and verify the provider's security capabilities.

Contractual provisions (Article 30): All contracts with ICT third-party providers must include specific clauses covering:

• Service level descriptions and performance targets
• Incident reporting obligations
• Audit and access rights (including for regulators)
• Exit strategies and transition plans
• Data location and processing restrictions
• Subcontracting conditions

Concentration risk (Article 29): Assess whether your entity is overly dependent on a single provider or a small number of providers. If one cloud provider hosts 80% of your critical functions, that is a concentration risk that must be managed.

Oversight of critical providers (Articles 31-44): The ESAs can designate certain providers as "critical ICT third-party service providers" and subject them to direct oversight, including on-site inspections, recommendations, and ultimately the power to require financial entities to partially or fully suspend use of a non-compliant provider.

Pillar 5: Information Sharing (Article 45)

The fifth pillar encourages (but does not mandate) financial entities to share cyber threat intelligence and vulnerability information with each other. This can be done through:

• Trusted information sharing communities
• ISACs (Information Sharing and Analysis Centres)
• Industry-specific platforms

The goal is to create a collective intelligence network that raises the resilience of the entire sector. Financial entities that participate in information sharing arrangements must notify their competent authority and ensure appropriate confidentiality protections.

While this pillar is voluntary, regulators will increasingly view participation in information sharing as evidence of a mature cyber resilience programme.

DORA Enforcement and Penalties

DORA enforcement is handled by national competent authorities (NCAs) - the same regulators that supervise financial institutions today:

• EBA oversees credit institutions, payment institutions, electronic money institutions
• ESMA oversees investment firms, trading venues, central counterparties
• EIOPA oversees insurance and reinsurance undertakings, IORPs

Penalties are determined at the national level, but DORA sets the framework. Article 50 requires member states to establish "effective, proportionate and dissuasive" administrative penalties. Several member states have transposed penalties including:

• Fines calculated as a percentage of annual turnover
• Public censure (naming and shaming)
• Temporary prohibition of management functions
• Orders to cease specific activities

For critical ICT third-party service providers under direct ESA oversight, Article 35(8) allows penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance, for up to six months.

The reputational damage of a publicised DORA sanction may be more costly than the fine itself. In a sector built on trust, being publicly cited for inadequate digital resilience is a serious business risk.

DORA Timeline: Where We Are Now

DORA is not a future obligation. It is current law. If your organisation has not yet established a DORA-compliant ICT risk management framework, you are already behind.

How to Prepare: Practical Steps

Achieving DORA compliance is not a single project - it is an ongoing programme. Here is a practical roadmap:

Phase 1: Assessment (4-8 weeks)

1. Gap analysis. Map your current ICT risk management practices against DORA's specific requirements (Articles 5-16). Identify gaps in policies, procedures, and controls.
2. Scope definition. Identify all ICT systems supporting critical or important functions. These are your priority.
3. Third-party inventory. Build your register of information (Article 28(3)). Catalogue every ICT third-party provider, the services they provide, and which business functions depend on them.

Phase 2: Remediation (3-6 months)

4. Update policies. Revise ICT risk management policies, incident response procedures, business continuity plans, and third-party management policies to meet DORA requirements.
5. Implement controls. Deploy missing technical controls - identity and access management, encryption, logging and monitoring, network segmentation.
6. Update contracts. Review all ICT third-party contracts against Article 30 requirements. Negotiate amendments where clauses are missing.

Phase 3: Testing and Validation (Ongoing)

7. Establish testing programme. Implement regular penetration testing, vulnerability assessments, and scenario-based testing per Article 25. Deploy automated penetration testing for continuous coverage.
8. Conduct tabletop exercises. Test your incident response and business continuity plans through simulated scenarios.
9. Prepare for TLPT. If your entity is subject to Article 26, begin scoping your first Threat-Led Penetration Test with your competent authority.

Phase 4: Ongoing Compliance

10. Continuous monitoring. DORA is not a point-in-time certification. Implement continuous monitoring of ICT risks, third-party performance, and security posture.
11. Regular reviews. Review the ICT risk management framework at least annually and after every major incident.
12. Board reporting. Establish regular reporting to the management body on ICT risks, incidents, and testing results.

How Automated Pentesting Satisfies DORA Article 26

One of the most operationally demanding aspects of DORA is the testing requirement. Article 25 requires penetration testing as part of the basic testing programme, and Article 26 requires TLPT for significant entities.

Automated penetration testing platforms directly address the Article 25 requirement by:

• Running continuous tests against web applications, APIs, and infrastructure
• Generating compliance-mapped evidence for each test cycle
• Providing verifiable proof of exploitation (not just theoretical vulnerabilities)
• Automating remediation verification (retesting after fixes)
• Creating audit-ready reports aligned to DORA's testing requirements

For Article 26 TLPT, automated testing supports the process by:

• Identifying the external attack surface (reconnaissance phase)
• Discovering initial vulnerabilities that human red teamers can investigate further
• Validating that TLPT findings have been properly remediated

The combination of continuous automated testing (Article 25) and periodic human-led TLPT (Article 26) creates a robust testing programme that satisfies DORA in full.

DORA and Other Regulations: How They Interact

DORA does not exist in isolation. It interacts with and complements other regulatory frameworks:

• NIS2 Directive - DORA is lex specialis (specific law) for the financial sector, meaning DORA requirements take precedence over NIS2 for covered entities. However, financial entities should still be aware of NIS2 supply chain requirements.
• GDPR - DORA's incident reporting requirements complement GDPR's 72-hour breach notification. If an ICT incident involves personal data, both reporting obligations apply.
• MiFID II/MiFIR - DORA replaces the operational resilience provisions in MiFID II's delegated acts for investment firms.
• PSD2/PSD3 - Payment institutions are covered by DORA, which raises the bar above PSD2's existing security requirements.
• ISO 27001 - DORA and ISO 27001 share significant overlap. An ISO 27001-certified organization is well-positioned for DORA, though additional requirements (particularly around TLPT and the register of information) must be addressed.

Conclusion

DORA represents the most comprehensive digital operational resilience framework ever applied to the financial sector. It is not a box-ticking exercise - it is a fundamental shift in how financial regulators approach ICT risk. The regulation demands that organisations build genuine resilience: tested, documented, governed, and continuously improved.

The organisations that treat DORA as an opportunity rather than a burden will build stronger security programmes, better third-party relationships, and more resilient operations. Those that treat it as a checkbox will find themselves perpetually catching up as enforcement intensifies.

Matproof helps financial institutions achieve and maintain DORA compliance through automated penetration testing, continuous control monitoring, and compliance evidence management - covering all five pillars in a single platform. Book a demo to see how Matproof maps to your DORA requirements.