Table of contents
19
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: DORA TLPT sounds like one compliance requirement, but it’s actually the harder half of a two-tier testing system, and most guides never separate the two clearly.
- Every DORA entity has a testing duty, but only a small subset ever runs a TLPT. Articles 24-25 require annual testing (vulnerability scans, penetration testing, gap analyses) from almost everyone. Articles 26-27 require TLPT, a full red-team exercise, only from entities their regulator identifies, using the RTS’s thresholds plus a qualitative assessment.
- Most guides describe scope as “systemically important” firms, but the RTS puts hard numbers on several entity types. It names EUR 150 billion in payment transactions, EUR 40 billion in outstanding e-money and a two-step insurer test, and even then your authority can release an entity that meets them after an overall assessment.
- The RTS sets hard clocks for most phases, but few guides turn them into an actual timeline. Scope documents are due within 6 months of notification, the active red-team phase must run at least 12 weeks, and closure adds 4- and 10-week report deadlines after the active phase, then 8 weeks for the summary report and remediation plan.
- Only testers meeting DORA Article 27 and RTS Article 7 can run the official test, outside a narrow documented exception, and the bar is specific. Named experience-years, reference counts, and a hard separation between the threat-intelligence provider and the red team, not just “hire a reputable firm.”
- No regulator publishes a TLPT cost, and the vendor estimates that exist don’t agree with each other. The most detailed published range (£150,000-£310,000+ in provider fees alone) comes from a GRC software vendor’s whitepaper, not from any regulator.
DORA has been enforceable since January 2025, and its testing rules are not new. What’s changed is that the regulatory technical standard governing TLPT, Delegated Regulation (EU) 2025/1190, is now final, published, and in force, and most content written about it still cites the pre-final draft or treats “DORA testing” and “TLPT” as the same thing.
They aren’t, and confusing the two is how a compliance team either over-scopes a TLPT it was never required to run, or under-prepares for one it is.
This DORA TLPT guide separates DORA’s two testing tiers cleanly, gives you the exact thresholds that determine whether TLPT applies to you, turns the RTS’s own deadlines into a real project timeline, and is honest about what a penetration testing vendor like XHack can and can’t do for you here.
It sits inside our wider look at penetration testing for compliance, which compares how ten major frameworks, DORA included, actually treat testing side by side.
DORA, Regulation (EU) 2022/2554, defines threat-led penetration testing in one sentence, Article 3(17):
“‘threat-led penetration testing (TLPT)’ means a framework that mimics the tactics, techniques and procedures of real-life threat actors perceived as posing a genuine cyber threat, that delivers a controlled, bespoke, intelligence-led (red team) test of the financial entity’s critical live production systems.”
Notice what that definition doesn’t say. It doesn’t call TLPT “a penetration test.” It calls it a framework, an intelligence-led red team test, run against live production systems. The RTS makes the distinction explicit in its own recital 12: “Conventional penetration tests provide a detailed and useful assessment of technical and configuration vulnerabilities often of a single system or environment in isolation, but unlike intelligence led red team test, do not assess the full scenario of a targeted attack against an entire entity.”
A regular penetration test checks whether a specific system has exploitable holes; a DORA TLPT is a different scale of exercise entirely. A DORA TLPT starts from real threat intelligence about who would actually attack your entity and why, then runs a red team against your live production environment to see if those specific threats would succeed, tracked by a regulator-appointed test manager from notification to attestation.
That difference in shape is also why a DORA TLPT is expensive, slow, and reserved for a small number of entities, which is the next thing most guides blur.
Here’s the split that most DORA content blurs into one undifferentiated “testing requirement”:
Article 24-25: the general testing programme, almost everyone. DORA Article 24(6) requires that financial entities “ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.” Article 25(1) lists what counts: “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.” A regular penetration test is one of the listed test types for this tier, but the tier is a whole programme: Article 24 also requires a risk-based approach and procedures to prioritise, fix and validate every issue the tests reveal. Microenterprises get a lighter, risk-based version of this duty rather than a full exemption.
Article 26-27: DORA TLPT, a small subset only. Article 26(1) requires TLPT “at least every 3 years” but only from entities the competent authority identifies against specific criteria, and never from microenterprises or the simplified-framework entities listed in Article 16(1). This is the tier this article is mostly about.
The practical DORA TLPT consequence: if your entity has never been notified by a regulator that it’s in scope, you almost certainly still have an annual Article 24-25 testing duty, with penetration testing one of the named options, just not the full TLPT machinery. Skip ahead to the section on what applies if you’re not identified if that’s your situation, because most of this guide’s phase-by-phase detail won’t apply to you yet.
Most pages covering DORA TLPT describe who’s in scope in vague terms: “systemically important,” “major financial institutions.” The RTS, Delegated Regulation (EU) 2025/1190, Article 2(2), gives exact criteria instead. TLPT authorities must require TLPT from the following, unless their Article 2(1) assessment says it isn’t justified:
Two things worth knowing before you assume any of this settles the question for you. First, meeting a quantitative threshold doesn’t automatically mean TLPT: Article 2(1) also has your regulator weigh impact, systemic character, and ICT risk profile, and recitals 2 and 3 explicitly allow an entity that meets the numbers to be released from the requirement “in light of an overall assessment.” Second, other entity types, crypto-asset service providers among them, are assessed against qualitative criteria only, with no bright-line number.
In practice: you don’t self-declare into TLPT. Your competent authority notifies you. What these DORA TLPT thresholds tell you is whether you’re a realistic candidate, and if you are, it’s worth starting the internal conversation before that notification arrives rather than after.
Only a handful of the guides we reviewed add up the RTS’s own deadlines: every deadline below is the RTS’s own text, not a planning estimate, and stacking them shows how little slack the process actually has.
Preparation phase. The clock starts at notification (Article 9(1)). Within 3 months, the entity submits initiation information: a project charter, control team lead contacts, whether it’s using internal or external testers, and a code name for the engagement (Article 9(2)). The control team gets formed and validated by the authority (Article 9(4)-(5)). Within 6 months of notification, the scope specification document is due, approved by the entity’s own management body before it goes to the authority (Article 9(6)).
Threat intelligence phase. The threat intelligence provider builds targeted scenarios. The control team lead selects at least three scenarios, and no more than one may be non-threat-led (Article 10(3)-(4)). The RTS recitals note this phase typically runs around 4 weeks, though that’s a recital estimate, not a hard article deadline.
Red team phase. Once the threat intelligence report is approved, DORA TLPT testers prepare a red team test plan (Annex IV), then the active testing begins. This is the RTS’s hardest floor: Article 11(5) requires the active red team testing phase to “last for at least 12 weeks,” scaled up for larger or more complex entities. Testers report to the control team and test managers at least weekly (Article 11(7)).
Closure phase, two parallel deadlines and then a third. The red team test report is due within 4 weeks of the active phase ending (Article 12(2)). The blue team test report, plus a replay of offensive and defensive actions and a mandatory purple teaming exercise, is due no later than 10 weeks after the active phase ends (Article 12(4)-(5)). Once the authority confirms those reports meet the required content, the entity has 8 weeks to submit a summary report of findings (Article 12(7)).
Remediation. Within 8 weeks of the same Article 12(7) notification, in parallel with the summary report, the entity delivers its remediation plan: per-finding shortcomings, proposed measures with prioritization, root cause analysis, and named responsible staff (Article 13).
Add it up and a first DORA TLPT cycle realistically runs around 9 to 15 months from notification to attestation: up to 6 months of preparation, roughly 4 weeks of threat intelligence, at least 12 weeks of active testing, up to 10 weeks of closure reporting, then up to 8 weeks for the summary report and remediation plan, plus authority review time the RTS doesn’t fix. That range is our own arithmetic from the RTS deadlines, not a sourced benchmark, and provider procurement has to finish inside it, because the RTS requires procurement completed before testing starts. No page we reviewed while researching this article gives an internal staff-effort figure in hours or person-days, and neither will we invent one; treat any such number you see elsewhere as unsourced unless it says whose data it’s based on.
DORA Article 27(1) sets five conditions for any DORA TLPT tester, the backbone of who’s actually allowed to run one: the highest suitability and reputability; technical and organizational capability with demonstrated expertise in threat intelligence, penetration testing, and red team testing; certification by an accreditation body or adherence to formal codes of conduct; independent assurance or an audit report on how they manage risk to the entity’s confidential information; and full professional indemnity insurance covering misconduct and negligence.
The RTS adds specifics the DORA text leaves open. In the adopted RTS, provider selection sits in Article 7. The concrete figures below come from the ESAs’ final report on the draft RTS, where they appear as draft Article 5(2), so read them as the final-draft wording: the threat intelligence provider needs at least three references and a manager with 5+ years of threat intelligence experience; the red team needs a manager with 5+ years of penetration testing and red team experience plus at least two testers with 2+ years each and combined participation in at least five previous assignments; external testers need at least five references; and the threat intelligence provider and red team must be kept separate from each other, and neither may simultaneously perform blue team work for the same entity.
For a DORA TLPT engagement, internal testers are allowed, but narrowly. Article 26(8) requires that an entity using internal testers still contract external testers every third test, and significant credit institutions are restricted to external testers entirely. DORA Article 27(2) adds that the competent authority must approve the use of internal testers and the threat intelligence provider must always be external, and RTS Article 15 requires an internal test team of a lead plus at least two additional members, all employed by the entity (or an intra-group ICT provider) for the preceding 12 months.
One detail worth flagging plainly: neither DORA nor the RTS creates an EU register of approved TLPT providers. Your TLPT authority, not a marketing claim, is the actual gatekeeper here: under RTS Article 9(11) you have to show it your providers meet the requirements before you sign, and you can’t contract them if it disagrees.
Neither DORA nor the RTS sets a cost, and almost every published DORA TLPT figure is a vendor’s own estimate, sourced with varying rigor, that doesn’t reconcile with the others.
The most detailed published figure comes from SureCloud, a GRC software vendor, whose published table puts combined threat intelligence and red team provider fees at £150,000 to £310,000+, built from £30,000-£60,000 for threat intelligence plus £120,000-£250,000+ for the red team phase. Their table explicitly states preparation, closure, internal staff time, and remediation are additional costs on top of that range, and it’s a vendor’s estimate without a stated sample size or methodology, not an independent benchmark. SureCloud also sells GRC and testing-adjacent services itself, and its figures are published in GBP for a regime priced in EUR, so convert before you plan a budget against them.
nFlo, a firm that sells DORA and TIBER-compliant testing, publishes a different figure: EUR 30,000-80,000 for threat intelligence and EUR 100,000-350,000 for the red team phase at a mid-sized institution, reaching EUR 500,000 or more for the largest, again without a stated method or sample.
Other, larger ranges circulate in search summaries and on non-specialist blogs, but none we checked cites a source or a method, so we’ve left them out. If a figure doesn’t say whose engagements it’s based on, treat it as unverified.
One figure comes from a regulatory process rather than a sales page: a respondent to the ESAs’ 2024 consultation on the insurer thresholds put the cost impact at “around 500k€ average (with 10 to 12 weeks of testing),” and argued that wasn’t proportionate to risk. That’s a single stakeholder’s estimate made against the draft thresholds, not an ESA finding. If DORA is one of several frameworks on your plate, our comparison of how ten compliance frameworks actually treat penetration testing and our dedicated SOC 2, ISO 27001 and FedRAMP guides cover the others side by side.
If your entity hasn’t been notified that it’s required to run a DORA TLPT, and most DORA entities never will be, general testing is still required of you. Article 24-25’s annual testing programme applies regardless, and penetration testing is explicitly named as an acceptable test type under it.
This is where most guides stop, which is a gap worth naming: nothing about not being identified for TLPT changes your obligation to run regular, independent security testing, at least yearly, on the ICT systems and applications supporting your critical or important functions. It just means that testing doesn’t need to take the shape of a multi-month, regulator-supervised red team exercise. A standard penetration test, run by an independent tester (internal or external, with conflict-of-interest safeguards if internal), against the systems in scope, is one of the test types this tier explicitly accepts, alongside scans, gap analyses and scenario-based tests. If part of that testing programme now includes an AI-assisted or AI-run pentest, our guide on whether auditors accept AI-run pentest evidence is worth reading before you lean on it for DORA documentation.
Some national regulators also run voluntary TIBER-style testing programs alongside the mandatory DORA framework, so it’s worth checking with your own competent authority whether a voluntary intelligence-led exercise makes sense for your risk profile even without a TLPT notification. Our guide to choosing a penetration testing provider and our explainer on vulnerability assessment vs penetration testing both apply directly to scoping that Article 24-25 programme.
Two DORA TLPT structures exist for entities that share infrastructure with others. Pooled testing (DORA Article 26(4), RTS Article 6/8) applies when an ICT third-party provider’s participation in a normal TLPT would risk service quality or data confidentiality for its other, non-DORA customers; in that case, the financial entity and the provider can agree in writing that the provider directly contracts an external tester to run one pooled test covering several financial entities, under the direction of one designated financial entity, with the number of participating entities “duly calibrated taking into account the complexity and types of services involved.” Joint testing covers a different case: several entities using the same intra-group ICT provider, or belonging to the same group and sharing ICT systems, testing together.
The practical DORA TLPT relevance for most readers: if a critical vendor sits in your supply chain and also serves other DORA entities, you may be asked to participate in a pooled test rather than running an entirely separate one. Article 26(3) is clear that including a third-party provider in TLPT scope doesn’t reduce the financial entity’s own full responsibility for DORA compliance.
Once a DORA TLPT’s reports and remediation plans are agreed, the authority issues an attestation confirming the test was performed to the required standard, which exists specifically to enable mutual recognition between competent authorities across Member States (Article 26(7)).
Read a DORA TLPT attestation for what DORA itself says it is, not more. On this specific DORA TLPT point, recital 61 is explicit: attestations “should be solely for the purpose of mutual recognition and should not preclude any follow-up action needed to address the ICT risk to which the financial entity is exposed, nor should they be seen as a supervisory endorsement of a financial entity’s ICT risk management and mitigation capabilities.” A DORA TLPT attestation says the process was followed correctly. It is not a certificate that your systems are secure, and, per recital 61, it doesn’t stop your supervisor from following up on whatever the test found.
Let’s be direct: XHack is not a DORA TLPT provider. XHack does not meet DORA Article 27 or RTS Article 7, is not TIBER-EU or CBEST accredited, and is not CREST accredited. XHack’s team holds OSCP+, OSCP, C-AI/MLPen and CASA certifications plus Synack Red Team membership, which is real offensive experience but not Article 27 status, so check TLPT’s tester rules with your authority before you hire anyone, us included. If your entity has been notified that it’s in scope for TLPT, the test itself has to come from testers who meet those requirements (an external provider, or an internal team your authority has approved under Article 27(2)), and no penetration testing vendor should tell you otherwise.
What XHack actually does is different and still genuinely useful: independent penetration testing that produces the kind of technical evidence DORA’s general Article 24-25 testing programme names as acceptable. Our Assurance tier, starting at $5,000, scopes to internal and external web, host, API and mobile coverage with two certified testers, plus AI agents only if you give explicit permission, and the resulting report already maps findings against PCI DSS, SOC 2, ISO 27001, HIPAA and GDPR control language. DORA is not currently on that mapping list, and we’re not going to pretend it is; what the report gives you is the technical testing evidence, and your compliance team decides how that evidence supports your own Article 24-25 documentation.
There’s a second, more specific DORA TLPT use case: readiness before an engagement you already know is coming. Fixing the ordinary vulnerabilities and detection gaps first, through a standard engagement, means the qualified TLPT red team you eventually hire spends its 12-plus weeks of active testing on the paths that actually matter, not the easy findings a routine scan would have caught anyway. That’s practice, not TLPT evidence, and it doesn’t shorten or replace a single RTS deadline.
Our Enterprise tier, custom-quoted, covers red team and purple team operations and separate threat intelligence services for entities that want that capability on an ongoing basis. To be precise: they’re red team operations and threat intelligence work, not TLPT, and they aren’t mapped to the RTS’s phases. Our piece on what red team engagements actually look like covers that service in more depth than this compliance-focused piece has room for, and our AI red teaming guide covers the separate job of red teaming AI systems.
Privacy matters here too: if you use the XHack AI agent, pentest chats and session data stay on your own machine, and you can delete them any time. VAPT reports themselves are retained for 12 months.
Want a fixed-price quote scoped to general testing or readiness work? Request one. Prefer to talk it through first, including whether you actually need a TLPT-qualified provider instead of us? Book a free consultation. Brutal honesty is kind of our thing.
DORA TLPT (threat-led penetration testing) is an intelligence-led red team exercise required under DORA Articles 26-27, run against a financial entity’s live production systems using real threat intelligence, at least every three years (your authority can change that interval), but only for entities their competent authority identifies against specific criteria.
A regular penetration test, covered under DORA Articles 24-25, checks a specific system or environment for exploitable technical vulnerabilities. TLPT is broader: it starts from targeted threat intelligence about real attackers who would plausibly target your entity, then runs a red team exercise against live production systems to test whether those specific threats would succeed, supervised by your regulator from notification through attestation.
Only entities your competent authority identifies against RTS Article 2 criteria: credit institutions that are G-SIIs or O-SIIs, payment institutions above EUR 150 billion in transaction value in each of the two preceding years, e-money institutions above EUR 150 billion in transactions or EUR 40 billion outstanding, central securities depositories, central counterparties, major trading venues, and insurers meeting layered premium and technical-provision thresholds. Meeting a threshold doesn’t guarantee designation, because your authority also weighs impact and ICT risk profile, and other entity types, crypto-asset service providers among them, can be identified on those qualitative criteria alone.
The RTS sets one hard minimum and a series of hard deadlines, not the whole timeline: the active red team phase must last at least 12 weeks, the scope specification is due within 6 months of notification, the red team and blue team reports are due within 4 and 10 weeks of the active phase ending (both counted from the same point), and the summary report and remediation plan follow within 8 weeks of the authority’s confirmation. Added up, a first cycle realistically runs around 9 to 15 months from notification to attestation, by our own arithmetic from those deadlines, with provider procurement finished inside the preparation phase.
There’s no regulator-published figure. The most detailed vendor estimate (SureCloud) puts combined threat intelligence and red team provider fees at £150,000-£310,000+, excluding preparation, closure, internal staff time and remediation. Other vendors publish different ranges in different currencies. Treat every figure, including that one, as a vendor’s own estimate, not an independent benchmark.
No. XHack does not meet the DORA Article 27 or RTS Article 7 tester requirements and holds no TIBER-EU, CBEST or CREST accreditation. What XHack offers is independent penetration testing, one of the test types DORA Article 25(1) lists for the general Article 24-25 programme (your compliance team decides how the report fits that programme), and readiness testing to prepare for a TLPT run by a provider that meets Article 27, never a substitute for the TLPT itself.
Yes. DORA Article 24-25 requires almost every financial entity to run appropriate tests at least yearly on all ICT systems supporting critical or important functions, and penetration testing is one of the test types Article 25(1) names, regardless of whether you’re ever identified for TLPT.
DORA TLPT is a real, specific, heavily regulated requirement of its own, and it applies to far fewer entities than the volume of content written about it suggests. Almost everything published skips the details that actually matter once you’re inside the process: the exact thresholds that determine scope, the hard clocks the RTS sets for most phases, and what an attestation does and doesn’t mean once you have one.
If you’re not sure whether DORA TLPT applies to you, start with the RTS Article 2 thresholds above and a conversation with your competent authority, not a vendor’s sales page. If you know a DORA TLPT is coming, the timeline math above is the plan to work backward from. And if what you actually need right now is solid, independently tested evidence for your Article 24-25 programme or a cleaner baseline before a qualified TLPT red team walks in the door, that’s the part we can help with.
Categories
Related articles
