DORA Penetration Testing Requirements: TLPT, TIBER-EU, and What Financial Entities Must Know

DORA Changes the Rules for Financial Sector Security Testing

The Digital Operational Resilience Act (DORA), which became applicable on January 17, 2025, introduces the most prescriptive penetration testing requirements in any regulatory framework globally. Unlike HIPAA's technology-neutral approach or SOC 2's implicit expectations, DORA explicitly mandates penetration testing and defines exactly what form that testing must take for significant financial entities.

DORA applies to virtually the entire EU financial sector: credit institutions, investment firms, insurance and reinsurance undertakings, payment institutions, crypto-asset service providers, and -- critically -- ICT third-party service providers that serve them. The regulation establishes two tiers of security testing: standard resilience testing for all entities and threat-led penetration testing (TLPT) for those identified as significant.

For organizations accustomed to annual penetration testing as a compliance checkbox, DORA introduces a fundamentally different paradigm. TLPT is not a vulnerability assessment with a cover page. It is a structured, intelligence-driven red team exercise that tests an organization's ability to detect, respond to, and withstand a realistic cyberattack against its most critical functions.

The Two Tiers of DORA Security Testing

DORA establishes a layered approach to resilience testing under Chapter IV, Articles 24 through 27.

Tier 1: Digital Operational Resilience Testing (All Entities)

Article 24 requires all financial entities (except micro-enterprises) to establish, maintain, and review a digital operational resilience testing program. This baseline program must include:

• 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

This is not a menu where entities pick their preferred options. Article 24(2) states that the program shall include "all of" these elements as appropriate to the entity's size, risk profile, and the nature and complexity of its ICT services.

Standard penetration testing under Tier 1 should follow a risk-based approach: testing the systems and applications that pose the greatest risk to the entity's critical functions. The frequency is at least annual for critical systems.

Tier 2: Threat-Led Penetration Testing (Significant Entities)

Articles 26 and 27 introduce TLPT -- a requirement that applies only to financial entities identified by their competent authority as significant. TLPT goes well beyond standard penetration testing in scope, methodology, and rigor.

Understanding Threat-Led Penetration Testing

TLPT is built on the TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) framework developed by the European Central Bank. DORA effectively codifies TIBER-EU into law for designated financial entities.

What Makes TLPT Different from Standard Penetration Testing

A standard penetration test identifies vulnerabilities and attempts to exploit them, typically within a defined scope and with the knowledge of the security team. TLPT is fundamentally different in several dimensions:

Intelligence-driven scope. The scope of a TLPT is determined by threat intelligence, not by the entity or its auditor. A threat intelligence provider analyzes the entity's threat landscape and produces a targeted threat intelligence report that identifies the most realistic and impactful attack scenarios. The red team then executes those specific scenarios.

Live production testing. DORA Article 26(2) explicitly requires that TLPT be performed on live production systems supporting critical functions. Testing against staging environments or isolated copies does not satisfy the requirement. This is a significant departure from standard penetration testing, where production testing is often avoided due to operational risk.

Full attack simulation. TLPT covers the full attack lifecycle: initial access, lateral movement, privilege escalation, data exfiltration, and -- critically -- testing the entity's detection and response capabilities. The red team does not stop at identifying a vulnerability. They exploit it, move through the environment, and attempt to achieve objectives that a real adversary would pursue.

Blue team testing. Unlike standard penetration tests where the security team may be informed, TLPT tests the blue team (defensive security operations) without their knowledge. The goal is to evaluate whether the entity's detection, monitoring, and incident response capabilities would identify and respond to a real attack.

Purple team conclusion. After the red team phase, DORA requires a purple team exercise where the red team and blue team work together to review findings, understand attack paths, and improve defenses. This collaborative phase transforms the exercise from a pass/fail test into a learning opportunity.

TLPT vs. Standard Penetration Testing

Dimension	Standard Pentest	TLPT
Scope definition	Organization-defined	Threat intelligence-driven
Target systems	Agreed scope, often staging	Live production, critical functions
Blue team awareness	Usually informed	Not informed
Methodology	Tester's methodology	TIBER-EU framework
Duration	1-4 weeks typical	12+ weeks typical
Intelligence phase	Optional	Mandatory
Purple team phase	Optional	Mandatory
Regulatory oversight	None	Competent authority involvement
Frequency	Annual	Every 3 years

For a broader understanding of how red team engagements differ from standard penetration testing, our comparison article covers the spectrum of security testing approaches.

Which Entities Must Perform TLPT

Article 26(8) empowers competent authorities to identify financial entities that are required to perform TLPT. The identification criteria include:

• Impact-related factors (systemic importance, criticality to the financial sector)
• Financial stability concerns
• ICT risk profile and ICT maturity level
• Specific characteristics of the entity's operations

In practice, the following types of entities are most likely to be designated for TLPT:

• Significant credit institutions as classified by the ECB under the Single Supervisory Mechanism
• Global systemically important institutions (G-SIIs) and other systemically important institutions (O-SIIs)
• Central securities depositories and central counterparties
• Large payment institutions and electronic money institutions
• Major insurance and reinsurance undertakings
• Trading venues and data reporting service providers

Smaller financial entities -- those not designated by their competent authority -- are not required to perform TLPT. They must still perform standard penetration testing under the Tier 1 requirements of Article 24.

TLPT Scope Requirements

DORA defines specific scope requirements for TLPT that go beyond what most organizations are accustomed to in standard penetration testing.

Critical or Important Functions

Article 26(1) mandates that TLPT must cover several or all critical or important functions of the financial entity. "Critical or important functions" is a defined term under DORA Article 3(22): a function whose disruption would materially impair the financial performance, the soundness or continuity of services, or whose discontinued, defective, or failed performance would materially impair the entity's compliance with regulatory requirements.

This means the TLPT must target the systems, processes, and technologies that the entity depends on for its core business operations and regulatory compliance.

ICT Third-Party Service Providers

Article 26(3) introduces one of DORA's most consequential provisions: where critical or important functions are supported by ICT third-party service providers, the TLPT scope must include those providers. The financial entity must involve the ICT provider in the testing, and the provider must cooperate.

This creates a cascading obligation. If a bank's core banking platform is hosted by a cloud provider, and the cloud infrastructure supports a critical function, the TLPT may need to include testing of the cloud provider's environment. The financial entity cannot exclude critical third-party dependencies from its TLPT scope simply because they are managed by a vendor.

However, Article 26(4) provides an alternative: where the inclusion of an ICT third-party service provider in the TLPT could cause risk to the quality or security of services to other clients, the financial entity and the provider may agree that the provider undergoes a separate pooled TLPT, the results of which are shared with the financial entity.

Live Production Systems

DORA is explicit that TLPT must be performed on live production systems. This requirement reflects the regulation's focus on operational resilience rather than theoretical security. Testing against a replica environment tells you whether the replica is secure -- it tells you nothing about whether your detection and response capabilities work in the actual production environment.

This does not mean the red team has carte blanche to disrupt production services. The testing framework includes controls, escalation procedures, and emergency stop mechanisms. But the testing must use the real infrastructure, the real monitoring, and the real security team.

TLPT Execution Framework

DORA Article 27 establishes requirements for TLPT execution that align with the TIBER-EU framework.

Phase 1: Preparation

The financial entity establishes a control team -- a small group of senior individuals who manage the TLPT process. The control team works with the competent authority to confirm scope, timeline, and rules of engagement. The control team is the only internal group aware that a TLPT is occurring.

Phase 2: Threat Intelligence

An external threat intelligence provider produces a targeted threat intelligence report specific to the financial entity. This report identifies realistic threat scenarios based on the entity's sector, geography, technology stack, and known adversary capabilities. The threat intelligence drives the red team's engagement plan.

Phase 3: Red Team Execution

External testers (the red team) execute the attack scenarios defined by the threat intelligence phase. The red team operates covertly, without the knowledge of the entity's defensive security team. The execution phase typically spans 12 or more weeks and covers the full kill chain from initial reconnaissance through objective achievement.

Phase 4: Closure

After the red team phase concludes:

1. The red team produces a detailed report documenting attack paths, techniques, findings, and outcomes
2. A purple team exercise brings together the red team and blue team to review findings and develop remediation plans
3. The financial entity produces a summary report and remediation plan
4. The competent authority reviews the results and may provide feedback

Phase 5: Attestation

Article 26(7) states that after the completion of TLPT, the competent authority shall provide the entity with an attestation confirming that the test was performed in accordance with the requirements. This attestation can be shared with other competent authorities to enable mutual recognition and avoid duplicative testing.

Tester Qualification Requirements

DORA Article 27 establishes stringent requirements for TLPT testers.

External Testers Required

TLPT must be performed by external testers. Unlike some standards that permit qualified internal teams, DORA requires independent external providers for the red team engagement. The threat intelligence provider must also be external.

Internal testers may participate alongside external testers in certain circumstances (Article 27(1)(a)), but the external testing firm must lead the engagement.

Tester Qualifications

External testers must demonstrate:

• Highest suitability and reputability
• Technical and organizational capabilities, specifically in threat intelligence, penetration testing, and red team testing
• Certification by an accreditation body in a Member State, or adherence to formal codes of conduct or ethical frameworks
• Independent assurance or audit report relating to the sound management of risks associated with TLPT, including protection of confidential information and the entity's business operations
• Professional indemnity insurance covering risks arising from the TLPT

These requirements effectively limit the pool of qualified TLPT providers to established firms with demonstrated red team capabilities, regulatory experience, and appropriate insurance coverage.

Frequency and Ongoing Obligations

DORA requires designated financial entities to perform TLPT at least every three years. This is less frequent than annual penetration testing, reflecting the significantly greater scope, cost, and operational impact of TLPT.

However, the three-year TLPT cycle does not replace the requirement for ongoing resilience testing under Article 24. Standard penetration testing, vulnerability assessments, and other testing activities must continue on their regular cadence between TLPT exercises.

After each TLPT, the financial entity must implement all remediation actions identified during the engagement. The competent authority monitors remediation progress and may require status updates.

Third-Party Provider Obligations

DORA's treatment of ICT third-party service providers creates significant implications for technology vendors serving the financial sector.

Contractual Requirements

Article 30 mandates that contracts between financial entities and ICT third-party service providers include provisions for:

• Cooperation with the entity's resilience testing program
• Participation in TLPT where the provider supports critical functions
• Right of the entity (and its competent authority) to access, inspect, and audit the provider

Subcontracting Chain

DORA extends these obligations through the subcontracting chain. If a cloud provider subcontracts infrastructure to another provider, and that infrastructure supports a financial entity's critical function, the subcontractor may also be subject to testing requirements.

For more on how DORA's requirements extend to domain security and digital infrastructure, see our DORA compliance domain security guide.

Practical Implications for Financial Entities

Start Planning Early

A TLPT engagement from planning through attestation typically spans six to nine months. Organizations designated for TLPT should begin planning at least twelve months before their target completion date to allow time for threat intelligence procurement, red team selection, scope validation with the competent authority, and remediation after the exercise.

Budget Appropriately

TLPT is substantially more expensive than standard penetration testing. The combination of threat intelligence, an extended red team engagement (12+ weeks), purple teaming, and regulatory coordination means that TLPT budgets for significant financial institutions typically range from six to seven figures, depending on scope and complexity.

Coordinate with Third Parties

If critical functions depend on ICT third-party providers, engage those providers early. Contractual provisions for TLPT cooperation should be in place before the testing cycle begins. Negotiating access and rules of engagement with a cloud provider during the TLPT itself creates delays and scope gaps.

Prepare Your Blue Team (Without Telling Them)

The paradox of TLPT is that you must prepare your defensive capabilities without revealing that a test is imminent. This means investing in detection engineering, incident response playbooks, and SOC analyst training as an ongoing program -- not as TLPT-specific preparation. If your blue team is only effective when they know they are being tested, TLPT will expose that gap.

Next Steps

If your financial entity has been designated for TLPT or you anticipate designation, the time to begin preparing is now. If you are subject to DORA's Tier 1 requirements and need to establish a resilience testing program, standard penetration testing is the foundation.

If you are evaluating whether your organization needs a penetration test, DORA compliance is a clear and unambiguous driver -- the regulation does not leave room for interpretation.

Our Penetration Testing Scoping Wizard helps you define the scope of your testing program, whether you are preparing for standard resilience testing or building toward TLPT readiness. And our services team can help you navigate the requirements, select qualified providers, and build a testing program that meets DORA's demanding standards.