---
title: "EU DORA TLPT eligibility workflow for financial entities"
canonical_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow"
source_url: "https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow"
author: "Sorena AI"
description: "Check how DORA TLPT authorities identify financial entities for threat-led penetration testing and what evidence supports scope, readiness, providers, and governance."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "EU DORA TLPT eligibility"
  - "DORA threat-led penetration testing"
  - "TLPT authority"
  - "critical or important functions"
  - "DORA Article 26"
  - "DORA RTS 2025/1190"
  - "EU DORA"
  - "DORA TLPT"
  - "threat-led penetration testing"
  - "financial entities"
  - "ICT risk management"
  - "TIBER-EU"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# 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.

*Artifact Guide* *EU DORA*

## DORA TLPT eligibility workflow

Use this workflow to prepare a grounded TLPT eligibility file before or after a TLPT authority asks whether a financial entity must perform threat-led penetration testing.

The workflow separates authority identification, impact and systemic relevance, critical-or-important-function scope, control-team readiness, provider evidence, and group or cross-border coordination.

DORA TLPT eligibility is not a self-selected penetration-test program. Competent authorities or designated TLPT authorities identify financial entities for advanced threat-led penetration testing by looking at impact, systemic character, ICT risk profile, and ICT maturity. The practical file should show why the entity is or is not likely to be selected, which critical or important functions would be in scope, and whether governance and evidence are ready for authority validation.

## Start with the authority process, not an internal threshold

Under DORA Article 26, financial entities identified for TLPT carry out advanced threat-led penetration testing at least every three years, with the competent authority able to adjust frequency based on risk profile and operational circumstances. The selection decision is authority-led: Member States may designate a single public authority for TLPT matters, and delegated tasks do not remove the relevant competent authority role where tasks remain with it.

Build the eligibility file around the authority that can act on the entity. Record the entity's DORA financial-entity type, home Member State, competent authority, any designated TLPT authority, and whether any tasks have been delegated to another national authority. For significant credit institutions and cross-border entities, record the Union or national supervisory links instead of assuming a single local contact.

- Authority record: competent authority under DORA, any designated TLPT authority, delegated TLPT tasks, and the named contact channel once notified.
- Entity record: financial-entity category, licences or authorisations, Member States of operation, and group or branch structure relevant to TLPT coordination.
- Frequency record: previous TLPT date or equivalent advanced test, current authority request, and any written authority change to the default three-year frequency.
- Evidence limit: do not create a private numerical cut-off unless it comes from the TLPT RTS or from the authority's written instruction.

Sources for this answer:

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA Article 26 establishes TLPT frequency, authority identification, designated TLPT authorities, attestations, pooled testing, and use of testers.
- [Delegated Regulation (EU) 2025/1190 on DORA TLPT criteria](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - The TLPT RTS states that TLPT authorities identify entities and clarifies authority responsibilities for test managers, validation, cross-border, joint, and pooled TLPTs.

## Record selection criteria without inventing extra tests

The 2025 TLPT RTS gives the selection structure. TLPT authorities assess impact, systemic character, and ICT risk profile. Impact and systemic factors include size, services across one or more Member States, interconnectedness with other financial entities, criticality or importance of services for the financial sector, substitutability, business-model complexity, and group-level systemic character where ICT systems are shared.

The RTS then names categories that must perform TLPT unless the authority's overall assessment shows the TLPT is not justified. Those categories include G-SIIs, O-SIIs and entities in those groups, certain high-volume payment and e-money institutions, central securities depositories, central counterparties, qualifying electronic trading venues, and qualifying insurance or reinsurance undertakings. Use those criteria as evidence categories, not as a guarantee of selection or exclusion.

- Impact evidence: market-share position where available, range of activities, Member States served, service criticality, substitutability, and concentration of important services.
- Systemic evidence: G-SII or O-SII status, group membership, shared ICT systems, ICT intra-group service providers, and dependencies that could affect national or Union financial stability.
- ICT risk evidence: threat landscape, dependence of critical or important functions on ICT, ICT architecture complexity, third-party or intra-group ICT service reliance, supervisory findings, business-continuity maturity, response and recovery maturity, and security monitoring capability.
- Category evidence: map only the RTS-supported categories and quantitative criteria that apply to the entity; do not add unsupported revenue, employee-count, client-count, or incident-count thresholds.

Sources for this answer:

- [Delegated Regulation (EU) 2025/1190 on DORA TLPT criteria](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Article 2 lists the impact, systemic, and ICT-risk factors TLPT authorities use and the financial-entity categories that normally require TLPT unless the authority assessment does not justify it.
- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA Article 26 requires competent authorities to identify TLPT entities by impact-related factors, financial-stability concerns, and specific ICT risk profile or maturity.

## Prepare the scope and readiness file before notification

Once a TLPT authority notifies a financial entity that a TLPT is to be carried out, the 2025 RTS requires initiation information within three months and a management-body-approved scope specification document within six months. That scope document must list all critical or important functions identified by the financial entity and explain why each function is included or excluded.

Readiness evidence should therefore exist before notification. Keep a current inventory of critical or important functions, supporting ICT systems, outsourced or intra-group ICT services, jurisdictions where systems are used, and preliminary confidentiality, integrity, authenticity, and availability flags. Where a third-party or intra-group provider supports a critical or important function, record how participation, safeguards, pooled testing, or joint testing would be handled.

- Initiation pack: project charter, high-level project plan, control team lead, tester approach, secure communication channels, and code name.
- Scope pack: all critical or important functions, inclusion or exclusion rationale for each function, supporting ICT systems, outsourced-provider names, jurisdictions, and preliminary flags.
- Risk pack: live-production testing risks, possible financial-sector or financial-stability impact, crisis escalation risk, data corruption risk, interruption risk, blue-team activity risk, and restoration risk.
- Provider pack: evidence that threat intelligence providers and external testers meet RTS criteria, including experience, references, insurance, separation, conflict management, restoration procedures, and prohibited activities.

Sources for this answer:

- [Delegated Regulation (EU) 2025/1190 on DORA TLPT criteria](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - Articles 4, 5, 7, 9, and Annex II define control-team arrangements, TLPT risk management, provider selection evidence, initiation information, and scope specification content.
- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - DORA Article 26 requires TLPT to cover several or all critical or important functions and live production systems supporting those functions.

## Govern the test as an authority-validated resilience exercise

A DORA TLPT is not ordinary vulnerability scanning. The TLPT authority participates in all phases, validates key documentation, and can prevent contracting where selected providers do not meet DORA, RTS, or lawful national-security requirements. The financial entity remains responsible for the impact of the test even when providers and ICT third-party service providers participate.

For group, cross-border, joint, or pooled testing, identify the lead TLPT authority and the other TLPT authorities that may participate as observers or test managers. If the entity uses shared ICT systems, an ICT intra-group service provider, or a third-party provider used by multiple financial entities, record why an individual, joint, or pooled TLPT is appropriate and how the scope remains effective.

- Governance evidence: management-body approval of scope, control team lead mandate, need-to-know restrictions, secrecy arrangements, authority validations, and escalation process.
- Testing evidence: targeted threat intelligence report, selected scenarios, red team test plan, weekly progress reporting, leg-ups, change approvals, suspension or limited purple-team decisions, and active red-team testing duration.
- Closure evidence: red team report, blue team report, replay and purple teaming outputs, test summary report, remediation plan, attestation, and notification to the relevant competent authority where different from the TLPT authority.
- Cross-border evidence: host Member States with critical or important functions, other TLPT authorities involved, lead authority decision, shared ICT systems, intra-group service providers, and pooled-testing rationale.

Sources for this answer:

- [Delegated Regulation (EU) 2025/1190 on DORA TLPT criteria](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - The RTS sets authority validation points, test-manager involvement, closure reports, remediation-plan content, attestations, and cooperation rules for cross-border, joint, and pooled TLPTs.
- [ECB note on TIBER-EU and DORA TLPT](https://www.ecb.europa.eu/press/pr/euro/html/index.en.html?ref=sorena.io) - The ECB grounding explains that TIBER-EU can support DORA TLPT when formal TLPT requirements set by competent authorities are fulfilled.

*Recommended next step*

*Placement: before sources*

## Prepare TLPT scope, authority, and evidence records

Sorena can help turn DORA TLPT selection criteria into a cited eligibility record, critical-function scope file, provider evidence pack, and remediation-ready governance workflow.

- [Open Research Copilot for DORA TLPT](/solutions/research-copilot.md): Ask source-linked questions about TLPT selection, critical or important functions, provider criteria, test phases, remediation, and attestations.
- [Review DORA TLPT readiness](/contact.md): Check whether your TLPT authority, entity category, scope evidence, control team, providers, and governance records are ready for authority validation.

## Primary sources

- [Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554&ref=sorena.io) - Primary DORA source for Article 26 TLPT frequency, scope, authority identification, pooled testing, attestation, and tester requirements.
  - Quote: "Threat-led penetration testing"
- [Delegated Regulation (EU) 2025/1190 on DORA TLPT criteria](https://eur-lex.europa.eu/eli/reg_del/2025/1190/oj/eng?ref=sorena.io) - RTS source for identifying financial entities required to perform TLPT, selection criteria, authority validation, scope documentation, provider evidence, testing phases, remediation, attestation, and cooperation.
  - Quote: "criteria used for identifying financial entities"
- [ECB note on TIBER-EU and DORA TLPT](https://www.ecb.europa.eu/press/pr/euro/html/index.en.html?ref=sorena.io) - ECB source used for the limited point that TIBER-EU is intended to help entities and authorities perform DORA TLPT when formal authority requirements are met.
  - Quote: "TIBER-EU"

## Related Topic Guides

- [DORA Critical or Important Functions: mapping ICT dependencies and evidence](/artifacts/eu/digital-operational-resilience-act/critical-and-important-functions.md): 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](/artifacts/eu/digital-operational-resilience-act/deadlines-and-compliance-calendar.md): Calendar the grounded DORA dates and recurring evidence: 17 January 2025 application, incident reporting clocks, register updates, annual reporting, TLPT cadence, and CTPP oversight milestones.
- [DORA ICT Third-Party Contract Remediation Workflow](/artifacts/eu/digital-operational-resilience-act/contract-remediation-workflow.md): 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](/artifacts/eu/digital-operational-resilience-act/faq/ict-third-party-contracts.md): 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](/artifacts/eu/digital-operational-resilience-act/third-party-risk-and-contract-clauses.md): Source-grounded 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](/artifacts/eu/digital-operational-resilience-act/incident-classification-forms.md): Grounded 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](/artifacts/eu/digital-operational-resilience-act/incident-clock-workflow.md): Grounded 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](/artifacts/eu/digital-operational-resilience-act/major-incident-reporting.md): Source-grounded 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?](/artifacts/eu/digital-operational-resilience-act/faq/major-incident-thresholds.md): FAQ on DORA major ICT-related incident classification thresholds, recurring incidents, reporting triggers, and evidence inputs grounded in EU DORA RTS and ITS texts.
- [DORA Register of Information FAQ: ICT Third-Party Arrangements](/artifacts/eu/digital-operational-resilience-act/faq/register-of-information.md): 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](/artifacts/eu/digital-operational-resilience-act/roi-import-and-build-workflow.md): 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](/artifacts/eu/digital-operational-resilience-act/dora-register-of-information-template.md): A grounded DORA register of information template for ICT third-party contracts, provider hierarchy, critical functions, dates, statuses, reporting, and evidence.
- [DORA TLPT selection: who can be required to test?](/artifacts/eu/digital-operational-resilience-act/faq/tlpt-selection.md): FAQ on DORA threat-led penetration testing selection: who identifies financial entities, what criteria are used, what the TLPT authority validates, and what evidence to keep.
- [DORA vs EBA outsourcing guidelines: ICT third-party risk comparison](/artifacts/eu/digital-operational-resilience-act/dora-vs-eba-outsourcing-guidelines.md): 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](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-22301.md): 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](/artifacts/eu/digital-operational-resilience-act/dora-vs-iso-27001.md): 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](/artifacts/eu/digital-operational-resilience-act/dora-vs-nis2.md): 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](/artifacts/eu/digital-operational-resilience-act/dora-vs-psd2-incident-reporting.md): 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](/artifacts/eu/digital-operational-resilience-act/applicability-test.md): A source-grounded 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](/artifacts/eu/digital-operational-resilience-act/checklist.md): A source-grounded 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](/artifacts/eu/digital-operational-resilience-act/compliance.md): A source-grounded 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](/artifacts/eu/digital-operational-resilience-act/faq.md): 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](/artifacts/eu/digital-operational-resilience-act/ict-risk-management-control-baseline.md): A source-grounded 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](/artifacts/eu/digital-operational-resilience-act/subcontracting-chain-controls.md): 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](/artifacts/eu/digital-operational-resilience-act/penalties-and-fines.md): Grounded 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](/artifacts/eu/digital-operational-resilience-act/register-of-information-data-model.md): 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](/artifacts/eu/digital-operational-resilience-act/requirements.md): A grounded 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](/artifacts/eu/digital-operational-resilience-act/scope-and-covered-entities.md): 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](/artifacts/eu/digital-operational-resilience-act/scope-and-proportionality-workflow.md): 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](/artifacts/eu/digital-operational-resilience-act/testing-and-tlpt-readiness.md): A grounded DORA guide for resilience testing, TLPT eligibility, authority interaction, test evidence, remediation plans, and avoiding unsupported testing cadence.
- [EU DORA TLPT Runbook: scope, providers, reports, and remediation](/artifacts/eu/digital-operational-resilience-act/tlpt-runbook.md): 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?](/artifacts/eu/digital-operational-resilience-act/faq/proportionality.md): A grounded 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](/artifacts/eu/digital-operational-resilience-act/register-of-information-how-to-build.md): Build a DORA register of information from contracts, ICT services, providers, functions, subcontractors, risk assessments, audit evidence, exit plans, and export checks.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/digital-operational-resilience-act/tlpt-eligibility-workflow