TrustForge.pub

Author: Romain Muguet

1. Introduction: A Regulation Born from Necessity

The financial sector remains a high-value target for cybercriminals, hacktivists and state-aligned actors, with attacks growing in both sophistication and frequency. Data from ENISA’s 2025 Threat Landscape Report, released in October 2025, underscores the sector’s persistent exposure: out of 4,875 selected and curated cybersecurity incidents analysed for the period from July 2024 to June 2025, the finance sector accounted for 4.7% of all collected incidents. While this percentage may appear modest, the disproportionately high impact of disruption on critical digital infrastructure, payment systems, clearing mechanisms and retail banking amplifies the stakes beyond what raw numbers suggest. Phishing continues to dominate as the primary initial intrusion vector across the broader threat landscape, accounting for about 60% of observed cases. Within the finance sector specifically, hacktivist-led DDoS attacks dominated the threat picture, representing 83.5% of incidents, followed by cybercrime at 14.8% and state-aligned activity at 1.7%. Within cybercrime affecting financial institutions, data breaches accounted for 64%, while ransomware represented 36%.

The human dimension of this threat is equally striking. In the first half of 2025, Darktrace observed 2.4 million phishing emails within financial-sector customer deployments, with almost 30% aimed at VIP users.¹ Meanwhile, official reporting on Akira indicated approximately $244.17 million in claimed ransomware proceeds by late September 2025, with some incidents involving data exfiltration in just over two hours from initial access. ² Attackers are now weaponising newly disclosed vulnerabilities within days and increasingly leveraging AI-enabled tools to automate social engineering and malware development at scale.

It is against this backdrop that the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554 of 14 December 2022, applicable since 17 January 2025, must be understood. DORA is not simply a compliance framework.³ It is a legislative response to a structural problem: the financial sector’s digital defences, for all their sophistication, had long been governed by fragmented, inconsistent and largely reactive requirements. DORA sets out to change this by introducing one of the first EU sector-specific regulatory regimes to impose a detailed, binding and methodologically specific framework for digital operational resilience testing, including adversarial security testing through TLPT.

This article analyses DORA’s most significant legislative innovations, with particular focus on Threat-Led Penetration Testing (TLPT). It examines why these requirements are commendable and transformative, how they relate to existing frameworks, and what they signal for the financial industry, the cybersecurity profession, and the future of European digital regulation.

2. The Pre-DORA Landscape: Fragmentation as a Systemic Risk

To appreciate what DORA represents, one must first understand the regulatory environment it harmonised. For decades, the governance of digital risk in the EU financial sector was dispersed across a patchwork of national rules, supervisory expectations and sector-specific circulars. Germany, for example, had sector-specific IT supervisory requirements for banking, insurance undertakings, payment and e-money institutions, and asset managers, including BAIT, VAIT, ZAIT and KAIT. With DORA’s entry into application, BaFin repealed VAIT, ZAIT and KAIT with effect from 16 January 2025 to avoid double regulation.⁴ France had its own ACPR guidance and supervisory expectations. The European Banking Authority had also issued ICT security and outsourcing guidelines under the EU supervisory framework, but these still left room for national implementation and supervisory interpretation. Firms operating across multiple EU jurisdictions therefore had to navigate overlapping, and sometimes divergent, expectations. 

The consequences were predictable. Large international banks with dedicated regulatory affairs teams could map these divergences and adapt. Smaller institutions such as fintechs, payment service providers, electronic money institutions and crypto-asset firms often faced a heavier proportional burden in interpreting and operationalising these expectations. The concept of “digital operational resilience” existed in regulatory discourse, but its operational content could differ from Frankfurt to Amsterdam to Warsaw.

Regulations such as NIS2 and GDPR had already begun to build a European digital governance architecture, but neither was designed to address financial-sector operational resilience with the same level of specificity as DORA. GDPR focuses principally on personal data protection and privacy. NIS2 addresses cybersecurity risk management, supply-chain security and the assessment of security measures at a horizontal level across critical and important sectors. DORA goes further for the financial sector by introducing a directly applicable, finance-specific regime covering ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk management and information sharing. 

DORA harmonised much of this into a single, directly applicable regulation covering a broad range of financial entities. More importantly, it shifted the regulatory posture from reactive to proactive: not just “what do you do when something goes wrong?” but “how do you know your defences actually work?

3. DORA’s Five Pillars: Structure with Intent

DORA is built on five core pillars, each addressing a distinct dimension of digital operational resilience. Understanding them as a coherent architecture – rather than a checklist – is essential to grasping the regulation’s ambition.

ICT Risk Management establishes governance accountability at the highest level. The management body is given ultimate responsibility for managing ICT risk, and financial entities must implement comprehensive risk frameworks covering identification, protection, prevention, detection, response, recovery and learning. This is not novel in concept, but DORA’s insistence on management-body accountability marks a meaningful elevation of cybersecurity from a technical concern to a strategic one.

ICT-Related Incident Reporting introduces standardised incident reporting requirements, mandating that financial entities report major ICT-related incidents to competent authorities within tight deadlines. This ensures transparency and enables rapid response.

Digital Operational Resilience Testing is where DORA’s most innovative requirements reside. It establishes a two-tier testing regime: a baseline programme of regular, risk-based testing applicable to financial entities, and an advanced Threat-Led Penetration Testing regime applicable to financial entities identified by competent authorities on the basis of impact, systemic relevance, ICT risk profile, ICT maturity and technology-related criteria. This is the pillar explored in depth in the sections that follow.

Third-Party ICT Risk Management imposes strict obligations on financial entities to manage risks associated with ICT third-party service providers throughout the lifecycle of the relationship. This includes contractual safeguards, due diligence, ongoing monitoring, exit strategies, registers of information, management of concentration risk, and specific requirements for ICT services supporting critical or important functions. DORA also creates an EU oversight framework for ICT third-party service providers designated as critical by the European Supervisory Authorities.

Information Sharing enables financial entities to participate in arrangements for exchanging cyber threat information and intelligence, subject to safeguards on confidentiality, competition law, data protection and business secrecy. This collective dimension reflects a mature understanding that resilience is not only an individual institutional property, but can also be strengthened through trusted sector-wide collaboration.

4. Understanding the Testing Toolkit: Penetration Testing and Red Teaming

Before examining DORA’s specific testing requirements, it is worth establishing a clear conceptual foundation. The terms “penetration testing” and “red teaming” are frequently used interchangeably in professional discourse, but they describe meaningfully different exercises, and DORA treats them as such.

Penetration testing – often called ethical hacking – is a structured assessment in which authorised professionals attempt to identify and exploit vulnerabilities in an organisation’s ICT systems. The question it answers is: what weaknesses exist? Testing can be conducted with varying levels of prior knowledge: black box testing (no prior knowledge of the target, simulating an external attacker), white box testing (full knowledge of the system, enabling comprehensive internal assessment), or grey box testing (partial knowledge, a hybrid approach). Penetration tests are typically scoped to specific systems or applications, conducted over a defined period, and aimed at producing a catalogue of vulnerabilities for remediation.

Red teaming takes a fundamentally different perspective. It simulates real-world, multi-vector attacks against a target organisation with a specific strategic objective – accessing sensitive data, disrupting operations, exfiltrating funds – while attempting to evade detection. Where penetration testing asks “what vulnerabilities exist?”, red teaming asks: can we detect and stop a sophisticated attack? Red team exercises are longer, broader in scope, and designed to test not just technical defences but the organisation’s people, processes, and detection and response capabilities. Physical intrusion, social engineering, and supply chain exploitation may all be in scope. Red teaming is the operational core of Threat-Led Penetration Testing.

This distinction is critical because DORA does not treat these approaches as interchangeable. Its testing pillar combines a baseline programme of digital operational resilience testing, which may include penetration testing among other techniques, with an advanced TLPT regime for financial entities selected by competent authorities. Each layer answers a different and necessary question about the institution’s security posture.

5. DORA’s Testing Regime: A Two-Tier Architecture

DORA’s approach to testing is structured and graduated. Articles 24 and 25 establish the baseline programme: financial entities, other than microenterprises, must maintain a digital operational resilience testing programme and ensure that appropriate tests are conducted at least yearly on ICT systems and applications supporting critical or important functions. These tests may include vulnerability assessments and scans, open-source analyses, network security assessments, gap analyses, physical security reviews, questionnaires, scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.

Articles 26 and 27 then introduce the advanced TLPT regime for financial entities selected by competent authorities.⁵ TLPT is not simply a more intensive penetration test; it is an intelligence-led red team exercise conducted under a controlled regulatory framework and based on threat intelligence relevant to the tested entity and its threat landscape.

Unlike standard penetration tests, TLPT is performed under controlled secrecy: only the control team and designated stakeholders are aware that the exercise is taking place, while the wider detection and response teams are generally not informed, so that the test can generate realistic evidence on detection and response capabilities. It targets live production systems, within defined safeguards, and is grounded in bespoke and current threat intelligence rather than generic attack scenarios.

The DORA TLPT framework specifies the following key parameters:

• Frequency: At least every three years, with competent authorities able to require more frequent testing. This interval acknowledges the resource-intensive nature of full-scale TLPT exercises while ensuring that testing remains current.
• Scope: Several or all critical or important functions, and the ICT systems, services and processes supporting them, including relevant ICT services provided by third-party providers where they support those functions and fall within the agreed TLPT scope. This supply-chain reach is one of DORA’s most important innovations.
• Red team composition: Financial entities may use external testers or, subject to strict safeguards, internal testers. However, every third TLPT must be performed using external testers, and significant credit institutions must use external testers for every TLPT. 
• Pooling: Where several financial entities rely on the same ICT third-party service provider, DORA allows a pooled TLPT arrangement under defined conditions. This is a pragmatic acknowledgement that shared ICT dependencies can create shared resilience questions, and that testing common third-party services may be more efficient and more realistic when coordinated.

The level of methodological specificity embedded in these provisions is unusual for EU cyber regulation. DORA does not merely say “conduct advanced testing.” It defines the entities, functions, systems, testers, phases, deliverables, validation and supervisory attestation mechanisms that make TLPT legally and operationally meaningful.

6. TLPT Is Not New – But DORA Made It Law

One of the most analytically significant aspects of DORA’s TLPT provisions is that the underlying concept has a decade-long history. DORA did not invent intelligence-led adversarial testing, it conferred binding legal authority upon it.

The lineage begins with the Bank of England’s CBEST framework, formally launched in June 2014, one of the first formalised attempts to apply real threat intelligence to adversarial security testing in a financial-sector context.⁶ By grounding exercises in current intelligence about real adversaries, CBEST moved testing meaningfully closer to the threats institutions actually face.

The European Central Bank and the Eurosystem absorbed this insight and scaled it. In 2018, TIBER-EU – the Threat Intelligence-Based Ethical Red Teaming framework – was published, providing a pan-European methodology for intelligence-led testing. National implementations followed across Europe, including TIBER-NL, TIBER-BE, TIBER-DE, TIBER-FR, TIBER-DK and others. Significant financial institutions ran TIBER-style exercises, often under the encouragement or coordination of their supervisors.

Yet TIBER-EU remained entirely voluntary. In practice, participation was limited to the largest and most sophisticated institutions, those with the resources and supervisory relationships to make the programme work.

DORA changed the equation. It did not simply copy TIBER-EU into legislation; rather, it made TLPT a binding obligation for selected financial entities and used TIBER-EU as the methodological backbone through the DORA TLPT Regulatory Technical Standards.⁷ In February 2025, the Eurosystem updated TIBER-EU to align with the DORA TLPT RTS, confirming the framework’s transition from voluntary supervisory practice to a core reference for implementing a legal obligation.⁸ The relationship is therefore best understood as follows: DORA makes TLPT mandatory for identified entities, while TIBER-EU provides the operational methodology for performing TLPT in a controlled, consistent and safe manner.

This historical context matters because it strengthens, rather than diminishes, DORA’s significance. The regulation did not invent TLPT; it recognised a decade of practitioner and supervisory experience, formalised the approach through binding legal requirements, and broadened its application beyond the institutions that had voluntarily adopted TIBER-style testing. That is precisely what good regulation does.

7. DORA as a Blueprint: What Comes Next?

DORA should be read not only as a finished text but as a precedent. The model it establishes – sector-specific, methodologically prescriptive and linked to technical standards and supervisory frameworks that can evolve more flexibly than primary legislation – is likely to influence the next generation of European cyber regulation.

Several observations follow. The co-production approach, in which the TIBER-EU framework provides the technical backbone for DORA’s legal obligations, resolves a persistent tension between legislative generality and operational specificity. As cyber regulation evolves across other critical sectors – energy, healthcare, transport, telecommunications – this model offers a workable template.

DORA’s sectoral focus also raises the natural question of what follows. Financial services were the first target because of their systemic importance and advanced regulatory ecosystem. But the logic of mandatory adversarial testing, third-party supply chain oversight, and structured threat intelligence sharing applies with equal force to other sectors. NIS2 covers much of this ground but with considerably less prescription. DORA may well prove to be the highest-resolution template for sector-specific cyber resilience legislation across the EU’s critical infrastructure.

Finally, DORA’s cultural ambition deserves acknowledgement. The regulation consistently frames resilience not as a compliance outcome but as an operational posture. By embedding continuous, adversarially-informed testing into the legal fabric of the financial sector, it attempts to shift the industry’s self-understanding: not “are we compliant?” but “are we genuinely prepared?” That is a harder question, and DORA is right to insist on it.

8. Conclusion: A Landmark That Demands to Be Understood

DORA represents a turning point in European cybersecurity regulation. In an era of escalating phishing campaigns, AI-accelerated attacks, and ransomware groups extracting hundreds of millions in months, the financial sector’s need for proactive, adversarially-informed resilience has never been more acute.

DORA’s dual testing architecture – yearly appropriate testing of ICT systems and applications supporting critical or important functions, combined with periodic TLPT for financial entities selected by competent authorities – ensures that financial institutions do not merely catalogue vulnerabilities but actively validate their capacity to detect, contain and recover from sophisticated real-world attacks. The pooling provision can make this regime more viable where several financial entities use common ICT providers or infrastructures. The purple teaming phase required under the DORA TLPT RTS/TIBER-EU process helps transform findings into lasting capability improvements. The supply-chain reach of TLPT scope acknowledges that no institution’s resilience is greater than the resilience of the critical ICT dependencies on which it relies.

But DORA’s most enduring contribution may be the signal it sends beyond the financial sector: that advanced adversarial testing is no longer merely a luxury of the well-resourced, a voluntary aspiration of the security-conscious, or an informal expectation left to supervisory discretion. For financial entities selected under DORA’s TLPT regime, it is now a legal obligation. And in making it so, DORA does something rare for a regulatory text: it actively shapes the profession, the market and the culture it governs.

For practitioners, it is an invitation to build expertise the market has formally recognised. For institutions, it is a mandate to move from the question of whether they will be attacked to how well they will survive it. And for regulators elsewhere, it is a blueprint worth studying carefully.

1. Darktrace, “The State of Cybersecurity in the Finance Sector: Six Trends to Watch,” 2025, https://www.darktrace.com/blog/the-state-of-cybersecurity-in-the-finance-sector-six-trends-to-watch. ↩︎
2. Cybersecurity and Infrastructure Security Agency (CISA) et al., “StopRansomware: Akira Ransomware,” Joint Cybersecurity Advisory AA24-109A, last updated November 13, 2025, https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a. ↩︎
3. European Parliament and Council, Regulation (EU) 2022/2554 of 14 December 2022 on digital operational resilience for the financial sector. ↩︎
4. Deutsche Bundesbank and Federal Financial Supervisory Authority (BaFin), “BAIT / DORA information page on the repeal of VAIT, ZAIT and KAIT with expiry of 16 January 2025.” ↩︎
5. European Commission, Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on threat-led penetration testing. ↩︎
6. Bank of England, “Bank of England launches new framework to test for cyber vulnerabilities,” June 10, 2014. ↩︎
7. European Commission, Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 supplementing Regulation (EU) 2022/2554 with regard to regulatory technical standards on threat-led penetration testing. ↩︎
8. European Central Bank, “TIBER-EU Framework updated to align with DORA,” February 11, 2025. ↩︎