FAQEU DORA

DORA TLPT Selection

Competent authorities or TLPT authorities identify which financial entities must perform DORA threat-led penetration testing.

This FAQ helps understand the selection criteria, authority involvement, readiness timeline, provider checks, scope evidence, remediation records, and attestation artifacts.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Questions
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 25, 2026
Overview

DORA has applied since 17 January 2025. Advanced testing by means of threat-led penetration testing () applies to financial entities identified by the relevant authority. The authority considers the entity type, ICT risk profile, systemic importance, group and shared-system facts, and critical or important functions. Timings on this page are tied to cited sources; verify current legal source language before implementation decisions.

Search this module

Find a question or answer quickly

5 of 5 questions
Question 1

Who decides whether a financial entity must perform DORA TLPT?

Identified financial entities must carry out at least every 3 years. A competent authority may reduce or increase that frequency where the entity's risk profile and operational circumstances require it. Article 16 entities and microenterprises are excluded from TLPT.

Commission Delegated Regulation (EU) 2025/1190 refines that selection process. It uses the term for the public authority, delegated national financial-sector authority, or competent authority responsible for -related tasks. That TLPT authority assesses whether a financial entity is required to perform TLPT, participates in every phase of the test, and validates key documents and decisions.

  • Do not treat selection as a generic company-size threshold; the official criteria are financial-sector and ICT-risk specific.
  • Track the authority that made or communicated the selection decision, especially where the and the competent authority are different.
  • If the entity is part of a group that shares ICT systems or uses the same ICT intra-group service provider, capture whether authorities considered individual, joint, or .
  • If an entity believes is not justified despite meeting a listed category or quantitative criterion, record the authority assessment rather than relying on an internal exemption.

Does DORA let a financial entity decide on its own that it is outside selection?

No. The internal team should prepare the facts, but DORA selection depends on competent-authority or -authority identification. The evidence record should show the authority position, the entity type, ICT risk profile, systemic or impact factors, shared ICT-system facts, and any authority communication about whether TLPT is required.

Citations
Regulation (EU) 2022/2554 (DORA), Article 26

Supports the Article 26 rule that identified financial entities perform TLPT at least every 3 years and that competent authorities identify entities using impact, financial-stability, ICT-risk, maturity, and technology criteria.

Question 2

Which financial entities may be identified for DORA TLPT?

Delegated Regulation 2025/1190 starts from the financial entity's impact, systemic character, and ICT risk profile. It points the to impact-related factors such as size, cross-border services, interconnectedness, criticality, substitutability, business-model complexity, and whether the entity belongs to a systemic group sharing ICT systems.

It also points to ICT-risk factors such as the entity's threat landscape, dependence of critical or important functions on ICT, ICT architecture complexity, use of ICT third-party or intra-group providers, supervisory review outcomes, business-continuity maturity, response-and-recovery maturity, and real-time monitoring, detection, analysis, and response capability.

  • The RTS starts with specified categories and thresholds: G-SIIs, O-SIIs, and their member credit institutions; payment institutions above EUR 150 billion in payment transactions in each of the prior 2 calendar years; electronic money institutions above that payment threshold or EUR 40 billion in outstanding electronic money for each of those years; central securities depositories; central counterparties; qualifying electronic trading venues; and a subset of large insurance or reinsurance undertakings.
  • The RTS also allows authorities to assess other types of financial entities where qualitative factors make TLPT appropriate.
  • Meeting an entity-category or quantitative criterion is not the end of the analysis. The can release an entity where its overall impact, related financial-stability concerns, or ICT risk profile does not justify .
  • Microenterprises and entities under the Article 16 simplified ICT risk management framework are excluded from by DORA Article 26(1); this is not an authority-discretion test.

Are DORA selection criteria just revenue, employee count, or generic security maturity?

No. The RTS uses sector-specific quantitative gates for some categories and an authority assessment of financial-sector impact, systemic character, ICT risk profile, ICT maturity, critical or important functions, shared systems, and group structure. Generic revenue, headcount, or cyber-maturity thresholds cannot replace that test.

Citations
Question 3

What happens after a financial entity is selected for TLPT?

Selection starts a supervised preparation process before the red-team exercise. After notification from the , the financial entity must initiate and submit initiation information within 3 months. That information includes a project charter, lead contact details, intended use of internal or external testers, communication channels, and a code name.

The financial entity must then submit a scope specification document within 6 months of the authority notification. The management body approves the scope specification document, and the approves it if it is complete and supports an appropriate and effective .

  • Appoint a lead responsible for day-to-day management and control-team decisions.
  • Keep knowledge of planned or ongoing limited to the , management body, testers, threat intelligence provider, and on a need-to-know basis.
  • Scope critical or important functions by considering their criticality, day-to-day importance, exchangeability, interconnectedness, geographic location, sector dependence, and available threat intelligence.
  • Do not begin the testing phase until provider procurement or assignment is complete, the risk assessment has been consulted on with test managers, and authority validation points have been handled.

What readiness evidence should a selected financial entity prepare before DORA testing starts?

Prepare the authority notification, project charter, high-level project plan, lead details, communication-channel choices, code name, internal or external tester plan, control team validation, risk assessment, risk-management measures, provider due-diligence evidence, and management-approved scope specification document.

Citations
Question 4

How should scope, providers, and authority validation be documented?

The scope record should explain why each critical or important function and supporting ICT system is included or excluded. Annex II to Delegated Regulation 2025/1190 requires the scope specification to list all critical or important functions identified by the financial entity and, for included functions, the relevant ICT systems, outsourcing status, ICT third-party provider, jurisdictions, and preliminary flags.

Provider selection also needs evidence. The must assess testers and threat intelligence providers against DORA Article 27 and the RTS requirements before contracting, provide evidence to test managers, and not proceed where the concludes that the selected providers or testers do not comply with the applicable requirements.

  • Keep the function inventory, inclusion and exclusion rationale, supporting ICT systems, outsourced-system facts, provider names, jurisdictions, and preliminary flags.
  • Keep provider CVs, appropriate certifications, professional indemnity insurance evidence, references, conflict checks, separation of threat-intelligence and tester staff where relevant, and restoration-procedure commitments.
  • If internal testers are proposed, keep the authority approval, conflict-of-interest analysis, resource evidence, and proof that the threat intelligence provider is external.
  • If pooled or is considered, keep the authority feasibility assessment, designated financial entity, lead , participating entities, shared ICT provider facts, and each entity's own risk assessment.
Citations
Question 5

What evidence closes a DORA TLPT selection and testing cycle?

A selected entity should preserve both selection evidence and testing evidence. Selection evidence explains why the entity was identified, who the authority contact was, what scope was approved, and whether the test was individual, joint, or pooled. Testing evidence shows that the authority-supervised process was completed and that remediation is owned.

The active red team testing phase must last at least 12 weeks. After testing, the RTS requires red team and blue team reports, replay and purple teaming activities, a test summary report, remediation plans, and an attestation. The attestation is for mutual recognition and does not remove the financial entity's responsibility for the test impact or remediation.

  • Keep the selected-entity rationale, authority notification, authority validations, and any decision on individual, pooled, or .
  • Keep the targeted threat intelligence report, selected scenarios, red team test plan, weekly progress records, deviations, leg-ups, suspensions, and risk-management decisions.
  • Keep the red team report, blue team report, replay and purple-teaming outputs, test summary report, and remediation plan with root causes, priorities, owners, expected completion, and risks of non-implementation.
  • Keep the attestation showing dates, functions in scope, participating entities and providers, internal-tester use where relevant, active red team duration, involved authorities, and documents examined by the .

Does a DORA attestation mean the authority has endorsed the entity's overall ICT resilience?

No. DORA Article 26 frames the attestation as confirmation that the test was performed in accordance with the requirements for mutual recognition. The financial entity remains responsible for the impact of the test and for addressing findings through remediation.

Citations
Recommended next step

Prepare the authority-facing TLPT selection record

Use the cited sources listed here to verify obligations and the supporting evidence requirements.

Research workflow
Open Research Copilot for EU DORA

Verify TLPT selection, authority validation, provider checks, scope evidence, and remediation records using the cited sources on this page.

Explore next step
Talk to Sorena
Talk through TLPT readiness

Review your DORA TLPT selection facts, authority evidence, and testing-cycle records with Sorena.

Explore next step
Primary sources

References and citations

Regulation (EU) 2022/2554 (DORA), Article 26
eur-lex.europa.eu
Referenced sections
  • Supports the Article 26 attestation, mutual-recognition purpose, remediation-plan submission, and continuing responsibility of the financial entity.
"remain at all times fully responsible"
Regulation (EU) 2022/2554 (DORA), Articles 26 and 27
eur-lex.europa.eu
Referenced sections
  • Supports the tester requirements, internal-tester approval conditions, pooled testing rule, ICT third-party participation, and full responsibility of the financial entity.
"Requirements for testers"
Regulation (EU) 2022/2554 (DORA), Recital 43 and Article 26
eur-lex.europa.eu
Referenced sections
  • Supports that only identified financial entities perform advanced TLPT and that microenterprises and simplified-framework entities are not the target of TLPT selection.
"only financial entities meeting the criteria"
Related guides

Explore more topics

DORA Critical or Important Functions: mapping ICT dependencies and evidence
How DORA critical or important functions affect ICT service mapping, third-party contracts, register-of-information records, incidents, testing, and evidence.
DORA deadlines and compliance calendar for financial entities
Track DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and critical-provider oversight milestones.
DORA ICT Third-Party Contract Remediation Workflow
A DORA workflow for remediating ICT third-party contracts covering critical or important functions, subcontracting, audit rights, exits, register updates, and evidence.
DORA ICT Third-Party Contracts FAQ
What DORA requires in ICT third-party contracts, including critical or important functions, audit and access rights, termination, exit, subcontracting, register updates, and evidence.
DORA ICT third-party risk and contract clauses guide
Official source DORA guide for financial entities in scope, ICT third-party risk, contract clauses, subcontracting controls, register evidence, audit rights, exit planning, and oversight.
DORA incident classification forms: criteria, fields, and reporting clocks
Official source guide to DORA ICT incident classification forms: major-incident criteria, significant cyber-threat notifications, report fields, time limits, evidence, and reclassification records.
DORA incident clock workflow: classification, reports, deadlines, and evidence
Official source DORA workflow for starting the major-incident reporting clock, classifying ICT incidents, submitting initial, intermediate, and final reports, and preserving authority evidence.
DORA major ICT incident reporting: classification, reports, and timing
Official source DORA guide to major ICT-related incident classification, initial notifications, intermediate and final reports, competent authority routing, and significant cyber threat notifications.
DORA major ICT incident thresholds: what triggers reporting?
FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs based on EU DORA RTS and ITS texts.
DORA Register of Information FAQ: ICT Third-Party Arrangements
FAQ on the DORA register of information: who maintains it, which ICT third-party arrangements it covers, template fields, critical functions, reporting, data quality, and evidence.
DORA Register of Information Import and Build Workflow
Build a DORA register of information from procurement, vendor, contract, service, function, and subcontractor data using the official register templates and validation checks.
DORA Register of Information Template: ICT Provider Fields and Evidence
An official source DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
DORA vs EBA outsourcing guidelines: ICT third-party risk comparison
Compare binding DORA ICT third-party risk duties with the EBA/ESA outsourcing baseline for registers, critical functions, contracts, subcontracting, exit, incident reporting, and evidence.
DORA vs ISO 22301: ICT resilience and business continuity compared
Compare DORA's binding ICT operational resilience duties for financial entities with ISO 22301's business continuity management system requirements.
DORA vs ISO/IEC 27001: legal ICT resilience obligations and ISMS controls
Compare EU DORA and ISO/IEC 27001 across scope, governance, incident reporting, testing, ICT third-party risk, certification, evidence, overlap, and gaps.
DORA vs NIS2: financial-sector obligations, overlap, and evidence
Compare DORA and NIS2 for financial entities, ICT providers, incident reporting, management accountability, third-party risk, supervisory routes, and reusable evidence.
DORA vs PSD2 incident reporting: major ICT and payment incidents
Compare DORA major ICT-related incident reporting with PSD2 major operational or security payment incident reporting, including scope, triggers, report stages, recipients, and evidence.
EU DORA Applicability Test for Financial Entities and ICT Providers
An official source DORA applicability test for financial-entity scope, ICT third-party services, critical or important functions, exclusions, proportionality, and evidence.
EU DORA Compliance Checklist for Financial Entities
An official source DORA checklist covering ICT risk governance, major incident reporting, resilience testing, TLPT, ICT third-party contracts, register-of-information records, and audit evidence.
EU DORA Compliance Obligations and Evidence Guide
An official source DORA compliance guide covering ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, registers, governance, oversight, and evidence.
EU DORA FAQ: scope, incidents, ICT contracts, testing, and evidence
Concise DORA FAQ covering who is in scope, proportionality, ICT third-party contracts, register-of-information records, major ICT incident thresholds and reporting, TLPT, testing, enforcement, and evidence.
EU DORA ICT risk management control baseline
An official source DORA control baseline for ICT risk governance, asset and dependency mapping, protection, detection, response, recovery, testing, third-party risk, and evidence.
EU DORA ICT subcontracting chain controls for critical functions
DORA guide to ICT subcontracting chains for critical or important functions: prior assessment, contract conditions, register fields, monitoring, exit rights, and evidence.
EU DORA penalties and fines: enforcement powers and limits
Official source guide to DORA enforcement: competent-authority powers, administrative penalties, remedial measures, publication rules, and Lead Overseer penalty payments for critical ICT third-party providers.
EU DORA Register of Information Data Model: templates, fields, and evidence
Field-level guide to the EU DORA register of information data model: templates B_01 to B_07, provider identifiers, contract links, subcontracting chains, critical-function assessments, dates, and export evidence.
EU DORA Requirements Overview: ICT risk, incidents, testing, and third-party risk
An official source overview of the main EU DORA requirements for financial entities: governance, ICT risk management, incident reporting, resilience testing, TLPT, ICT third-party risk, register of information, oversight, proportionality, and evidence.
EU DORA Scope and Covered Entities: financial entities and ICT providers
Classify whether DORA applies to a financial entity, ICT third-party provider, group arrangement, branch, or critical ICT service dependency.
EU DORA Scope and Proportionality Workflow
Classify DORA covered entities, simplified-framework status, critical or important functions, ICT dependencies, evidence records, and governance approvals.
EU DORA testing and TLPT readiness guide
An official source DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
EU DORA TLPT eligibility workflow for financial entities
Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance.
EU DORA TLPT Runbook: scope, providers, reports, and remediation
Build a DORA threat-led penetration testing runbook around authority coordination, scope validation, provider controls, active testing, closure reports, remediation, and attestation.
How does proportionality work under EU DORA?
An official source FAQ on DORA proportionality: what can be scaled, who may use the simplified ICT risk framework, what evidence supports the decision, and which duties cannot be waived.
How to build a DORA register of information
Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.