DORA TLPT: Threat-Led Penetration Testing Under Articles 26 and 27, Explained for Financial Entities
Threat-led penetration testing (TLPT) is the advanced testing tier in the EU's Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554). Articles 26 and 27 require the financial entities their supervisors single out to run a controlled, intelligence-led red-team attack on live production systems at least every 3 years, following the TIBER-EU framework. Most banks, insurers, payment firms and fintechs are not in that group. They fall under the standard tier in Articles 24 and 25: appropriate testing, including penetration testing, of every ICT system supporting a critical or important function, at least yearly.
This page explains what TLPT is, who has to do it, how a test runs, who may carry it out, and how it differs from an ordinary penetration test. For the full set of obligations, see DORA penetration testing requirements.
One thing to know first: Budget Security does not deliver TLPT or TIBER-EU red-team engagements. We deliver the Article 25 standard tier: scoped, manual penetration tests of web applications, APIs, networks and cloud accounts by OSCP-certified testers.
What DORA TLPT is
DORA defines TLPT in Article 3(17) as "a framework that mimics the tactics, techniques and procedures of real-life threat actors" and that "delivers a controlled, bespoke, intelligence-led (red team) test" of "the financial entity's critical live production systems". Source: Regulation (EU) 2022/2554, Article 3.
Three words carry the weight. Threat-led: the attack scenarios come from intelligence about who realistically targets this entity and how. Live production: the test runs against the real systems, not a staging copy. Red team: the goal is to reach agreed objectives, such as a payment system, while the defenders do not know a test is under way. A TLPT tests detection and response as much as vulnerabilities.
Article 26(1) sets the cadence: in-scope entities "shall carry out at least every 3 years advanced testing by means of TLPT", and the authority may adjust that frequency based on risk. Article 26(2) requires each test to cover several or all critical or important functions, on live production systems, including outsourced ICT. The authority validates the scope.
The method is TIBER-EU. In the European Central Bank's words, "TIBER-EU is a European framework for threat intelligence-based ethical red-teaming." The ECB published it in May 2018 and updated it to align with the DORA technical standards on TLPT, which Article 26(11) required to follow TIBER-EU. The outcome is not a pass or fail; the test aims to "reveal the strengths and weaknesses of the cyber resilience measures put in place by the tested entity." Source: ECB, TIBER-EU.
Who has to do TLPT, and who decides
Not every financial entity. DORA has applied since 17 January 2025 (Article 64), but the TLPT duty lands only on the entities a competent authority identifies. Article 26(8) names the grounds: impact on the financial sector, financial stability concerns, and ICT risk profile and maturity. Microenterprises and entities under the simplified framework of Article 16(1) are excluded. People call the selected group "significant entities"; DORA uses that word only for significant credit institutions.
The detailed criteria sit in the regulatory technical standards drafted under Article 26(11), published as Commission Delegated Regulation (EU) 2025/1190, which the European Banking Authority lists as in force and applying from 8 July 2025. The RTS also cover internal testers, the scope and methodology of each phase, closure and remediation, and the supervisory cooperation behind mutual recognition. Source: EBA, Joint RTS on threat-led penetration tests.
You do not self-select. If you meet the criteria, your competent authority, or the single public authority designated under Article 26(9), contacts you.
Attestation and mutual recognition. After the test, Article 26(6) requires the entity to give the authority a summary of findings, the remediation plans and documentation showing the test met the requirements. Under Article 26(7) the authority issues an attestation, which enables mutual recognition between authorities, so a group active in several member states does not repeat the test per regulator. Article 26(4) adds a pooled option: where testing a shared ICT provider could harm its other customers, the provider may contract an external tester directly and run one TLPT that counts for every participating entity.
How a TLPT runs: phases and teams
The ECB lists the stages as initiation, scoping, threat intelligence, red-team testing, blue team report and remediation plan. They group into three phases.
Preparation. The entity's control team and the authority's TIBER cyber team agree which critical or important functions are in, which live systems support them and which third-party providers are involved. The authority validates the scope (Article 26(2)) and risk controls are agreed so the test cannot damage data, assets or the functions themselves (Article 26(5)).
Testing. The threat intelligence provider works out who would realistically attack this entity and how, and turns that into attack scenarios. The red team runs them against the live systems, covertly, over weeks, while the blue team defends without knowing a test is on.
Closure. The red team reports what it reached and how; the blue team reports what it saw and did. Purple-teaming, where attackers and defenders replay the attack together, can take place "in the TIBER-EU testing phase or closure phase". The entity drafts a remediation plan and files the Article 26(6) package.
The teams, in the ECB's words:
- Control team (the white team in some frameworks). "A small team within the target entity whose members are the only ones there who know a test is happening."
- Blue team. "The people in the entity that is the subject of the test, whose prevention, detection and response capabilities are being tested without their foreknowledge."
- Threat intelligence provider. "The team that looks at the range of possible threats and carries out reconnaissance on the entity."
- Red-team testers. "The team that carries out the simulated attack by attempting to compromise the critical functions of the entity."
- TIBER cyber team. "The team within the authority that is responsible for overseeing the test."
Source: ECB, TIBER-EU. A TLPT is measured in months; a scoped penetration test in tester-days.
Who may run a TLPT: the Article 27 tester requirements
Article 27(1) says financial entities shall only use testers that meet five conditions. Source: Regulation (EU) 2022/2554, Article 27.
- Suitability. They "are of the highest suitability and reputability".
- Capability. They have the technical and organisational capabilities and specific expertise in threat intelligence, penetration testing and red-team testing.
- Certification or code. They "are certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks".
- Assurance. They provide independent assurance or an audit report on the sound management of TLPT risks, including protection of the entity's confidential information.
- Insurance. They are "duly and fully covered by relevant professional indemnity insurances, including against risks of misconduct and negligence".
Internal testers. Allowed, with conditions. Article 26(8): entities using internal testers must contract external testers at least every third test, and significant credit institutions must use external testers only. Article 27(2): the competent authority must approve the use and verify sufficient dedicated resources and no conflicts of interest, and "the threat intelligence provider is external to the financial entity". Article 27(3) requires the contract with an external tester to cover sound handling of the results. Read as a buyer's checklist, Article 27 asks whether the provider is organised for TLPT, not only whether its testers are skilled.
TLPT vs penetration testing: side by side
A penetration test asks: which weaknesses in this system can an attacker exploit? A TLPT asks: can a realistic adversary reach this entity's critical functions, and would anyone notice?
| TLPT (Articles 26 and 27) | Penetration testing (Articles 24 and 25) | |
|---|---|---|
| Goal | Reach agreed objectives on live systems as a real threat actor would; test detection and response | Find and confirm exploitable vulnerabilities in a defined system; deliver fixes |
| Who is in scope | Entities identified by their competent authority under Article 26(8) and the RTS | Every financial entity other than microenterprises, for all systems supporting critical or important functions |
| Frequency | At least every 3 years; the authority may adjust | At least yearly (Article 24(6)) |
| Scope | Several or all critical or important functions, live production, including outsourced ICT; validated by the authority | Assets you define: application, API, network, cloud account |
| Who tests | Testers meeting Article 27; external at least every third test; external threat intelligence provider always | Independent parties, internal or external (Article 24(4)) |
| Who knows | A small control team and the authority; the blue team is not told | The system owner and security team; the test is announced and coordinated |
| Deliverable | Red team report, blue team report, remediation plan, summary to the authority, attestation | Report per asset with findings, severity, evidence and fix guidance; retest record |
| Typical duration | Months, across preparation, testing and closure | Days; on our platform 1 to 30 tester-days in half-day steps |
One point gets missed: a TLPT does not replace the yearly testing. Article 24(6) applies to every financial entity other than microenterprises, including those selected for TLPT.
What Budget Security does not do: TLPT
Budget Security does not perform threat-led penetration testing, TIBER-EU engagements or any covert red-team exercise. We are not a threat intelligence provider, we do not attack live production systems without the defenders' knowledge, and we take no part in the supervisor coordination a TLPT requires. If your authority has identified you for TLPT, you need a provider built for it, and this page is not a pitch for us to do it. Check the Article 27 evidence pack before you check the price.
What we deliver is the Article 25 standard tier: a scoped, manual penetration test of a named asset by an OSCP-certified tester. Every financial entity outside the TLPT group owes that test under Article 24(6), the TLPT group still owes it yearly alongside the red-team cycle, and ICT providers to banks are asked for it in due diligence.
The standard tier: Articles 24 and 25, and what ICT providers to banks get asked
What the regulation says. Article 24(1) requires every financial entity other than a microenterprise to maintain a testing programme. Article 24(4) requires tests by independent parties. Article 24(5) requires procedures to prioritise, classify and remediate every issue found. Article 24(6) sets the cadence: "Financial entities, other than microenterprises, shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions." Source: Regulation (EU) 2022/2554, Article 24.
Article 25(1) lists what counts, from vulnerability assessments and scans, open source analyses, network security assessments and gap analyses, through source code reviews and scenario-based tests, to penetration testing. Article 25(2) requires central securities depositories and central counterparties to run vulnerability assessments before deploying systems supporting critical or important functions. Article 25(3) lets microenterprises take a risk-based approach.
How to evidence it. A supervisor or auditor wants the chain, not just a PDF:
- A written testing programme naming the test types you use and why.
- An inventory of the ICT systems supporting critical or important functions, so the "all" in Article 24(6) can be checked.
- A dated test report for each of those systems from the last 12 months, with scope and exclusions.
- Proof of tester independence under Article 24(4).
- Each finding classified, prioritised and tracked to remediation under Article 24(5), with a retest showing the fix held.
ICT third-party providers. If you are a fintech, SaaS vendor or hosting or payments provider selling to financial entities, DORA reaches you through your customers. Their Article 24 programme covers the systems supporting their critical or important functions wherever those run, and Article 26(2) pulls outsourced ICT into TLPT scope. In practice a bank meets its obligation for a system you host by asking you for a recent independent penetration test report on the application and API it consumes, the tester's qualifications, open findings with severities, and proof that confirmed findings were retested. Having that ready turns a procurement delay into an attachment.
How Budget Security's pentest fits, and what to do next
Budget Security is a self-serve platform for the standard tier. Register, add the assets that support your critical or important functions, and the scoping engine returns a plan in tester-days and its price. Pick a start date; booking creates a quote, not a payment.
- Scoped per asset. Web application, API, external or internal network and cloud account scopes, black, grey or white box.
- Manual testing by OSCP-certified testers. Tooling handles discovery. Exploitation, business logic and attack chains are human work.
- Start within 7 days of booking. A faster start depends on tester availability and carries an urgency surcharge.
- Report within 48 hours after the test ends. One PDF per asset: executive summary, scope, and each finding with severity, CVSS score, impact, fix, replication steps and evidence.
- Findings workspace included. Status per finding with notes and history, so the Article 24(5) remediation trail exists without a spreadsheet. Invite developers on findings-only accounts, create Jira Cloud issues in one click, or copy a ready-made prompt for your AI coding tool.
- Retest as a paid add-on. One tester-day, booked from the workspace, closing the finding in the tracker your assessor sees.
- Pricing. $985 per tester-day for US clients (€849 per day for EU clients). No setup or project-management fee, prices excluding VAT, payment after the report is delivered. A customer-facing application plus its API typically runs 3 to 5 tester-days; the pentest pricing calculator gives your figure.
If your authority has identified you for TLPT. Confirm the designated authority and your test window, select a provider against Article 27, and keep the yearly Article 24(6) testing running, because the TLPT cycle does not replace it. We can cover that yearly layer, not the TLPT.
If you have not been identified. Inventory the systems supporting critical or important functions, write the testing programme, test each in-scope asset at least yearly, track every finding to closure and retest the confirmed ones. Ask your supervisor if unsure whether the TLPT criteria apply.
If you are an ICT provider to financial entities. Expect the questionnaire. Test the application and API your customers consume, keep the report and retest record current, and give your customer's assessor read access to the findings. For the complete picture, read the general DORA testing requirements.
FAQ
DORA TLPT: frequently asked questions
Is TLPT mandatory for every bank under DORA?
How often does DORA require TLPT?
Can an internal team perform a DORA TLPT?
What is TIBER-EU?
What is the difference between TLPT and a penetration test?
Does Budget Security perform DORA TLPT?
Need the Article 25 pentest, not a red team?
Scope the asset that supports your critical or important function and see the tester-day estimate first. OSCP-certified testers, start within 7 days, report within 48 hours after the test ends.