“We Need a DORA Red Team”: Is the Request Ready for TLPT Providers?
Three incomplete group fragments reveal whether a DORA red-team request is ordinary penetration testing, TLPT preparation or an actionable provider procurement.
Signals to watch
- A competent-authority notification or another verifiable regulatory trigger identifies the financial entity for TLPT
- Critical or important functions and their live production systems begin to define the test rather than a generic application scope
- A control-team lead, threat-intelligence provider, tester route and third-party ICT participation are connected to a dated procurement decision
“We need a DORA red team” is not yet a threat-led penetration-testing procurement. The request becomes ready for TLPT provider review only when a verifiable regulatory trigger, critical or important functions, live-production scope, test governance and a provider-selection decision begin to describe the same exercise. Without those facts, it may be an ordinary penetration test or an internal TLPT preparation discussion.
Illustrative industry case — this composite scenario explains a buying-signal and qualification pattern. It is not a customer story, real group conversation, test, regulatory decision or record of commercial results.
The reader is a financial-sector threat-led penetration-testing provider sales director following authorised Telegram groups used by EU banking-resilience teams, fintech security leaders, red-team providers, threat-intelligence specialists and critical ICT suppliers. A day matters because the financial entity may already be choosing providers or drafting the scope it will send for authority validation. The messages still cannot prove that the writer represents an identified entity, controls procurement or has permission to test any system.
Fragment one: “DORA red team” is still ordinary demand
The first composite fragment says:
“Need a DORA red team this year. Mostly external apps. Looking for firms with finance experience.”
This is commercially relevant but not TLPT-ready. It names a regulation, a broad service and a provider preference. It does not identify the financial entity, competent authority, critical or important functions, live production systems, internal governance or whether “red team” means a normal security assessment.
That distinction has a legal basis. DORA Article 24 requires a broad digital operational resilience testing programme for covered financial entities other than microenterprises, and Article 25 lists many possible tests, including vulnerability assessments, source-code reviews, scenario-based testing and penetration testing. Article 26 creates the narrower advanced testing route known as threat-led penetration testing (TLPT).
At this stage, the sales director asks one question: Has the financial entity been identified for DORA TLPT by the competent authority, or is it independently exploring a red-team exercise? Until the trigger is evidenced, route the discussion as ordinary penetration-testing demand. The broader article on where penetration-testing demand appears in Telegram groups can support that path without relabeling it TLPT.
Fragment two: a regulatory trigger changes the conversation
A later fragment adds:
“The authority notification is with legal. Payments and customer authentication were named. We still need to map the systems.”
This new fact moves the case into TLPT preparation, provided a qualified person verifies the notification. DORA Article 26 requires identified entities to carry out TLPT at least every three years as a baseline, although the competent authority can reduce or increase that frequency based on risk profile and operational circumstances.
The function names matter more than the phrase “external apps.” Each TLPT must cover several or all critical or important functions and run on live production systems supporting them. The financial entity must identify the underlying ICT systems, processes and technologies—including relevant outsourced or contracted ICT services—and assess which functions belong in scope. The competent authority validates the precise scope.
The provider still cannot quote active testing from these two lines. Unknowns include the jurisdiction and TLPT authority, exact functions, production dependencies, third-party ICT services, data and continuity risks, test timing, permitted attack objectives and procurement authority. The next output is a controlled preparation call, not a test plan.
Fragment three: governance makes provider procurement visible
The third fragment says:
“Control team lead is appointed. Scope draft includes the payment platform and one managed identity service. We are separating threat intelligence and red-team bids before the authority review.”
This is the first fragment that can justify provider-procurement follow-up. A control-team lead exists, two candidate dependencies appear, and a provider decision precedes an authority review. It remains incomplete: neither provider has been selected, the scope has not been validated, the managed service’s participation is unresolved, and no budget or authorised testing instruction is shown.
Commission Delegated Regulation (EU) 2025/1190 explains why those missing pieces matter. The control team manages the test while preserving secrecy. The financial entity prepares a scope specification document approved by its management body and submitted for TLPT-authority approval. Threat intelligence must be supplied externally; testers and the threat-intelligence provider have defined expertise, experience, assurance and insurance expectations. Procurement or assignment must finish before the testing phase begins.
This is not a conventional application pentest expanded with a longer report. TLPT uses targeted threat intelligence to build realistic scenarios across people, processes and technologies supporting critical or important functions. The active red-team testing phase takes place on live production systems and, under the Delegated Regulation, lasts at least 12 weeks. That exposure requires explicit risk controls, confidentiality, communication, suspension and restoration arrangements.
What the sales director should verify before accepting the brief
The three fragments create a practical readiness split:
- Ordinary penetration testing: a product, application or environment needs assessment, but there is no verified TLPT identification or Article 26 governance.
- TLPT preparation: the regulatory trigger and functions can be verified, while system mapping, control-team authority, risk controls or authority-validated scope remain unfinished.
- Provider procurement: the control team is operating, scope and authority milestones are known, and the entity is selecting a threat-intelligence provider and eligible testers for a defined exercise.
Before moving the third state into a provider review, verify the original authority communication, financial entity and jurisdiction; critical or important functions; live-production systems and third-party dependencies; control-team lead and management-body involvement; internal, external, joint or pooled route; provider-selection criteria; secrecy and data-handling arrangements; insurance; stop conditions; remediation ownership; and the next authority or procurement date.
No Telegram fragment authorises access or testing. Written authority, safe rules of engagement and the approvals required by the financial entity and TLPT authority must precede operational work.
The DORA register is a related record, not the TLPT scope
Third-party ICT dependencies may appear both in a TLPT scope and in the DORA register of information, but the tasks differ. The register records contractual arrangements for ICT services; TLPT selects critical or important functions and the live systems, processes and technologies that support them. The DORA register remediation article handles the data relationship, not test authorisation or red-team scope.
TOP Prospect can connect these incomplete fragments from groups a user intentionally connects and is authorised to access, retain original wording, sources and time, remove duplicates and rank them for human review. It cannot verify an authority notice, identify critical functions, approve scope, assess provider eligibility, access production, contact participants or authorise testing. If authorised-group discovery later enters the buying decision, the pricing page shows the public options.
Key facts
- DORA separates general resilience testing from Article 26 TLPT.
- Competent authorities identify the financial entities required to perform TLPT; the baseline frequency is at least every three years.
- TLPT covers critical or important functions and operates on supporting live production systems.
- The financial entity retains responsibility when third-party ICT services or testers participate.
- An authority attestation supports mutual recognition; it is not an endorsement that the entity is secure.
FAQ
Is every penetration test performed by a DORA-regulated entity a TLPT?
No. TLPT applies to identified entities and follows specific scope, governance, production, provider and authority-validation requirements.
How often must an identified financial entity perform TLPT?
At least every three years as the Article 26 baseline. The competent authority may reduce or increase the frequency based on risk profile and operational circumstances.
Can a conventional penetration-testing provider perform DORA TLPT?
Not on that description alone. Testers and threat-intelligence providers must satisfy the applicable DORA and Delegated Regulation requirements, and the TLPT authority participates in provider and test decisions.
Does a TLPT attestation mean the authority endorses the entity’s security?
No. It confirms that the test was performed in accordance with the requirements as evidenced in the documentation for mutual-recognition purposes. The financial entity remains responsible.
Frequently asked questions
Is every penetration test performed by a DORA-regulated entity a TLPT?
No. DORA distinguishes general digital operational resilience testing from advanced threat-led penetration testing. TLPT applies to financial entities identified by the competent authority and follows specific scope, governance, live-production, provider and authority-validation requirements.
How often must an identified financial entity perform TLPT?
DORA Article 26 sets a baseline of at least every three years for identified financial entities. The competent authority may reduce or increase the frequency based on the entity risk profile and operational circumstances.
Can a conventional penetration-testing provider perform DORA TLPT?
Not on that description alone. Article 27 and Delegated Regulation (EU) 2025/1190 set suitability, expertise, independence or assurance, insurance, experience and other requirements for testers and threat-intelligence providers.
Does a TLPT attestation mean the authority endorses the entity’s security?
No. The attestation supports mutual recognition by confirming performance in accordance with the requirements as evidenced in the documentation. The financial entity remains responsible, including for remediation and test impacts.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
