2026-04-20·13 min read·

DORA Art.45–46: Threat-Led Penetration Testing (TLPT) Requirements for Financial Services — Developer and Security Guide 2026

Post #490 in the sota.io EU Cyber Compliance Series

The EU Digital Operational Resilience Act (DORA) creates two tiers of ICT testing. Basic testing — vulnerability assessments, network scans, penetration tests — applies broadly. Advanced testing under Articles 45 and 46 applies only to the most significant financial entities and is qualitatively different: it requires red-team exercises against live production environments, conducted by certified external testers operating on the basis of actual threat intelligence.

This is Threat-Led Penetration Testing (TLPT). If your financial services organisation is in scope, a TLPT is not a checkbox exercise. It is a structured, multi-month engagement that tests whether real attackers, using real tactics, can breach your real production systems. This guide explains what TLPT requires under DORA, who must comply, and what the ESA Joint Regulatory Technical Standard (RTS) on TLPT means in practice.

The Two-Tier Testing Structure Under DORA

DORA Chapter IV creates a layered digital resilience testing framework:

Tier 1 — Basic testing (Art.25–26, all financial entities):

Vulnerability assessments and scans
Open source analyses
Network security assessments
Gap analyses
Physical security reviews
Questionnaires and software solution scans
Source code reviews where feasible
Scenario-based testing

Tier 2 — Advanced TLPT (Art.45, significant financial entities only):

Full red-team engagement against live production systems
Based on real threat intelligence gathered on the specific entity
External certified testers mandatory (with limited internal supplementation under Art.46)
Coordinated with competent authorities
Every three years minimum frequency

The critical distinction: basic testing can be performed against test environments with anonymised data. TLPT under Art.45 must target live production systems. The rationale is that adversaries do not test against staging environments.

Who Must Conduct TLPT: The Significance Thresholds

Art.45(1) states that TLPT applies to financial entities "identified as significant" by their competent authority. The designation follows criteria established across the sectoral financial legislation, not a single DORA threshold. Competent authorities assess:

Systemic importance: entities whose failure would affect market stability
Customer base scale: large retail deposit holders, large investment portfolios
Interconnectedness: significant clearing, settlement, or payment infrastructure roles
ICT risk profile: entities with complex, highly integrated ICT architectures

Financial entity categories typically subject to TLPT designation:

Category	Typical significance threshold	Regulatory reference
Credit institutions	Significant institutions under SSM / large domestic banks	CRR + DORA Art.45
Investment firms	Systemically important or large balance sheet	MiFID II + DORA
CCPs	All EU-authorised CCPs	EMIR + DORA
CSDs	All EU-authorised CSDs	CSDR + DORA
Insurance / reinsurance	Large undertakings (Solvency II threshold)	Solvency II + DORA
Payment institutions	Significant by transaction volume	PSD2 + DORA
Crypto-asset service providers	Significant CASPs under MiCA	MiCA + DORA

Art.45(2) also permits competent authorities to require TLPT of entities below the significance threshold when the authority determines their ICT risk profile warrants it.

Smaller entities and proportionality: Art.45(1) explicitly allows competent authorities to exempt small non-interconnected investment firms and other less significant entities from mandatory TLPT. The exemption is authority-granted, not self-assessed — if you have not received explicit confirmation, assume TLPT may apply.

The ESA Joint RTS on TLPT

The European Banking Authority (EBA), European Securities and Markets Authority (ESMA), and European Insurance and Occupational Pensions Authority (EIOPA) jointly published the Regulatory Technical Standard on TLPT under DORA Art.26(11) (the DORA cross-reference to Art.45 testing standards) and Art.45(8).

The RTS specifies:

Criteria for threat intelligence providers — who is qualified to produce the intelligence basis for TLPT
Tester requirements — qualifications, certifications, independence, liability
Scope determination methodology — how the threat intelligence informs test scope
Execution standards — red team conduct, communications protocols, deconfliction with SOC
Pooled testing arrangements — how multiple entities sharing an ICT provider can conduct a single coordinated TLPT
Competent authority involvement — notification requirements, authority participation rights

The RTS builds directly on the TIBER-EU framework published by the European Central Bank. TIBER-EU (Threat Intelligence-Based Ethical Red-Teaming) was the predecessor voluntary framework; DORA Art.45 makes equivalent testing mandatory for significant entities.

TLPT Phase Structure: What a Compliant Engagement Looks Like

A DORA-compliant TLPT follows a structured phased approach derived from TIBER-EU:

Phase 1: Preparation (4–8 weeks)

Scope definition: The entity defines the Generic Target of Evaluation (GTEM) — the crown-jewel systems, processes, and functions that, if compromised, would cause the most significant operational or financial damage. The GTEM typically includes:

Core banking / trading systems
Payment processing infrastructure
Customer authentication systems
Market data and order management systems
Key internal communication platforms

Threat intelligence procurement: A qualified Threat Intelligence Provider (TIP), independent of the red team, researches and produces:

An entity-specific threat landscape assessment
Actor profiles of threat groups known to target the financial sector
Tactics, Techniques, and Procedures (TTPs) documented in the threat intelligence report
Specific attack scenarios derived from actual adversary tradecraft against comparable entities

The TIP's output drives the red team's targeting choices. This is the key differentiator from generic penetration testing: TLPT simulates the adversaries most likely to actually attack your organisation, using the methods they actually use.

Competent authority notification: The entity notifies its competent authority before TLPT commences. Art.45(3) grants competent authorities the right to participate in the oversight of TLPT execution, and to require specific adjustments to scope or approach.

Phase 2: Test Execution (8–12 weeks)

Red team operations: The external red team, working from the TIP's threat intelligence, conducts a full-scope adversarial simulation. Operations are:

Conducted against live production systems (not test environments)
Using real adversary TTPs from the intelligence report
Without informing operational IT and security staff (the "white team" — typically senior management and the CISO — knows; the SOC does not)
Documented continuously in a detailed red team log

Purple team phase (optional but common): After initial red team operations, many TLPT engagements include a collaborative purple team phase where the red team reveals specific techniques to the defensive team, enabling measurement of detection and response capability.

Deconfliction: The white team maintains a deconfliction channel. If red team activity causes unexpected operational disruption, the white team can pause or redirect operations without revealing the exercise to the SOC. This is critical for live production testing safety.

Phase 3: Closure and Reporting (4–6 weeks)

Final reports: Three documents are produced:

Red team report — full technical record of red team operations, TTPs used, access achieved, vulnerabilities exploited
Blue team report — assessment of detection, alerting, and response to red team activity (produced by the defensive team after the exercise is revealed)
Summary report — executive-level findings, remediation priorities, submitted to competent authority

Remediation planning: Art.45(7) requires entities to address critical vulnerabilities identified in TLPT. The competent authority may review the remediation plan and, where the authority participated in TLPT oversight, may require specific remediation timelines.

Art.46: Tester Requirements

Art.46 sets requirements for the external testers conducting TLPT. Key provisions:

Independence requirements (Art.46(1)): External testers may not have conducted work for the financial entity within three years prior to TLPT engagement for functions covered by the test scope. This prevents testing teams from effectively auditing their own prior recommendations.

Internal tester supplementation (Art.46(2)): After the first TLPT cycle — i.e., after completing one external TLPT — entities may supplement future engagements with internal red team staff, but:

The lead tester must remain external
Internal testers must meet equivalent qualification standards to external testers
The competent authority must approve internal tester participation
This "hybrid" approach is not available for the first TLPT cycle

Qualification criteria (per RTS): The ESA RTS specifies that testers must demonstrate:

Relevant certifications (CREST CRT, CREST CCSAS, CHECK Team Leader, or equivalent national equivalents recognised in the relevant EU member state)
Experience in adversarial simulation operations
Track record in financial services sector engagements
Adequate professional indemnity insurance
Absence of conflicts of interest, including supply chain relationships with the target entity's ICT providers

Liability: Art.46(5) provides that financial entities remain responsible for regulatory compliance outcomes even when external testers are used. The tester contract should address liability for operational disruption caused by red team activity during production testing.

Pooled Testing: ICT Third-Party Providers

Art.45(5) introduces a practical accommodation for the shared ICT infrastructure reality of financial services: pooled testing.

When multiple financial entities rely on the same critical ICT third-party provider, and each entity's TLPT would necessarily target that provider, the entities may coordinate a single pooled TLPT against the shared provider.

Pooled TLPT mechanics:

All participating entities must agree to the scope
The pooled test must still be entity-specific in its intelligence basis — the TIP produces threat profiles for each participating entity
The red team tests the shared provider infrastructure, but from the perspective of each entity's threat model
Each entity receives its own final report sections covering its specific systems and access paths
Competent authorities of each participating entity must be individually notified and may each participate in oversight

Why this matters for cloud-hosted financial services: If your financial application is hosted on a third-party cloud platform, that platform is a potential TLPT target when your entity is designated significant. Under pooled testing, multiple bank customers of the same EU cloud provider could coordinate a single TLPT engagement targeting the shared infrastructure, rather than each entity separately contracting red teams to test the same underlying systems.

For EU-hosted financial services using EU-native cloud infrastructure, this coordination is materially simpler: a single EU-jurisdiction engagement, governed by EU law, without the cross-border legal complexity that arises when the shared ICT provider is a US-headquartered company subject to US legal process.

TLPT Frequency and Record-Keeping

Minimum frequency: Art.45(1) requires TLPT at least every three years. Competent authorities may require more frequent testing based on the entity's risk profile.

Clock reset: A new three-year cycle begins from the date the competent authority acknowledges receipt of the final TLPT summary report (or, in frameworks where authority sign-off is explicit, from the sign-off date).

Record retention: Art.45(6) requires entities to retain TLPT documentation for a minimum of five years from the test completion date, including red team logs, TIP reports, blue team reports, and remediation evidence.

Cross-border recognition: Art.45(4) provides for mutual recognition of TLPT results across EU member states. A TLPT conducted under the supervision of the French ACPR is recognised by the German BaFin for entities operating in both jurisdictions, avoiding duplicative testing against the same systems. The competent authority that supervised the original TLPT issues a certificate of TLPT completion recognised by other member state authorities.

Practical Preparation: What Financial Service Developers and Architects Need to Know

Production environment access is mandatory — plan accordingly: If your systems will be subject to TLPT, the red team requires realistic access paths. Hardened test environments or anonymisation layers that would mask real vulnerabilities are not compliant. Your architecture must permit controlled external actor simulation against production systems, with appropriate deconfliction mechanisms.

Document your ICT asset inventory now: TLPT scope is derived from your business-critical functions. An accurate, current inventory of ICT assets supporting critical functions is a prerequisite for meaningful scope definition. DORA Art.8 (ICT asset management) supports this requirement, but TLPT preparation exposes gaps in asset documentation that basic ICT risk management may not surface.

Identify your white team: The white team — the small group of senior people who know the test is occurring — must be established before TLPT commences. This typically includes: CISO or Head of Information Security, CTO, CRO (for liaison with competent authority), and one or two senior IT infrastructure leads who can operate the deconfliction channel.

Engage early with TIP market: The qualified threat intelligence providers capable of producing DORA-compliant entity-specific threat intelligence reports are a relatively small market. Significant entities should identify and qualify TIP vendors well before their TLPT timeline requires their output.

Third-party contract review: If your production systems involve critical ICT third-party providers — cloud platforms, data centres, network providers — review whether your contracts permit the access required for TLPT. Art.28 (DORA contractual requirements for ICT third-party providers) requires that contracts include provisions permitting audits and testing, but the specific TLPT context should be confirmed. For providers under pooled testing arrangements, co-ordination provisions must be explicitly addressed.

DORA Testing Timeline: Where Art.45–46 Fits

DORA provision	Testing type	Scope	Frequency	Who
Art.25	Basic testing (vulnerability, network)	All financial entities	Annual minimum	Internal or external
Art.26	Penetration testing	All financial entities above threshold	Annual minimum	Internal or qualified external
Art.45	TLPT — advanced testing	Significant financial entities (designated)	Minimum every 3 years	External certified testers (Art.46)
Art.46	Tester qualifications	As above	Per TLPT engagement	External + optional internal after first cycle

DORA's basic testing obligations (Art.25–26) applied from January 17, 2025 — the DORA general application date. The advanced TLPT requirements under Art.45–46 also apply from January 17, 2025, but the designation process for significant entities and the first TLPT cycle scheduling means the first TLPT engagements for most entities will run through 2025–2026.

EU Infrastructure and TLPT Simplification

DORA Art.45–46 creates a specific coordination burden around third-party ICT providers. For financial entities operating on US-headquartered cloud infrastructure, TLPT raises questions that do not arise on EU-native infrastructure:

CLOUD Act conflict: Red team operations that access data on US-company servers may intersect with US legal process in ways that are not fully resolved under EU-US data agreements
Cross-jurisdiction deconfliction: When a red team tests infrastructure operated by a US company's EU subsidiary, the legal authority for deconfliction coordination spans two jurisdictions
Pooled testing coordination: Co-ordinating a pooled TLPT with a non-EU provider's compliance team adds cross-border legal review requirements that are absent when the shared provider is EU-headquartered

Financial services entities choosing EU-native cloud infrastructure — providers headquartered in the EU, operating exclusively under EU law — simplify the TLPT third-party coordination layer. The red team, the target entity, the shared provider, and the competent authorities all operate under the same legal framework.

Key Takeaways

DORA Art.45 mandates TLPT for significant financial entities — real red-team exercises against live production systems, every three years minimum.
Art.46 requires external certified testers; internal supplementation is permitted only after the first completed TLPT cycle.
The ESA Joint RTS on TLPT specifies tester qualifications, threat intelligence standards, scope methodology, and pooled testing arrangements.
TLPT is not an extension of basic penetration testing. It begins with entity-specific threat intelligence and targets production systems with real adversary TTPs.
Pooled testing reduces duplicative testing load when multiple financial entities share critical ICT third-party providers.
EU-native cloud infrastructure simplifies the third-party coordination and legal framework that TLPT requires.

DORA TLPT obligations are already in force. Significant financial entities that have not yet begun scoping their first TLPT cycle should treat this as an urgent gap, not a deferred compliance item.