DORA penetration testing: what TLPT is and who needs it

DORA penetration testing means two different things. Every in-scope financial entity runs a resilience testing programme that can include penetration tests. A smaller group, selected by authorities, also runs threat-led penetration testing (TLPT). This page separates the two and explains what a SaaS supplier to banks should expect.

What are the two layers of testing under DORA?#

DORA is Regulation (EU) 2022/2554, dated 14 December 2022. EIOPA states that it "entered into application on 17 Jan 2025". The testing rules sit in Chapter IV.

Ordinary testing is the baseline for all in-scope entities. TLPT is the heavier test for a selected few.

What do Articles 24 and 25 require?#

Article 24 requires financial entities, other than microenterprises, to run a sound digital operational resilience testing programme as part of their ICT risk-management framework. The mirror text adds these points:

• Use a risk-based approach (24(3)).
• Have tests undertaken by independent parties, internal or external. Internal testers need enough resources and no conflicts of interest (24(4)).
• Set procedures to prioritize, classify and remedy issues, and to check that weaknesses are fully addressed (24(5)).
• Test, at least yearly, all ICT systems and applications that support critical or important functions (24(6)).

Article 25 lists the tests a programme should include. The list reads: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing. Penetration testing is one item on a long list, and the entity chooses the mix. Article 25(2) adds that central securities depositories and central counterparties run vulnerability assessments before deploying new or existing applications.

Who must do TLPT, how often, and who may test?#

TLPT applies only to entities that a competent authority identifies. Article 26 names the factors: impact on the financial sector, financial stability and systemic importance, and ICT risk profile or maturity. The regulatory technical standard sets the criteria.

The Commission Delegated Regulation (EU) 2025/1190 is the regulatory technical standard on TLPT. EIOPA lists it among the Level 2 acts published in the Official Journal. Several law-firm pages give adoption and entry-into-force dates, but we did not confirm those on EUR-Lex, so this page states none.

TLPT is closer to a red team exercise than to a pentest. Read red team vs penetration testing for the difference. We do not describe our web, API and SaaS testing as TLPT.

What should a SaaS or ICT supplier expect from financial customers?#

A SaaS vendor is not subject to TLPT unless it is itself a financial entity. Do not read DORA as "TLPT applies to every SaaS company". The pressure reaches suppliers through bank customers, who must manage ICT third-party risk and test the systems they depend on.

Expect three kinds of request:

1. A security questionnaire with a pentest question: date, scope, tester, open findings.
2. A request for a summary of the latest test, often a letter. See the attestation letter guide.
3. A contract clause that lets the customer ask for test evidence or support its own testing.

None of these is TLPT. They are due diligence. See security questionnaire pentest questions and pentest reports for customer security reviews.

Where does a web and API pentest fit, and where does it not?#

A web and API pentest fits Article 25's penetration testing item for the application layer. It gives a bank customer evidence that the app was tested for broken access control, authentication flaws and tenant isolation, and that fixes were retested.

It does not replace TLPT, network and physical tests, source code review, or the entity's own programme. It also does not show that a supplier is compliant with DORA. Compliance is the financial entity's duty, and its supervisors decide what satisfies them. We do not say any report will be accepted by a regulator or a customer.

What evidence should you prepare for a bank's due diligence?#

Prepare these items before a bank asks.

• Scope statement: apps, APIs, environments and roles tested.
• Test dates, and the date of any retest.
• Method named in the report, such as the OWASP WSTG. See penetration testing methodology.
• Tester independence: who tested, and whether they built the system.
• Findings by severity, with fix status.
• A summary letter you may share, with the full report held back for use under NDA.
• Your process for fixing issues and checking the fix, which mirrors the intent of Article 24(5).

How does DORA compare with NIS2 and PCI DSS?#

For PCI, see PCI DSS penetration testing requirements.

What to check before you agree scope#

• Is the customer a financial entity, or an ICT supplier to one?
• Does the customer want ordinary pentest evidence or TLPT? Ask in writing.
• Which of your systems support the customer's critical or important functions?
• Who signs the authorization, and does it cover third-party hosts?
• Will the customer accept a letter, or does it need the report?
• When is the retest, and does the report show its date?

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report