DORA Compliance Penetration Testing: What EU Financial Entities Need to Know

The Digital Operational Resilience Act—DORA—represents the most significant shift in cybersecurity regulation the EU financial sector has ever seen. And at its core, sitting right alongside ICT risk management frameworks and incident reporting obligations, is a set of testing requirements that turns penetration testing from a voluntary exercise into a legally mandated activity with defined frequencies, scoping rules, tester qualifications, and supervisory oversight.

If you're a bank, insurer, payment institution, investment firm, or any other entity regulated under EU financial services law, this applies to you. If you're systemically important, it gets even more intense. And if you're an ICT third-party provider serving those entities, you're not off the hook either.

This guide walks through everything you need to understand: what DORA requires, who's in scope, the difference between standard annual testing and the advanced Threat-Led Penetration Testing (TLPT) regime, and how to build a testing program that keeps you compliant without drowning in regulatory complexity.

---

What Is DORA and Why Does It Exist?

The Digital Operational Resilience Act (EU Regulation 2022/2554) was adopted by the European Council in December 2022, entered into force on January 16, 2023, and became applicable on January 17, 2025. Unlike a Directive, which requires transposition into national law, DORA is a Regulation—meaning it is directly applicable in all EU Member States without modification.

DORA exists because the EU's financial sector had a patchwork problem. Before it, different countries applied different cybersecurity requirements to their financial institutions. Some had robust testing frameworks (the Netherlands had TIBER-NL, Germany had TIBER-DE), while others had minimal technical requirements. A cross-border bank might face three different testing regimes depending on which jurisdiction was looking.

Meanwhile, the financial sector was becoming increasingly dependent on digital infrastructure and third-party ICT providers. A single cloud outage or cyberattack could cascade across institutions, borders, and markets. DORA was designed to create a harmonized framework that ensures every financial entity in the EU can withstand, respond to, and recover from ICT-related disruptions.

The regulation rests on five pillars: ICT risk management, ICT-related incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Penetration testing falls under the third pillar, covered in Chapter IV (Articles 24 through 27) of the regulation—and it's the pillar with the sharpest teeth for day-to-day security teams.

Who's in Scope?

DORA applies broadly across the financial sector. The entities subject to its requirements include credit institutions (banks), payment institutions, electronic money institutions, investment firms, insurance and reinsurance companies, crypto-asset service providers under MiCA, central securities depositories, trading venues, trade repositories, fund management companies, credit rating agencies, and crowdfunding service providers, among others.

In practical terms: if your organization is regulated under EU financial services law, you're almost certainly in scope for DORA. The regulation deliberately casts a wide net to ensure that digital operational resilience is consistent across the sector.

There is one carve-out worth noting. Microenterprises—defined as entities with fewer than 10 employees and annual turnover or balance sheet below €2 million—face a lighter testing regime. They must still apply a risk-based approach to ICT testing, but the requirements are proportionally scaled. For everyone else, the full testing obligations apply.

And critically, DORA's reach extends beyond the financial entities themselves. ICT third-party service providers—cloud platforms, SaaS vendors, managed service providers, data analytics firms—fall under DORA's oversight framework, especially if they're deemed critical to financial sector stability. If you're a technology vendor serving EU financial institutions, your customers' DORA obligations are rapidly becoming your problem.

The Two Tiers of DORA Testing

DORA establishes a two-tiered approach to resilience testing. Understanding this structure is essential because the requirements, frequency, and complexity differ significantly between the tiers.

Dimension	Tier 1: Standard Testing	Tier 2: TLPT (Advanced)
Who	All DORA-regulated entities (except microenterprises)	Systemically important entities identified by competent authorities
Frequency	At least annually for critical/important functions	At least every 3 years (authority may adjust)
Scope	ICT systems supporting critical or important functions	Critical functions on live production systems, including third-party ICT
Approach	Vulnerability assessments, penetration testing, scenario-based tests, and others	Intelligence-driven red team exercise mimicking real threat actors
Blue team awareness	Typically aware of testing	Unaware—testing conducted in secrecy
Regulatory oversight	Testing programme documented and available on request	Scope validated by competent authority; attestation issued on completion

Tier 1: Annual Penetration Testing Under Articles 24 and 25

The baseline testing requirement applies to every DORA-regulated financial entity that isn't a microenterprise. Article 24 requires financial entities to establish, maintain, and review a comprehensive digital operational resilience testing programme as part of their ICT risk management framework.

Article 24(6) is the critical clause: financial entities must ensure that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions at least once a year.

Article 25 then lists the types of tests that the testing programme should include. The regulation doesn't require every entity to run every type of test—the principle of proportionality applies—but the examples give a clear picture of what regulators expect. These include vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, source code reviews (where feasible), scenario-based tests, compatibility testing, performance testing, end-to-end testing, and penetration testing.

For most financial entities with meaningful ICT infrastructure, penetration testing will be a core component of their annual programme. The regulation is clear: you need to demonstrate that your systems can withstand real-world attack techniques, not just that they've been scanned for known vulnerabilities.

What "Critical or Important Functions" Means

DORA defines a critical or important function as one whose disruption would materially impair the financial entity's performance, the soundness or continuity of its services, or its continuing compliance with regulatory obligations. In practical terms, this covers your core business operations: payment processing, trading platforms, customer-facing portals, credit decisioning systems, insurance claims platforms, settlement infrastructure, and the backend systems that support them.

Identifying these functions is the first step in scoping your testing programme. If a system supports a critical or important function—directly or through dependencies—it's in scope for annual testing.

Proportionality: Scaling Tests to Your Risk Profile

DORA explicitly acknowledges that not every financial entity is the same size or faces the same risk profile. Article 4(2) establishes a proportionality principle: the depth and frequency of your testing should be calibrated to your entity's size and complexity, overall risk profile, the criticality of the ICT systems being tested, exposure through outsourcing or cloud dependencies, material changes to your ICT infrastructure, and the severity and outcomes of previous incidents.

This means a small fintech company with a focused product and limited infrastructure isn't expected to match the testing programme of a G-SII (globally systemically important institution). But it also means you can't use proportionality as a blanket excuse for doing minimal testing. The principle scales the depth of testing, not the obligation to test.

Tier 2: Threat-Led Penetration Testing (TLPT) Under Articles 26 and 27

If standard annual testing is DORA's baseline, TLPT is the advanced tier—and it's a fundamentally different beast.

TLPT is a full-scale, intelligence-driven red team exercise conducted on live production systems, in secrecy from the organization's defensive teams, mimicking the tactics, techniques, and procedures that real-world threat actors would use against the entity. It's not a vulnerability scan with a fancy name. It's a controlled cyberattack designed to test whether your institution—its technology, its processes, and its people—can withstand and detect a sophisticated, targeted intrusion.

TLPT is mandatory only for certain financial entities identified by their competent authorities based on systemic importance, risk profile, and ICT maturity. The entities most likely to be designated include globally systemically important banks (G-SIIs) and other systemically important institutions (O-SIIs), the largest payment institutions (those processing over €150 billion in total transactions over each of the preceding two years), large insurance and reinsurance companies, central counterparties and central securities depositories, and major trading venues.

If your competent authority designates you for TLPT, you must carry out advanced testing at least every three years. The authority may also increase or decrease this frequency based on your risk profile and operational circumstances.

How TLPT Works: The Six Phases

The Regulatory Technical Standards on TLPT (Commission Delegated Regulation EU 2025/1190, published in June 2025) define a structured process that involves several distinct phases.

The preparation phase begins when the competent authority (your TLPT authority) notifies your entity that it must conduct a TLPT. You assemble a control team—a small, trusted group within your organization that manages the test—and identify the critical functions to be tested. The scope is then submitted to the TLPT authority for validation.

The threat intelligence phase involves a threat intelligence provider producing a targeted threat intelligence report specific to your institution. This report analyzes the threat actors most likely to target your entity, their known tactics and techniques, and the attack scenarios most relevant to your business model, technology stack, and geography. This intelligence drives the entire test—ensuring it reflects real-world threats, not generic attack playbooks.

The red team testing phase is the execution. The red team—working from the threat intelligence—conducts a sustained offensive campaign against your live production systems. Unlike standard pentesting, the test runs over an extended period (typically three to four months), the blue team (your defenders) is not informed, and the objective is to simulate a genuine advanced persistent threat.

The closure phase includes a mandatory purple teaming exercise, which is a key difference from the previous TIBER-EU framework where purple teaming was only recommended. During purple teaming, the red team and blue team work together to walk through the attack scenarios, review what was detected and what was missed, and collaboratively identify improvements. This ensures the test generates learning, not just findings.

Finally, the reporting and remediation phase produces documentation that is submitted to the competent authority for validation and attestation. The authority confirms that the TLPT was conducted in accordance with DORA's requirements and issues a formal attestation.

TLPT vs. Standard Pentesting: Understanding the Gap

The distinction between TLPT and standard penetration testing is one of the most important concepts for DORA compliance, and one of the most commonly misunderstood.

A standard penetration test typically targets a specific system or application—a web application, an API, a network segment. It runs for one to three weeks. The security team knows it's happening. The scope is bounded and agreed upon in advance. The tester looks for technical vulnerabilities, attempts to exploit them, and produces a report with findings and remediation guidance. It's a technical assessment of a defined surface.

A TLPT covers the entire organization. It targets critical business functions—not specific systems. It runs for months, not weeks. The defensive team is completely unaware. The test is driven by bespoke threat intelligence, not generic methodology. The testers simulate the full lifecycle of a real attack: reconnaissance, initial access, persistence, lateral movement, privilege escalation, and data exfiltration or operational disruption. And it tests not just technology, but people (do staff fall for the phishing?) and processes (does the SOC detect the intrusion? Does the incident response plan actually work?).

Think of it this way: a pentest asks "can someone break into this room?" TLPT asks "can a sophisticated adversary get into our building, find the vault, open it, take what they want, and leave without anyone noticing?"

ICT Third-Party Providers: You're Not Off the Hook

One of DORA's most significant innovations is its treatment of ICT third-party risk as a systemic concern rather than a bilateral contractual issue. If you're a cloud provider, SaaS vendor, managed security service, or any other technology company serving EU financial institutions, DORA reaches you in several important ways.

First, financial entities must contractually require their ICT third-party service providers to participate in and cooperate with TLPT when those providers are included in the test scope. Article 30(3)(d) of DORA makes this explicit. If your cloud platform hosts a bank's payment processing infrastructure and that bank is designated for TLPT, the bank must ensure your participation in the test—and you must facilitate it.

Second, ICT providers deemed critical to financial sector stability will be designated as Critical Third-Party Providers (CTPPs) by the European Supervisory Authorities (ESAs). CTPPs fall under direct oversight from the ESAs, including specific requirements around security testing, risk management, and operational resilience. The first wave of CTPP designations is expected in 2025, following criticality assessments by the ESAs.

Third, even if you're not designated as a CTPP, DORA is rapidly becoming a procurement filter. Financial entities evaluating technology vendors will increasingly require evidence of robust security testing programmes, the ability to support client-led simulations, and readiness for joint operational testing. Non-compliance won't just mean regulatory risk—it will mean losing access to European financial clients.

If you serve EU-regulated financial entities, the practical advice is straightforward: prepare to support your clients' DORA testing requirements, offer isolated test environments where appropriate, and be ready to demonstrate your own operational resilience through documented testing programmes.

Who Can Conduct Testing?

DORA establishes specific qualification requirements for testers, particularly for TLPT.

Standard Testing (Articles 24–25)

For the annual testing programme, DORA allows testing to be performed by independent internal teams or by qualified external providers. The key requirement is independence—testers must have no conflicts of interest and must not have a vested interest in the results. If you use internal testers, appropriate organizational separation is required.

The regulation doesn't mandate specific certifications for standard testing, but it does require that testers possess the necessary skills and expertise. In practice, competent authorities expect testers to have recognized professional qualifications and demonstrable experience in the types of testing being conducted.

TLPT (Articles 26–27)

For TLPT, the requirements are considerably stricter. The regulation requires that testers are of the highest suitability and reputability, possess technical and organisational capabilities with specific expertise in threat intelligence, penetration testing, or red team testing, are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks, and for external testers, carry professional indemnity insurance against risks of misconduct.

A significant nuance: DORA allows internal testers to conduct the red team component of TLPT, but with two critical constraints. The threat intelligence must always be provided by an external party, and every third TLPT must be conducted by an external red team provider. In practice, this means that even if you build an internal red team capability, you'll need external testers for at least one in every three TLPT cycles.

Remediation, Reporting, and Attestation

DORA doesn't treat testing as a standalone activity—it's embedded in a continuous improvement loop. The regulation requires financial entities to establish procedures and policies to prioritize, classify, and remedy all issues revealed through testing, and to ensure that all identified vulnerabilities and deficiencies are fully addressed.

For standard annual testing, the expectation is that your testing programme generates documented findings, those findings are triaged by severity, remediation is tracked and completed, and the results feed back into your ICT risk management framework. Your documentation must be available to competent authorities on request.

For TLPT, the requirements are more formal. After the test concludes—including the mandatory purple teaming exercise—the financial entity and the external testers provide documentation to the competent authority confirming that the TLPT was conducted in accordance with DORA's requirements. The competent authority validates this documentation and issues an attestation. This attestation can then be shared with other competent authorities to enable mutual recognition, reducing the need for duplicate testing across jurisdictions.

The mutual recognition mechanism is one of DORA's most practical innovations. If you're a cross-border institution operating in multiple EU Member States, a single TLPT attestation can satisfy supervisory requirements across jurisdictions—a significant improvement over the pre-DORA landscape where separate national testing frameworks required separate tests.

Key Timelines

The timeline matters strategically. If you're a candidate for TLPT designation, the first notifications are expected in 2026. The six-month window from notification to scope submission is tight for organizations that haven't laid the groundwork. Start the function mapping, identify your control team lead, and evaluate your provider options before you receive the letter.

Building Your DORA Testing Programme

Whether you're a mid-sized payment institution building a testing programme from scratch or a G-SII aligning an existing programme with DORA's requirements, here's a practical framework.

Step 1: Map Your Critical and Important Functions

Before you can test anything, you need to know what matters. Identify all functions whose disruption would materially impair your entity's performance, service continuity, or regulatory compliance. Then map the ICT systems, applications, and third-party dependencies that support each function. This mapping becomes the foundation of your testing scope and directly feeds your ICT risk management framework.

Step 2: Establish a Risk-Based Testing Programme

Design a testing programme that covers all ICT systems supporting critical or important functions, incorporates the testing types listed in Article 25 (scaled to your proportionality profile), operates on at least an annual cycle, and adapts based on material changes to your infrastructure, the outcomes of previous tests, and evolving threat intelligence.

Document the programme formally. DORA requires that your testing programme is documented, reviewed, and maintained as part of your ICT risk management framework. This documentation must be available to your competent authority on request.

Step 3: Engage Qualified Testing Providers

For most entities, external penetration testing providers will deliver the annual testing component. Select providers that have demonstrated experience in the financial sector, understand DORA's specific requirements, and can produce reports that meet regulatory expectations. Ensure that engagement contracts address independence requirements, confidentiality obligations, and the scope alignment process.

If you're a candidate for TLPT, you'll also need to identify threat intelligence providers and red team providers who meet the stringent qualifications outlined in Article 27 and the TLPT RTS. Start this evaluation early—the pool of qualified TLPT providers is smaller than the general pentest market, and scheduling windows fill quickly.

Step 4: Build the Remediation Loop

Testing without remediation is performance without purpose. Establish a documented workflow that takes findings from identification through remediation and verification. Classify findings by severity, assign ownership, define response timelines, and track closure. Every remediation should be verified—either through retesting or through validated control implementation.

Feed your testing results back into your ICT risk management framework. DORA views testing as one input into a broader resilience picture—not a standalone compliance exercise.

Step 5: Prepare for TLPT (If Applicable)

If your entity is likely to be designated for TLPT, preparation should start well before the notification arrives. Identify a control team lead—someone senior enough to manage the test across organizational boundaries and trusted enough to maintain secrecy from the blue team. Map the critical functions that will likely be in scope. Evaluate third-party dependencies that may need to be included. Review your contractual arrangements with ICT providers to ensure DORA-compliant participation clauses are in place.

Common Mistakes in DORA Testing Compliance

Treating Testing as a Checkbox

DORA's entire philosophy is resilience—not compliance theatre. Regulators designed the testing requirements to ensure that financial entities can genuinely withstand cyberattacks, not just produce reports that say they tried. If your testing programme generates findings that never get remediated, covers the easy systems while avoiding the complex ones, or produces reports that sit in a drawer until the next audit, you're missing the point and the regulator will notice.

Confusing Vulnerability Scanning with Penetration Testing

Article 25 lists both vulnerability assessments and scans and penetration testing as components of a testing programme. These are distinct activities. Automated vulnerability scanning identifies known weaknesses at scale. Penetration testing involves a qualified human tester actively attempting to exploit those weaknesses, chain them together, and assess real-world impact. Running a Nessus scan and calling it a penetration test won't satisfy DORA.

Ignoring Third-Party Dependencies

If your critical functions depend on third-party ICT providers—and in modern financial services, they almost certainly do—your testing programme must account for those dependencies. For standard testing, this means assessing the security posture of your third-party connections and interfaces. For TLPT, it means contractually ensuring your providers will participate in the test. Financial entities that ignore third-party risk in their testing scope create exactly the kind of blind spot DORA was designed to eliminate.

Assuming TLPT Is Just a Bigger Pentest

We've said it before, but it's worth repeating. TLPT is a fundamentally different activity from penetration testing. It's intelligence-driven, conducted on live production systems, run in secrecy from your defensive teams, executed over months rather than weeks, requires mandatory purple teaming, and is validated and attested by your competent authority. Approaching TLPT with a pentest mindset—limited scope, short timeline, technical-only focus—will result in a test that doesn't meet regulatory requirements and doesn't deliver meaningful resilience insights.

Waiting for Notification

If you're a systemically important institution, waiting for your competent authority to formally notify you before preparing for TLPT is a strategic mistake. The notification-to-scope window is approximately six months, and the preparation required—function mapping, provider selection, contract negotiation, control team formation, threat intelligence procurement—is substantial. Organizations that start early will execute smoother tests, generate better results, and demonstrate to their supervisors that they take operational resilience seriously.