Penetration testing vs TLPT under DORA: the differences, who they apply to and how to prepare

Under DORA, financial entities have to test their digital operational resilience at two levels. The first applies to almost all of them: the testing programme under Arts. 24-25, which includes vulnerability scans, code reviews and penetration testing. The second applies to only a few: advanced TLPT under Arts. 26-27, carried out on live production systems under the supervision of the authority.

Confusing the two levels is costly either way. A company that thinks “a pentest once a year” counts as TLPT will not be ready when the supervisor - in Poland, the KNF - selects it for TLPT. A company that thinks TLPT does not apply to it, and so it needs no testing at all, forgets the mandatory programme under Art. 24. Below you will find a comparison of penetration testing vs TLPT, the criteria for being selected for TLPT, an outline of the test and a list of steps worth taking whatever the authority decides.

Penetration testing vs TLPT: a comparison

In a nutshell: a penetration test checks what vulnerabilities a system has. TLPT checks whether the organisation as a whole - its people, processes and technology - can withstand a realistic attack on its most important functions.

The testing programme under DORA Articles 24-25: required of almost every entity

Before the question of TLPT even comes up, you need the foundation that DORA requires of all financial entities other than microenterprises:

• financial entities other than microenterprises establish a risk-based digital operational resilience testing programme (Art. 24(1)-(3)).
• tests are carried out by independent parties, whether internal or external (Art. 24(4)).
• all ICT systems and applications supporting critical or important functions are tested at least once a year (Art. 24(6)).
• issues revealed by the tests are classified and remedied according to established procedures (Art. 24(5)).

Microenterprises test too, just in a simpler way. Microenterprises carry out the tests referred to in Art. 25(1) by combining a risk-based approach with strategic planning of ICT testing, balancing the resources and time allocated against the urgency, type of risk and criticality of information assets and services (Art. 25(3)).

Art. 25 gives an open list of the tests that make up the programme: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing (Art. 25(1)). Penetration testing is one item on that list - alongside scans, code reviews and scenario-based tests. How a penetration test differs from a vulnerability scan and a compliance audit is explained on our penetration testing page.

The delegated regulation supplementing DORA adds specific minimum requirements: automated vulnerability scanning of ICT assets supporting critical or important functions at least once a week (Art. 10(2) of Delegated Regulation (EU) 2024/1774). The systems development procedure includes source code reviews covering static and dynamic testing, including security testing of internet-exposed applications (Art. 16(3) of Delegated Regulation (EU) 2024/1774).

TLPT: who it applies to

Identified financial entities carry out TLPT at least every three years; the competent authority may change this frequency (Art. 26(1)). The competent authority decides who must carry out TLPT, and the national arrangements may differ between Member States. The Polish Financial Supervision Authority (KNF) identifies, by way of decision, the entities required to carry out TLPT, approves internal testers and issues the test attestation (Art. 18zk of the Financial Market Supervision Act).

The authority takes three criteria into account (Art. 26(8), third subparagraph):

• the impact of the financial entity's services and activities on the financial sector
• possible financial stability concerns, including the systemic character of the entity
• the specific ICT risk profile and level of ICT maturity

The delegated regulation names the categories of entities from which the authority requires TLPT, unless an assessment shows that this is not justified (Art. 2(2) of Delegated Regulation (EU) 2025/1190):

• systemically important banks (G-SIIs, O-SIIs) and banks belonging to their groups
• payment institutions and electronic money institutions above thresholds for transaction value or for electronic money in circulation
• central securities depositories and central counterparties
• trading venues meeting market share criteria
• the largest insurance and reinsurance undertakings (thresholds for premiums and technical provisions)

The TLPT requirement does not apply to microenterprises or to entities applying the simplified framework under Art. 16 (Art. 26(1)).

If your organisation is close to the thresholds on this list, or plays a significant role in the market, it is safer to assume that a decision may come and to plan your preparations well in advance - the test itself and the stages around it take many months.

How TLPT runs: an outline of the phases

Delegated Regulation (EU) 2025/1190 divides the test into five stages. The authority oversees the process and, at the end, issues an attestation that allows the test to be mutually recognised.

1. 01

   Preparation

   Notification by the authority, set-up of the control team, a scope specification document approved by the management body, selection of providers.

2. 02

   Threat intelligence

   An external threat intelligence provider prepares at least 3 attack scenarios tailored to the financial entity.

3. 03

   Red team testing

   The active attack phase on production systems lasts at least 12 weeks, with weekly progress reports to the control team.

4. 04

   Closure

   Red team test report within 4 weeks, blue team test report, replay of the attack and a purple teaming exercise.

5. 05

   Remediation and attestation

   A test summary report and a remediation plan for the authority, followed by an attestation that the test was carried out.

The detailed deadlines for each stage, the roles in the test and the requirements for testers are described on our threat-led penetration testing (TLPT) page.

Red teaming vs penetration testing: a different method, a different question

TLPT is based on red teaming, which differs from a classic penetration test more than the similar names suggest:

• Goal. A pentest aims to find as many vulnerabilities as possible within an agreed scope. A red team aims to achieve a specific objective - e.g. access to the payment system - by the route a real adversary would choose.
• Awareness. A pentest is usually carried out with the administrators' knowledge. In red teaming, only the control team knows about the test, and the defenders respond as they would to a real incident.
• Scope. A pentest covers the specified systems. A red team may use any route within the approved scenarios - including people, processes and suppliers.
• Result. A pentest produces a list of vulnerabilities with evidence. Red teaming also shows whether the attack was detected, how quickly, and whether the response worked - and after the test, both sides analyse it together (purple teaming).

The two approaches complement each other. A red team that gets in during its first week through a known, unpatched vulnerability wastes test time on something an ordinary pentest or a scanner would have found.

The TLPT methodology is derived from the European TIBER-EU framework for red team testing in the financial sector.

How to prepare for TLPT - before the decision arrives

These steps make sense whether or not the supervisor selects your organisation for TLPT, because they follow from obligations that already apply:

1. A mature programme under Arts. 24-25. Regular scans, penetration tests of systems supporting critical or important functions and retests of the fixes. Remove known vulnerabilities before the test, not during it.
2. An inventory of critical or important functions and the systems that support them, together with dependencies on ICT third-party service providers.
3. Detection and response. TLPT puts your defences to the test, so rehearse monitoring, escalation and incident handling against scenarios beforehand.
4. ICT providers. Where ICT third-party service providers are in scope, the financial entity ensures their participation and retains full responsibility; pooled testing is possible (Art. 26(3)-(4)). In contracts for services supporting critical or important functions, DORA requires a provision on the provider's participation in TLPT (Art. 30(3)).
5. Control team and management decisions. Someone has to run the test on the organisation's side, protect its confidentiality and decide whether to halt activities if they threaten production.
6. Selecting testers and a threat intelligence provider in line with Art. 27 - the requirements are listed below.

Requirements for TLPT testers: how to read proposals

A financial entity may only use testers that (Art. 27(1)):

1. are of the highest suitability and reputability
2. possess technical and organisational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing
3. are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks
4. provide independent assurance or an audit report on the sound management of TLPT risks, including the protection of confidential information
5. are duly and fully covered by professional indemnity insurance

When assessing proposals, check that the provider has documented each of these points: certifications or codes of conduct, independent assurance on the management of test risks and the protection of confidential information, professional indemnity insurance, and the team experience and references required by the delegated regulation. A financial entity that uses internal testers must contract external testers for every third test. Significant credit institutions supervised by the ECB use external testers only (Art. 26(8), first and second subparagraphs).

How we can help

We do not act as a TLPT tester - in the test itself, we do not replace the red team or the threat intelligence provider. We help with what happens before and after the test: we carry out penetration tests and code reviews as part of the programme under Arts. 24-25, assess your testing programme and your readiness for TLPT, review proposals from testers and threat intelligence providers against Art. 27, and after the test we verify the fixes in the remediation plan with confirmation testing.

The services we offer to entities subject to DORA are described on our DORA compliance page, which covers resilience testing and ICT risk.