DORA TLPT is not a bigger pen test. Here is what is actually different.
DORA Article 26 testing differs from a standard penetration test in five operational ways. A practitioner walk-through of scope, scenarios, duration, sequencing, and reporting.
The phrase “DORA penetration testing” appears in a lot of compliance summaries, and it is creating a real problem. Procurement teams are going out to their existing pen test panels, getting proposals dressed up in TLPT language, and handing them to their regulators. The regulators are not happy. If you are a CISO preparing for your first TLPT cycle, or a programme manager trying to explain the difference to your board, here is what actually distinguishes a DORA Threat-Led Penetration Test from the kind of pen test your security team has been running annually for the past decade.
The short version: DORA TLPT is not a larger or longer pen test. It is a different category of exercise, governed by different regulatory obligations, using a different methodology, touching your live production environment, and ending with a structured exercise that most commercial red team engagements have never included. Five differences matter most.
1. Real threat intelligence drives the scenarios, not a generic scope
A standard penetration test begins with a scope document. The tester is told which systems are in bounds, which are not, and what the client wants tested. The scenarios are generic: common web application vulnerabilities, network perimeter weaknesses, phishing simulations. Useful. But not what DORA requires.
Article 26(2) of Regulation (EU) 2022/2554 requires that TLPT scope cover “several or all critical or important functions” of the entity. More importantly, the methodology mandated by Commission Delegated Regulation (EU) 2025/1190 (the TLPT RTS, applicable from 8 July 2025) requires that an external Targeted Threat Intelligence provider produce a structured TTI report before a single test action is taken. That report identifies the threat actors most likely to target your institution, their current tactics, techniques and procedures, their likely attack vectors, and the critical functions they would prioritise.
The red team’s scenarios are then derived from that TTI report. They are not invented by the testers. They reflect what Scattered Spider, Cl0p, APT29, or whatever adversary group is genuinely relevant to your institution actually does. If your threat profile says that your payment rails are the target and that initial access will likely come via a supply chain compromise of a third-party software vendor, then that is the scenario the red team executes.
This matters because it changes the entire purpose of the exercise. A generic pen test finds generic vulnerabilities. A TLPT finds whether your specific controls hold against the specific tradecraft of threat actors who are already interested in organisations like yours.
2. Testing happens on live production systems
Article 26(2) is explicit: testing “shall be performed on live production systems.” Not staging. Not a representative replica. The live systems supporting the critical or important functions in scope.
This has operational consequences that most pen test programmes are not designed to handle. The entity’s risk acceptance for a TLPT engagement is fundamentally different from a test on non-production infrastructure. The Control Team (the small group within the institution who know the test is happening) must have sufficient authority to authorise testing actions against live systems, manage escalation if something goes wrong, and ensure continuity obligations are met throughout.
It also means the Blue Team cannot know the test is happening. Your SOC is operating as normal, responding to what they believe are real incidents. This is the condition that generates the most operationally valid finding: not what your controls are configured to detect, but what they actually detect when a skilled adversary operates in your environment.
Standard pen tests are almost never conducted on live production. DORA TLPT must be.
3. The active testing phase must last at least 12 weeks
The TLPT RTS codifies a minimum 12-week duration for the active red team testing phase. This is not 12 weeks of total engagement time; this is 12 weeks of live attack simulation against production systems.
Most commercial red team engagements run for two to four weeks. Some run six. A 12-week minimum reflects the realities of how sophisticated threat actors actually operate: they take time to establish persistence, map the environment, blend into legitimate traffic, and move laterally before executing against their objective. A two-week engagement compresses that timeline artificially, which produces findings that are real but not representative of a patient, motivated adversary.
The 12-week floor is a signal about the type of adversary being simulated. A nation-state actor or a well-resourced ransomware affiliate does not operate on the same timeline as a 10-day pen test window. DORA TLPT is designed to surface what happens when they do not.
For a complex Tier 1 institution with multiple critical functions, third-party cloud scope, and significant geographic distribution, the full engagement from initiation to attestation typically runs 12 to 18 months. The active test window is one component of that.
4. Purple teaming is mandatory
Under Commission Delegated Regulation (EU) 2025/1190, purple teaming is not optional. It was encouraged under the pre-2025 TIBER-EU framework but not required. DORA made it a precondition for attestation.
Once the active red team phase ends, the Blue Team is brought in. The red and blue teams conduct a structured, collaborative replay of the entire attack: every technique used, every action taken, every lateral movement step, and every objective reached or not reached. The Blue Team reviews which detections fired, which were missed, and which controls held or failed. The RTS requires this to happen within 10 weeks of the red team phase completing.
This changes the deliverable entirely. A traditional red team engagement ends with a report. DORA TLPT ends with a capability transfer. The Blue Team leaves the purple team session with a precise understanding of which parts of their detection stack work and which do not, mapped to the specific TTPs that the relevant threat actors actually use. That is materially more useful to the institution than a PDF listing vulnerabilities.
Every red team exercise I have run has ended with the blue team finding out the results at a debrief. Some of those debriefs were the first time the SOC had spoken directly to a red team operator. The difference in understanding, speed of remediation, and institutional learning between that model and a structured 10-week purple team replay is not marginal. It is significant.
5. The competent authority issues a formal attestation
A standard pen test produces a report for internal use. The client decides what to do with the findings. There is no regulatory endpoint.
DORA TLPT ends with formal regulatory sign-off. Under Article 26(7), the competent authority reviews the summary findings and remediation plan and issues a formal attestation confirming the test was conducted in accordance with DORA requirements. That attestation enables mutual recognition: another EU competent authority in a different Member State can accept it as satisfying the TLPT obligation for that entity.
The TLPT Cyber Team at the competent authority is present throughout the engagement. They validate the scope, review initiation documents, approve the Scope Specification Document, and oversee the test process. They are not passive reviewers at the end. The regulatory supervision is active throughout.
This means that a test that does not satisfy the RTS requirements does not produce an attestation. The competent authority will not sign off on a test that ran for six weeks, used a generic scope, skipped purple teaming, or used a threat intelligence provider that was not independent of the red team. The regulatory bar is specific.
What this means for your existing pen test programme
None of this means your annual penetration test has no value. Article 25 of DORA establishes a basic testing regime that applies to all in-scope entities, and standard penetration tests sit within that regime. The two obligations are separate. Article 25 basic testing applies to everyone. Article 26 TLPT applies to the designated subset of higher-risk entities.
The risk for institutions being designated for TLPT is treating their Article 25 provider as their Article 26 provider. The methodology, independence requirements, duration, intelligence sourcing, and regulatory relationship are all different. Procuring a TLPT from your existing pen test panel, without verifying that the provider meets Article 27 requirements and has demonstrable TIBER-EU or CBEST-equivalent delivery experience, is the most common procurement error I see at this stage of the market.
The ESA Joint Final Report JC 2024-29 sets out the full methodology rationale. It is worth reading before you issue a procurement request.
See the full Article 26 requirements breakdown at the DORA TLPT guide. For provider selection criteria and what Article 27 requires of testers, see the DORA TLPT deep-dive section on testers.
