Threat-Led Penetration Testing (TLPT) in accordance with DORA

Threat-Led Penetration Testing (TLPT) in accordance with DORA

Advanced red-teaming tests for regulated financial institutions

The European DORA (Digital Operational Resilience Act) introduces a new standard for ICT risk management. It requires significant financial entities to regularly perform Threat-Led Penetration Testing (TLPT) — intelligence-based and threat-driven tests that simulate the capabilities of advanced, organized cyber attackers (APT groups).

The objective is not merely to identify vulnerabilities, but to verify the ability of the entire organization to detect, respond to, and recover from an attack aligned with a realistic and coordinated threat scenario.


What is Threat-Led Penetration Testing and why are routine tests not sufficient?

Unlike a standard penetration test, TLPT:

  • Simulates an attack in its full complexity, including initial compromise, lateral movement, privilege escalation, persistence and data exfiltration.

  • Is driven by current threat intelligence and sector-specific attack scenarios.

  • Includes a coordination phase with a clearly defined scope, rules of engagement, identification of critical systems and defined testing objectives.

  • From a technical perspective, requires deep knowledge of attack vectors and the ability to replicate real-world adversary techniques, including exploitation of zero-day vulnerabilities, social engineering, obfuscation techniques or supply-chain attacks.


What are the requirements for testing teams?

DORA also emphasizes the quality and qualification of entities performing advanced testing. Testers must meet strict criteria, including:

  • Being reputable professionals with proven technical and organizational expertise and specific domain knowledge.

  • Holding appropriate certifications and undergoing independent audits or demonstrating proper risk management practices in testing.

  • Maintaining adequate professional liability insurance to cover potential damages.

If an institution intends to use its own internal red team, it must obtain regulatory approval and ensure organizational independence of the internal team (to avoid conflicts of interest). Operational threat intelligence for the specific scenario must be provided by a qualified third-party provider.

What requirements does DORA set in relation to TLPT?

01

Testing must be conducted based on the current threat profile, not as a generic scenario.

02

The test must include critical functions and systems whose failure could threaten service stability.

03

The organization must engage external, independent and qualified testers.

04

The results must lead to the implementation of remediation measures and, where necessary, re-testing.

Differences between standard penetration testing and TLPT

Parameter Penetration Testing Threat-Led Penetration Testing (TLPT)
Test Objective Identification of vulnerabilities, misconfigurations and system weaknesses Simulation of a real-world attack (APT-like), testing resilience of defensive mechanisms
Frequency Min. once per year for systems supporting critical/important functions Min. once every 3 years (for selected entities based on risk profile)
Testing Team Internal or external team; must be independent External team or exceptionally internal red team; must hold professional certifications
Threat-Based (TI – Threat Intel / OSINT) Not mandatory Yes – scenario must be based on current threats relevant to the institution
Environment Typically testing or staging environment Production systems – real operational resilience is tested
Scope Approval Internally managed Scope must be approved by the relevant regulator
Focus Component testing (applications, networks, configuration weaknesses) End-to-end simulation – includes initial compromise, lateral movement, exfiltration and detection
Third-Party Assessment Optional, often omitted Mandatory if part of a critical function
Remediation Obligation to fix identified vulnerabilities, internal verification Mandatory remediation plans + verification and supervisory reporting
Supervisory Reporting No – internal documentation only Yes – results, remediation plans and proof of DORA compliance submitted to regulator
Test Certification Not required Yes – regulator issues certification of compliance with DORA
Methodological Framework Not strictly defined; may follow OSSTMM, OWASP, etc. Must comply with frameworks such as TIBER-EU
Benefits Identifies technical weaknesses Tests the ability to detect, respond to and withstand sophisticated attackers

How does testing work in practice?

Icon

Reconnaissance

Identification of the target application and connection to the internal network. Collection of information about the target system such as IP addresses, DNS records and other metadata.

Icon

Footprinting

Analysis of publicly available information about the application and related systems. Identification of accessible services, versions and other relevant data.

Icon

Sniffing

Intercepting and collecting transmitted data to identify vulnerabilities that could lead to data leakage.

Icon

Scanning

Scanning the network to identify active hosts and open ports. Scanning specific application services such as APIs and GUI interfaces.

Icon

Enumeration

Identification of user accounts and groups within the system. Specification of available functions and permissions within the application.

Icon

Vulnerability Analysis

Scanning and analysis of identified vulnerabilities in the application. Assessment of operating system, database and other component security. Use of tools such as Qualys, Nessus, Burp Suite and other standard automated and manual tools.

Icon

Exploitation

Attempt to exploit identified vulnerabilities to gain unauthorized access or exfiltrate information. Simulation of attacks against the application environment.

Icon

Post-Exploitation

Continuation of environment reconnaissance after gaining access. Collection of additional information and attempts to escalate privileges.

Icon

Reporting

Preparation of a detailed report containing identified weaknesses, improvement recommendations and evidence of conducted tests. Delivery of results to responsible stakeholders within the organization.

Icon

Cleanup

In the event of successful access, measures are taken to minimize potential impact. Removal of testing traces and restoration of the system to its original state.

Why work with BDO?

BDO delivers TLPT services in line with the specific requirements of European regulators (e.g., the ECB, EBA, ESMA), as well as proven methodologies such as TIBER-EU, CBEST, or iCAST.

Our methodology combines a red teaming approach, strong knowledge of the regulatory framework, and deep technical know-how—including scenarios that reflect sector-specific threats and digital attacks within the European financial ecosystem.

  • Expertise in DORA, NIS2 and TIBER-EU

We understand regulatory frameworks and can tailor TLPT testing to meet legislative and sector supervisory requirements. We also support the overall cybersecurity resilience strategy.

  • Independence and credibility

As an independent consulting firm, we do not provide proprietary technologies and deliver truly objective assessments. Cooperation with BDO is a clear signal of quality and trust for regulators and clients alike.

  • Certified red team with professional expertise

Our specialists hold certifications such as OSCP, CRTO, eCPPT, BSCP, CEH, CRT, CPSA, CISSP, CCISO and others. They have experience testing large banks, insurance companies and ICT service providers.

OSCP eCPPT RedTeam PenTest CEH CREST CISO CISSP

Main contacts

Martin Horičký
Martin Horičký
Partner • Digital Services
i View bio
Marek Kovalčík
Chief Information Security Officer • Digital Services
i View bio