Compliance
DORA
digital operational resilience
compliance

DORA Compliance Guide for Financial Entities in 2026

Practical guide to DORA compliance: requirements, TLPT testing, penalties, and actionable steps for financial entities and ICT providers in 2026.

SecraApril 21, 202611 min read

The Digital Operational Resilience Act (DORA) has been fully enforceable since January 17, 2025, and 2026 marks the year when EU supervisors are shifting from awareness to active enforcement. Financial authorities across Europe are conducting detailed audits, issuing the first Threat-Led Penetration Testing (TLPT) notifications, and scrutinizing ICT third-party contracts with unprecedented rigor. Whether you run a financial institution or provide technology services to one, DORA compliance is no longer a roadmap item — it is an operational imperative.

This guide breaks down what DORA requires, who must comply, how penalties work, and the concrete steps your organization should take to achieve and maintain compliance in 2026.

What Is DORA and Why Does It Matter Now

Regulation (EU) 2022/2554, known as DORA, establishes a uniform regulatory framework for the digital operational resilience of the European financial sector. Unlike the NIS2 Directive, which spans multiple sectors and requires national transposition, DORA is a directly applicable regulation across all EU Member States. No local implementing legislation is needed — its obligations are already enforceable as written.

DORA exists because the financial sector's dependence on information technology has reached a point where any major ICT incident can destabilize not just the affected entity but the broader financial system. Ransomware attacks paralyzing banking operations, cloud provider outages disrupting payment systems, and data breaches exposing millions of customer records are not theoretical risks — they are documented incidents from recent years.

What makes 2026 a critical year is that supervisors have now finalized all Regulatory Technical Standards (RTS) and Implementing Technical Standards (ITS) that specify the regulation's requirements in granular detail. Entities can no longer argue that obligations are unclear. The standards are published, deadlines are firm, and supervisory inspections are underway.

Who Must Comply: Entities and Providers in Scope

DORA applies to twenty distinct types of financial entities, making it one of the most comprehensive regulations in the sector. Obligated entities include:

  • Credit institutions (banks)
  • Investment firms
  • Payment institutions and electronic money institutions
  • Insurance and reinsurance undertakings
  • Institutions for occupational retirement provision
  • Management companies of collective investment undertakings
  • Crypto-asset service providers
  • Crowdfunding service providers
  • Credit rating agencies
  • Central securities depositories

But DORA reaches far beyond the traditional financial perimeter. A critical dimension is the regulation of ICT third-party service providers. If your company develops software, manages cloud infrastructure, provides cybersecurity services, or delivers any technology service to financial entities, you fall within DORA's scope.

Providers designated as Critical ICT Third-Party Providers (CTPPs) by the European Supervisory Authorities (EBA, EIOPA, ESMA) are subject to a direct oversight regime with dedicated inspections and penalties. By 2026, major cloud hyperscalers and infrastructure providers have already been identified, with the list expanding progressively.

Practical implication: if you are a technology company serving banks, insurers, or asset managers, your clients will demand DORA compliance evidence as a contractual prerequisite. Being unprepared may mean losing contracts.

The Five Pillars of DORA: What You Must Implement

The regulation is built around five core pillars that entities must implement comprehensively:

1. ICT Risk Management Framework

Entities must establish a comprehensive ICT risk management framework covering the identification and classification of all critical ICT assets, continuous threat and vulnerability assessment, implementation of protection, detection, response, and recovery measures, and periodic framework review with updates for emerging threats.

This framework cannot be a static document. DORA requires it to be embedded in corporate governance, with the management body assuming direct responsibility for its approval and oversight. Board members and executives face personal liability for non-compliance, with fines reaching up to EUR 5 million for individuals.

Entities must conduct risk assessments at least annually and after any major ICT incident, significant infrastructure change, or newly identified threat. The framework must document dependency maps, business impact analyses (BIA), and continuity plans.

2. ICT Incident Reporting and Management

DORA establishes a mandatory incident reporting process for significant ICT incidents to competent authorities. Entities must classify incidents based on criteria defined in the RTS — number of affected clients, economic impact, duration, geographic reach, data loss — and report within strict timelines:

  • Initial notification: within 4 hours of classifying the incident as major, no later than 24 hours from detection
  • Intermediate report: within 72 hours of the initial notification
  • Final report: within one month of incident resolution

Entities must also maintain a documented incident management process covering detection, triage, escalation, containment, forensic analysis, and recovery. The classification thresholds and reporting templates are specified in the RTS, leaving little room for interpretation.

3. Digital Operational Resilience Testing

This is the pillar with the most significant operational impact in 2026. DORA mandates two tiers of testing:

Basic testing (all entities): vulnerability assessments, network security scans, source code reviews (both SAST and DAST), compatibility testing, performance testing, end-to-end testing, and penetration testing. These tests must be conducted at least annually for ICT systems and applications supporting critical functions.

TLPT testing (designated entities): financial entities identified by their competent authorities must perform Threat-Led Penetration Testing at least every three years. TLPT tests align with the TIBER-EU framework and require participation of qualified external Red Team operators who simulate realistic attacks based on sector-specific threat intelligence.

The first TLPT notifications to entities across the EU are scheduled for late 2026 and early 2027. Once notified, an entity has 3 months to submit initiation documents and 6 additional months to deliver the detailed scope specification. TLPTs are not standard penetration tests — they require a threat intelligence phase, a Red Team execution phase against live production systems (without the Blue Team's knowledge), and a closure phase with detailed reporting and a remediation plan overseen by the competent authority.

4. ICT Third-Party Risk Management

DORA introduces rigorous requirements for managing technology vendor risk, an area where many financial entities have significant gaps. Key obligations include:

  • Maintaining a Register of Information (RoI) of all ICT third-party contracts, submitted annually to competent authorities. In the EU, the first major submission cycle occurred in early 2025 and repeats annually
  • Assessing concentration risk across critical providers and establishing viable exit strategies
  • Including mandatory contractual clauses in all ICT provider agreements — audit rights, information access, incident cooperation, data portability
  • Conducting due diligence before onboarding providers and periodic assessments throughout the contract term

Entities outsourcing critical functions must ensure their providers meet equivalent security standards. This creates a cascade effect where DORA obligations extend throughout the entire technology supply chain.

5. Cyber Threat Information Sharing

The fifth pillar establishes a framework for the voluntary sharing of information on threats, vulnerabilities, tactics, techniques, and procedures (TTPs) among financial entities. The objective is to build a collective defense ecosystem where attack intelligence is shared securely and systematically, leveraging frameworks like MITRE ATT&CK for threat classification and enabling sector-wide situational awareness.

Penalties for Non-Compliance: The Cost of Inaction

DORA establishes a robust sanctioning regime that varies by infringement type and entity category:

  • Financial entities: penalties are defined by Member States but can reach up to EUR 20 million or 10% of annual group turnover, whichever is higher
  • Individuals (executives): fines up to EUR 5 million and potential prohibition from holding management positions
  • Critical ICT Third-Party Providers (CTPPs): the Lead Overseer can impose periodic penalty payments of up to 1% of average daily worldwide turnover for each day of non-compliance — potentially representing hundreds of millions of euros for large technology companies

Beyond financial penalties, non-compliance can trigger public censures, operational restrictions, mandatory remediation programs, and intensified supervisory scrutiny that consumes internal resources for months.

Critical point: the personal liability of management body members is one of DORA's most disruptive elements. Board members cannot delegate this responsibility or claim lack of technical knowledge. They must demonstrate they have approved the ICT risk management framework, actively oversee it, and allocate sufficient resources to operational resilience.

How to Prepare Your Organization for DORA in 2026

Whether you are a financial entity or an ICT provider to the sector, these are the practical steps to achieve and sustain compliance:

Step 1: Gap Analysis

Compare your current security posture against DORA requirements. Review your ICT risk management framework, incident detection and response capabilities, security testing program, vendor contracts, and governance model. A specialized GRC consultancy engagement can significantly accelerate this process by identifying critical gaps and prioritizing remediation actions.

Step 2: Update the ICT Risk Management Framework

Develop or update your framework in accordance with the RTS. Document the ICT asset taxonomy, dependency maps, impact analyses, implemented security controls, and update procedures. Ensure the management body formally approves the framework and reviews it at least annually.

Step 3: Implement a Resilience Testing Program

Establish an annual testing program that includes, at minimum, vulnerability assessments, penetration testing of critical systems, and code reviews for proprietary applications. If your entity may be designated for TLPT, start preparing now by identifying advanced penetration testing providers with TIBER-EU experience and Red Team capabilities.

Testing must not be a checkbox exercise. It should produce actionable findings with defined remediation plans and deadlines. Supervisors will evaluate not only that tests were executed but that results translated into genuine security improvements.

Step 4: Review and Strengthen ICT Provider Contracts

Audit all contracts with technology providers to verify they include DORA's mandatory clauses: audit rights, incident notification, supervisory cooperation, security service levels, exit strategies, and data portability. Prepare the Register of Information (RoI) in accordance with supervisory authority templates.

Step 5: Train the Management Body

Board members and senior executives must receive specific training on their DORA responsibilities. The goal is not to turn them into technical experts but to ensure they understand the organization's ICT risks, the regulation's obligations, and their personal liability. DORA explicitly requires that management body members maintain sufficient knowledge and skills relating to ICT risks, updated regularly to keep pace with evolving threats.

DORA and NIS2: How They Interact

A frequent question concerns the relationship between DORA and the NIS2 Directive. Both regulations address cybersecurity, but with different approaches and scopes:

  • DORA is a sector-specific regulation for financial services, directly applicable, with detailed requirements and specialized supervision by financial authorities
  • NIS2 is a horizontal directive spanning multiple sectors (energy, transport, health, digital infrastructure, etc.) requiring national transposition

The lex specialis principle establishes that DORA takes precedence over NIS2 for financial entities in matters it specifically regulates. However, if NIS2 imposes stricter requirements in a particular area, those additional obligations may also apply.

In practice, financial entities should treat DORA as their primary regulatory framework and verify whether NIS2 introduces complementary obligations in areas not covered by DORA. Organizations that already hold certifications such as ISO 27001 or national security frameworks have a solid foundation on which to build DORA compliance, though they will need specific adaptations in areas like incident reporting, TLPT, and vendor management.

The Role of Penetration Testing and Red Teaming in DORA Compliance

Penetration testing and Red Team exercises are not optional add-ons under DORA — they are explicit regulatory requirements. Article 25 mandates penetration testing as part of the basic resilience testing program, while Articles 26 and 27 establish the TLPT framework for designated entities.

TLPTs are advanced exercises that go far beyond conventional penetration tests. They require:

  • A threat intelligence phase where a specialized provider identifies the most relevant and realistic threats to the entity based on the financial sector's threat landscape
  • A Red Team execution phase simulating real attacks against the entity's production systems without the defense team's (Blue Team) prior knowledge
  • A closure and remediation phase with detailed reporting, joint feedback sessions (in a Purple Team format), and a remediation plan overseen by the competent authority

Provider selection is critical: DORA sets specific requirements for the qualification, experience, and reputation of external testing teams, including technical certifications, demonstrable TIBER-EU experience, and the capability to cover both intelligence and execution phases.

Next Steps: Act Before Supervisors Do

DORA is not a future regulation — it is a current obligation. In 2026, supervisory authorities across the EU are intensifying verifications, TLPT designations are underway, and contractual requirements with ICT providers are tightening with every renewal cycle.

Organizations that act now have the margin to implement changes in an orderly manner and turn compliance into a competitive advantage. Those that delay will face accelerated implementations under supervisory pressure, with significantly higher costs and tangible sanction risk.

If your organization needs to assess its DORA readiness, Secra offers a free initial assessment that identifies key gaps and proposes a prioritized compliance roadmap. Our team combines expertise in GRC consultancy, advanced penetration testing, and Red Team exercises aligned with TIBER-EU — exactly what DORA demands.

Request your free assessment →

About the author

Secra Solutions team

Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

Meet the team →

Share article

👋Hi! Have any questions? Write to us, we reply in minutes.

Open WhatsApp →