Nov 05, 2026
Penetration Testing for Financial Service Providers in the Context of DORA
For financial service providers, a penetration test must go further. Simply uncovering isolated technical vulnerabilities is insufficient. It must demonstrate how specific attack paths affect critical business processes, whether defined protective measures hold up under real-world conditions, and how robust the evidence is for governance, risk management, and regulatory audits.
A DORA-aligned penetration test should, at a minimum, encompass the external attack surface, web applications, APIs, internal networks, cloud and ICT infrastructure, mobile applications, social engineering risks, as well as critical business processes and recovery procedures. While DORA does not mandate a formal division into exactly eight specific testing domains, the following structure provides a practical framework for defining the scope, conducting the tests, and documenting the results.
What DORA Means for Penetration Testing in the Financial Sector
DORA—the Digital Operational Resilience Act—establishes the European regulatory framework for managing ICT risks. Financial institutions are required to continuously assess their digital resilience and implement structured testing programs. Depending on their risk profile, this includes vulnerability assessments, penetration tests, and broader resilience evaluations.
These requirements compel IT leaders and information security officers to move security testing beyond the silo of pure IT security. The key lies in an integrated perspective that links critical business processes, supporting ICT services, and external dependencies with the measurable operational consequences of a system compromise.
Regulatory authorities incorporate test results—including findings from Threat-Led Penetration Tests (TLPT)—directly into their regulatory assessment of an organization’s ICT risk management and operational stability. Penetration Testing as Part of ICT Risk Management
A penetration test examines whether identified vulnerabilities can actually be exploited under controlled yet realistic conditions. Rather than relying on theoretical risk assumptions, it focuses on demonstrating concrete outcomes—such as unauthorized access to customer or contractual data, the illicit execution of payment transactions, the takeover of privileged administrative accounts, or the targeted disruption of a critical core function.
An automated vulnerability scan provides a broad inventory of known security gaps within systems and software components. However, it cannot map complex attack chains or assess the actual impact on business operations. A penetration test complements this foundational analysis through simulated, targeted exploitation. The results must be documented comprehensively so that they can be directly integrated into the risk register, vulnerability management processes, and management reporting. This requires structured information regarding the scope, methodology, testing period, findings, risk assessment, and follow-up testing.
Comparison: Penetration Test, TLPT, and Vulnerability Scan
Test Type
Purpose
Typical Scope
Vulnerability Scan
Identify known technical vulnerabilities
Automated assessment of systems and software
Penetration Test
Evaluate the exploitability and impact of vulnerabilities
Defined systems, applications, and attack paths
TLPT
Assess resilience against realistic attack scenarios
Critical functions and real-world attack chains
A DORA TLPT goes beyond a standard penetration test. It is based on specific threat intelligence insights and assesses defensive and responsive capabilities against sophisticated attack scenarios, focusing directly on critical or important functions.
The regulatory technical standards for TLPT are established at the EU level in Delegated Regulation (EU) 2025/119. Whether an entity is required to conduct a full-scale TLPT or if a risk-based penetration test suffices depends on its specific regulatory classification, the systems it operates, and current supervisory requirements.
What DORA does not mandate
DORA does not prescribe a rigid structure consisting of exactly eight testing areas, nor is there a universal testing framework applicable to every institution. Each financial entity is required to make an individual, risk-based selection of the elements to be tested.
Key factors for this determination include the identification of critical functions, the associated data flows, the current threat landscape, and dependencies on external third-party ICT service providers. Furthermore, a penetration test is not a substitute for the overall DORA compliance framework. Governance structures, incident management, business continuity plans, and third-party risk management require their own distinct processes. Depending on the…
