TLPT vs Traditional Penetration Testing: What DORA Article 26 Actually Requires

Two Testing Regimes, Two Different Objectives

DORA establishes two distinct testing obligations under Pillar III (Digital Operational Resilience Testing), and they are fundamentally different in scope, methodology, cost, and regulatory intent. Treating them as interchangeable — or worse, assuming that existing penetration testing satisfies both — is a compliance failure that supervisors will identify immediately.

Article 25 establishes the baseline: all financial entities must implement a programme of digital operational resilience testing proportionate to their size, risk profile, and the criticality of their ICT services. This includes vulnerability assessments, network security evaluations, gap analyses, source code reviews, scenario-based testing, compatibility testing, performance testing, and penetration testing.

Article 26 creates an entirely separate obligation: threat-led penetration testing (TLPT). This is not a more thorough version of Article 25 penetration testing. It is a different class of exercise with different objectives, different governance, different teams, and different regulatory oversight.

The distinction matters because they test different things. Traditional penetration testing asks: can an attacker exploit known vulnerabilities in our systems? TLPT asks: can a sophisticated, intelligence-driven adversary compromise our critical functions despite our detection and response capabilities?

What Traditional Testing Under Article 25 Requires

Article 25 testing is the foundation. Every in-scope entity — regardless of size — must maintain a testing programme. The regulation specifies a non-exhaustive list of testing types that should be performed "at least yearly" (Art. 25(1)).

The key elements include:

• Vulnerability assessments and scans across all ICT systems supporting critical functions
• Network security assessments including architecture reviews and configuration audits
• Gap analyses between documented security policies and actual implementation
• Source code reviews where applicable, particularly for bespoke or heavily customized applications
• Scenario-based testing simulating plausible disruption events
• Compatibility testing for software and hardware changes
• Performance testing under stress and peak load conditions
• Penetration testing of externally accessible and internally critical systems

These are familiar activities for most institutions with mature information security programmes. The regulatory novelty is not in the testing types themselves but in the requirement to maintain a formal, documented, risk-proportionate programme with results that feed into the ICT risk management framework (Art. 25(4)).

Art. 25(3) requires that the testing programme "include a range of tests, tools and methodologies" appropriate to the entity's ICT landscape. Supervisors will evaluate not just whether testing occurred but whether the programme covers the entity's actual risk surface — including third-party dependencies (Art. 25(2)).

What TLPT Under Article 26 Demands

TLPT is categorically different. Article 26(1) specifies that certain financial entities shall "carry out at least every 3 years advanced testing by means of TLPT." The adjective advanced is deliberate. TLPT is not penetration testing with a longer engagement window.

The Three-Team Structure

TLPT requires three distinct teams operating under strict separation:

The threat intelligence team produces a bespoke threat intelligence report analysing the specific threat landscape of the target institution. This is not a generic threat briefing. It identifies the most relevant threat actors, their tactics, techniques, and procedures (TTPs), and the attack scenarios most likely to be deployed against the entity's critical functions. The intelligence drives the entire test — without it, what remains is just a penetration test with a larger scope.

The red team (external testers) executes the attack scenarios defined by the threat intelligence. Art. 26(2) is explicit: TLPT must "cover several or all critical or important functions of a financial entity, and shall be performed on live production systems." This is not a test environment exercise. The red team operates against production infrastructure, attempting to achieve objectives that would represent genuine compromise of critical functions — data exfiltration, transaction manipulation, service disruption, or lateral movement to interconnected systems.

The white team (internal coordinators) manages the exercise from the entity's side. Only the white team knows the test is occurring. The entity's security operations centre, incident response teams, and IT operations are deliberately kept uninformed (the "blue team"). This is the defining characteristic of TLPT: it tests detection and response capabilities under realistic conditions where defenders do not know they are being tested.

Who Must Perform TLPT

Not every financial entity is subject to Article 26. Art. 26(8) specifies that competent authorities shall identify which entities must perform TLPT based on:

• The entity's risk profile and systemic importance
• The maturity of its ICT risk management
• The criticality of the ICT services, functions, and activities involved
• Any other factors the competent authority considers relevant

In practice, this means large banks, central counterparties, central securities depositories, trading venues, and systemically important payment institutions will almost certainly be designated. Mid-tier institutions may be designated based on their specific risk profiles. Small entities will generally be exempt, though supervisors retain discretion.

Frequency and Scope

TLPT must be performed at least every three years (Art. 26(1)). However, supervisors may require more frequent testing for entities with elevated risk profiles. Each TLPT cycle must cover "several or all critical or important functions" — the scope cannot be limited to a single application or network segment. The test must exercise the entity's ability to detect and respond to a realistic adversary operating across its critical infrastructure.

NCA Involvement

Unlike traditional penetration testing, TLPT involves the national competent authority directly. Art. 26(4) requires entities to notify their NCA before commencing TLPT and to submit results upon completion. The NCA may:

• Validate the scope and approach
• Require adjustments to ensure adequate coverage
• Review the threat intelligence report
• Assess the entity's remediation plan
• Use results to inform supervisory assessments

This regulatory oversight transforms TLPT from a technical exercise into a supervised assurance activity. The NCA is not a passive recipient of reports — it is an active stakeholder in the process.

Tester Qualifications: Article 27

Article 27 establishes specific requirements for TLPT testers that go well beyond standard penetration testing qualifications:

• Independence: Testers must be external to the financial entity. Internal red teams may participate but cannot lead the exercise. Art. 27(1)(a) requires testers that are "of the highest suitability and reputability."
• Technical capability: Testers must demonstrate expertise in threat intelligence, penetration testing, and red teaming. Generic IT audit firms do not qualify.
• Accreditation: Testers must carry relevant certifications or demonstrate equivalent competence. Art. 27(1)(b) references certification by an accreditation body or adherence to formal codes of conduct.
• Professional indemnity insurance: Art. 27(1)(c) requires appropriate insurance covering risks arising from the testing, including potential damage to production systems.
• Conflict of interest management: Testers must not have conflicts of interest with the entity's ICT service providers or the entity itself.

These requirements significantly narrow the pool of qualified TLPT providers. In most EU markets, fewer than a dozen firms meet all criteria, which has implications for availability, scheduling, and cost.

The TIBER-EU Connection

TLPT under DORA builds directly on the TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming), developed by the European Central Bank. TIBER-EU established the three-team model, the threat-intelligence-led approach, and the regulatory oversight structure that DORA now codifies into law.

Financial entities that have already participated in TIBER-EU, TIBER-DE, TIBER-NL, or similar national implementations will find the DORA TLPT requirements familiar. However, DORA adds legal enforceability — participation is no longer voluntary for designated entities.

The purple teaming phase — where red and blue teams collaborate post-exercise to share findings and improve detection capabilities — is an established TIBER-EU practice that DORA implicitly encourages through its requirement that TLPT results feed into the ICT risk management framework (Art. 26(6)).

Evidence and Documentation Requirements

TLPT produces substantial documentation that must be retained and made available to supervisors:

• Threat intelligence report: The bespoke analysis driving the test scenarios
• Red team test plan: Objectives, scope, attack vectors, rules of engagement
• Execution log: Detailed record of red team activities, including timestamps, techniques used, systems accessed, and data handled
• Findings report: Vulnerabilities exploited, detection gaps identified, response deficiencies
• Remediation plan: Specific corrective actions with owners, timelines, and success criteria
• Attestation: Formal confirmation from the NCA or designated authority that the TLPT was conducted in accordance with DORA requirements (Art. 26(7))

This evidence chain must demonstrate not just that the test occurred but that it was conducted with sufficient rigour, scope, and realism to provide meaningful assurance about the entity's resilience posture. Platforms that manage resilience testing evidence with integrity verification, chain-of-custody tracking, and structured metadata — such as Valendir — can significantly reduce the administrative burden of TLPT documentation and NCA reporting.

Budget Implications

TLPT is significantly more expensive than traditional penetration testing. Based on industry benchmarks and editorial estimates for a mid-size financial institution:

Over a three-year cycle, this represents EUR 80,000-170,000 per year in annualized TLPT costs — a material budget line that must be planned for. Institutions that have never participated in TIBER-EU or equivalent programmes should expect costs at the higher end of these ranges for their initial cycle.

Practical Recommendations

For institutions navigating both testing obligations:

1. Separate your testing programmes: Maintain distinct governance tracks for Art. 25 (ongoing testing) and Art. 26 (TLPT). They have different frequencies, teams, methodologies, and reporting structures.

1. Start TLPT procurement early: The pool of qualified TLPT providers is limited. Engagement timelines of 6-12 months from RFP to test completion are common. If your next TLPT cycle falls within 18 months, begin vendor selection now.

1. Invest in threat intelligence: The quality of the threat intelligence report determines the quality of the entire TLPT exercise. Generic threat briefings produce generic tests. Bespoke, entity-specific intelligence produces meaningful assurance.

1. Plan for remediation: Budget for fixing what the red team finds. The most common mistake is allocating budget for the test but not for the remediation. Findings without corrective actions are findings that will recur.

1. Coordinate with your NCA: Early engagement with your competent authority on TLPT scope, timing, and provider selection can prevent costly rework and demonstrate good faith compliance.

The institutions that treat TLPT as a strategic investment in resilience — rather than a regulatory box to check — will extract genuine security value from the exercise. Those that cut corners will discover, often through a real incident, that the exercise was worth every euro.

---

This guide reflects DORA requirements as published. Regulatory Technical Standards on TLPT are expected to provide additional implementation detail. Financial entities should monitor ESA publications and NCA guidance for jurisdiction-specific requirements.