DORA TLPT RTS Explained | Regulation 2025/1190 in Practice

Use the final RTS to resolve delivery responsibilities

The final TLPT RTS should inform the way the engagement is prepared and governed, not merely appear in a proposal’s reference list. Ask which participant owns each deliverable, how dependencies are resolved and what evidence supports completion. Keep the primary legal text available when interpreting the process.

• Connect the regulatory process to a practical responsibility and evidence matrix.
• Separate threat-intelligence work, test execution and closure decisions.
• Confirm entity-specific authority expectations before finalising the plan.

See how the engagement is scoped · Review DORA and RTS sources

What is the DORA TLPT RTS?

The DORA TLPT RTS is Commission Delegated Regulation (EU) 2025/1190. It translates DORA’s advanced threat-led penetration testing obligation into a detailed process: which financial entities are selected, how a test is governed and scoped, what providers must demonstrate, how testing proceeds, and what evidence follows.

For a CISO, control team lead or procurement owner, the practical challenge is connecting those requirements into one deliverable programme. An excellent technical report cannot compensate for missing authority approvals, an inadequately justified scope or a closure process that was never planned. Equally, a complete document set is of limited use if it cannot explain what happened to the critical functions under test.

This guide follows the final RTS and distinguishes legal requirements from our practical planning suggestions. For an engagement overview, visit our DORA TLPT services homepage. For a shorter starting point, see the DORA TLPT requirements guide.

Sources: final TLPT RTS, including Article 17; DORA Article 26. The two photographic images are AI-generated illustrations, not records of a client engagement.

DORA, the TLPT RTS and TIBER-EU: which takes precedence?

DORA is the parent regulation. Articles 26 and 27 address advanced testing and tester requirements. The TLPT RTS adds the detailed rules made under that mandate. TIBER-EU supplies an established operating framework and supporting guidance for intelligence-led red-team tests.

The ECB updated TIBER-EU to align with DORA in 2025. Its implementation guide for significant institutions expressly distinguishes the binding legislation from the framework used to implement it. That guide concerns the ECB’s process for identified significant institutions; it should not be presented as the authority procedure for every financial entity in Europe.

In procurement, require the proposal to identify all three layers: the legal requirements, the applicable authority process and the delivery method. “TIBER-style” is not an approval status. A voluntary red-team exercise, even a rigorous one, does not automatically receive recognition as the entity’s required DORA TLPT.

Useful official references: the ECB announcement of the updated TIBER-EU framework, the TIBER-EU framework and guidance library, and the TIBER-EU SSM implementation guide.

Who must perform TLPT under the RTS?

Article 2 combines selection criteria with an authority assessment of impact, systemic importance and ICT risk. The population is not defined by a universal employee count, a generic revenue threshold or the fact that a company sells a financial product. Nor does being outside one numerical threshold settle every applicability question.

The RTS addresses categories including systemically important credit institutions, qualifying payment and electronic-money institutions, central securities depositories, central counterparties, certain electronic trading venues and qualifying insurance or reinsurance undertakings. The detailed conditions differ between categories. Authorities also have powers within the selection framework that make a simple online yes/no calculator unreliable.

Treat these as examples to route an applicability review, not a complete determination. Record the legal entity, supervisory perimeter, relevant notification, lead authority and any group-level arrangements. An instruction addressed to one group company should not casually be assumed to cover every subsidiary or shared platform.

Selection criteria: TLPT RTS Article 2.

Our who needs TLPT guide helps organise the initial questions. Confirm the conclusion through the responsible authority process before committing to an execution date.

Roles, secrecy and decision-making

Article 3 requires the authority to designate a test manager and at least one alternate. Article 4 requires the financial entity to appoint a control team lead and establish organisational safeguards. The control team lead needs the mandate to make timely decisions, not simply a calendar-management role.

Secrecy matters because the test examines real defensive behaviour. Limit planned and ongoing test information to the relevant people on a need-to-know basis. Agree how the control team learns about detections without unnecessarily revealing the exercise, and how it communicates with the test managers before involving blue-team staff. Use the agreed code name and secure channels consistently.

A practical governance pack should identify who can approve an adaptation, pause activity, involve an ICT provider, handle an actual incident and authorise resumption. Establish deputies and out-of-hours contacts. Where a decision affects scope or the test plan, follow the RTS approval route rather than relying on an informal chat between the delivery teams.

• Management body: approve the scope specification and resource the entity’s responsibilities.
• Control team: maintain the risk picture, secrecy and decisions across the test.
• Authority test managers: oversee compliance and participate in the defined approval process.
• Threat-intelligence provider: develop entity-specific intelligence and remain available during testing.
• Red and blue teams: produce complementary evidence of offensive activity and defensive response.

Organisational requirements: TLPT RTS Article 4.

See how to organise the TLPT control team for further preparation detail.

DORA TLPT RTS deadlines: do not mix up the clocks

The last two deadlines are frequently misread. The trigger is the authority’s notification that it has assessed the red and blue team reports for the required annex content. It is not automatically the final day of red-team operations. Keep the notification itself in the project record so the date is auditable.

The six-month scope deadline is not an instruction to wait six months before acting. Provider procurement, dependency mapping, management approval and third-party permissions can all become the limiting factor. Work backwards from the required submissions and reserve time for questions and revisions. The RTS does not turn the entire engagement into a fixed twelve-week package.

Closure requirements: TLPT RTS Article 12.

For planning context, see our TLPT timeline guide.

Scoping: start with functions, then follow dependencies

DORA Article 26 requires testing of several or all critical or important functions, on the live production systems supporting them. RTS Article 9 and Annex II make the scope specification more concrete. The document lists the entity’s identified critical or important functions and explains inclusion or exclusion. For included functions it identifies supporting ICT systems, outsourcing, jurisdictions and preliminary flags.

A flag is an agreed test objective linked to a security aspect such as confidentiality, integrity, authenticity or availability. It should make the intended proof understandable. “Compromise the bank” is too vague to govern safely; a defined objective associated with a named business service gives the team something to assess and the control team something to authorise.

For an illustrative payment function, map the customer channel, identity plane, approval workflow, transaction processing, privileged operations and external connectivity. Identify who owns each dependency and which provider agreements affect testing. Distinguish a directly tested component from a dependency that is documented but subject to an agreed limitation. Do not silently present the latter as having been tested.

Keep a scope-decision register. Each entry can record the function, systems, inclusion rationale, owner, third parties, geographic dependencies, proposed flags and open permissions. This is a practical working format, not a replacement for Annex II or the authority’s template. It makes changes easier to review when intelligence or technical findings alter the proposed approach.

Preparation and scope approval: TLPT RTS Article 9.

Related: defining a DORA TLPT scope and TLPT readiness checklist.

Provider requirements: what Article 7 actually asks for

Provider due diligence must assess the people assigned to the test and the evidence behind the proposal. Article 7 supplements DORA Article 27 with specific requirements for the threat-intelligence provider and external testers. A certification logo on a website is not the entire assessment.

Ask the supplier to map evidence to each relevant paragraph rather than asserting “RTS compliant”. Verify availability for the required period, replacement-personnel controls, report responsibilities and the proposed interaction with the authority test managers. References and experience are separate questions: a company’s historic portfolio does not prove that the named team meets the staffing requirements.

Article 7 includes an exceptional-circumstances provision for departures from certain criteria, coupled with appropriate mitigating measures and records. Do not treat it as a routine procurement shortcut or grant yourself a blanket waiver. Escalate any intended exception through the authority process and document the reasoning before appointments are finalised.

Provider selection requirements: TLPT RTS Article 7.

Use our procurement guide and DORA Article 27 tester requirements explanation to structure questions. This article describes assessment criteria; it does not make unverified claims about a supplier’s credentials.

Internal testers, external testers and group teams

Internal testing is a controlled option, not a universal entitlement. DORA sets the conditions for authority approval, separation, resources and avoidance of conflicts. It requires external threat intelligence where internal testers are used and external testers for at least every third test. Significant credit institutions under the Single Supervisory Mechanism must use external testers.

RTS Article 15 adds requirements for internal-testing arrangements. Testers employed by an ICT intra-group service provider are treated as internal testers. The regulation also addresses disclosure of internal-tester use in the initiation information, red team report and summary report. A team does not become external merely because it sits in a different group company.

For planning, separate capacity from independence. A technically strong internal red team may still have conflicting responsibilities or be needed for essential defensive work. Document how the exercise will avoid weakening the entity’s ordinary security operations. Where internal and external testers are mixed, review the applicable internal-tester treatment rather than assuming the external members remove those requirements.

Sources: DORA Article 26, Article 27 and RTS Article 15.

Threat intelligence and the three scenario dimensions

Article 10 requires targeted intelligence after authority approval of the scope. Sector intelligence is an input, but the output must address the particular entity: its exposed information, relevant threat profiles, dependencies and plausible attack paths. A generic catalogue of current cyber threats is insufficient as the basis for a bespoke TLPT.

Annex III calls for at least three end-to-end threat scenarios for the relevant highest-severity threat profiles, covering availability, data integrity and information confidentiality. Each scenario can involve more than one security dimension. Those requirements do not authorise destructive demonstrations; risk controls govern how an objective is pursued and evidenced.

Ask of each scenario: why this threat actor or profile, why this function, why this path and what observation would make the result useful? Then trace the intelligence assumption into the red team test plan. If an assumption proves wrong during testing, record the change and the applicable approval instead of quietly substituting a convenient attack.

A practical traceability row can contain the intelligence reference, function, scenario, planned flag, allowed techniques, risk constraints, execution evidence and final outcome. Include a place to explain uncertainty. Intelligence may indicate that a path is plausible; it does not establish in advance that the target is vulnerable.

Threat-intelligence phase and Annex III: TLPT RTS Article 10.

Active testing, risk controls and leg-ups

Article 11 requires the red team test plan and the relevant approvals before active execution. Annex IV addresses communication, permitted and prohibited techniques, ethical boundaries for social engineering, risk measures and the other required plan elements. During active testing, progress reporting to the control team and test managers is at least weekly.

A leg-up is controlled assistance that enables the test to explore later stages when a scenario cannot otherwise progress as intended. It is not evidence that the earlier stage succeeded. If access is supplied to continue a scenario, the final narrative should distinguish that assistance from access actually gained through testing. This keeps the conclusions useful to management and defenders.

The control team must keep the operational-risk assessment current. Article 5 explicitly considers risks arising from both red-team and blue-team activity, incident escalation and incomplete restoration. A defensive reaction can be disruptive too. Agree how real incidents are separated from test events, which contacts can stop activity and how cleanup is evidenced.

Article 11 permits suspension under exceptional risk circumstances and, as a last resort with prior authority validation, continuation through limited purple teaming when continuation is otherwise impossible. That limited exercise counts toward the stated active-phase minimum. It is a governed exception, not a general basis for selling a workshop as twelve weeks of active testing.

Active testing, adaptation and exceptional measures: TLPT RTS Article 11.

Our TLPT methodology overview explains how governance and technical delivery fit together.

Third parties, pooled tests and joint tests

Outsourcing does not remove responsibility for the function. Where the scope involves an ICT provider, establish how that provider participates, how authority communication will work, which environments can be accessed and how impacts on other customers will be prevented. Resolve these matters before an execution schedule depends on them.

Pooled and joint TLPT arrangements need their own coordination. Articles 6 and 8 address risk management and procedural specificities, while Article 16 addresses cooperation between authorities. Each involved entity generally follows the defined steps unless the lead authority decides otherwise. Each financial entity’s control team conducts its own risk assessment; a common project plan does not erase entity-specific risks.

For a shared platform, a useful planning matrix maps each legal entity to its critical functions, supporting systems, provider contacts, jurisdictions, approval responsibilities and expected evidence. Highlight which findings are common and which conclusions can only be drawn for a specific entity. Prevent a group-wide report from making broader claims than the tested scope supports.

Sources: DORA Article 26 and RTS Article 16. Related guidance: third-party providers in TLPT.

The eight RTS annexes: your document map

Use the annexes as a content-control matrix, not as eight empty templates to populate at the end. Assign a document owner, reviewer, due-date trigger and approval status. Agree the secure storage location and document-handling rules before intelligence collection begins. Record versions so a change in scope can be followed through the test plan and reporting.

In particular, reconcile the flags and scenarios across the intelligence report, test plan, red team report and summary. Captured and non-captured objectives both matter. Preserve the difference between a control that resisted the tested action, an action not attempted for safety reasons and an action that failed because the prerequisite was absent.

Source: RTS Annexes I–VIII. Our deliverables overview and fictional sample DORA TLPT report show reporting context. A sample report is not a substitute for the complete authority submission pack.

Closure: red report, blue report, replay and purple teaming

Closure begins with the control team lead informing the blue team that a TLPT took place. The red team report supplies the offensive record. The blue team then explains the defensive view. The purpose is to reconcile two perspectives on the same activity, including gaps between available telemetry, actual detection and the decisions taken.

Replay and purple teaming should produce concrete learning. Select events where assumptions differed: a simulated action that generated no usable alert, an alert that lacked enough context for triage, or an escalation that reached the wrong owner. Explain which part of the chain needs changing. A finding titled “SOC did not detect the attack” is less actionable than a supported account of the missing event, correlation or response decision.

Distinguish the closure purple-teaming exercise from the exceptional limited purple teaming allowed during active testing. They have different roles in the RTS. Plan the required closure work at procurement, including access to the right defenders and sufficient time to reconcile timelines. Do not assume it is a discretionary extra after the red team leaves.

Keep sensitive details in the appropriate controlled records. Article 12 allows the relevant authority requests concerning sensitive information in reports. A management summary should communicate the consequence and required decisions without becoming an uncontrolled distribution channel for operational attack details.

Closure and reporting: TLPT RTS Article 12.

Further reading: TLPT reporting and remediation.

Remediation and attestation: evidence after the exercise

Article 13 requires the plan to address each finding: the shortcoming, proposed measures, priority and expected completion, root cause, responsible staff or functions, and risks of not implementing the measures or, where relevant, implementing them. Avoid converting a cross-cutting failure into a list of unrelated patches merely because patch tickets are easy to count.

Consider an illustrative identity-control weakness spanning several systems. The immediate action might restrict a permission, but the underlying cause could be an ownership gap in the access lifecycle. A useful plan records both, assigns the right owners and defines an observable completion condition. Otherwise, the same issue may reappear in a different system before the next TLPT.

Retesting and evidence review are practical ways to distinguish “change implemented” from “risk reduction demonstrated”. Link the acceptance evidence back to the original finding and agreed limitation. If an action cannot yet be completed, document the decision, compensating measures and remaining exposure through the entity’s governance process.

The attestation under DORA Article 26(7), RTS Article 14 and Annex VIII supports mutual recognition of the TLPT. It is issued through the authority process. A supplier cannot simply issue a generic “DORA-certified” badge to replace it. Nor does an attestation assert that the organisation has no vulnerabilities or has satisfied every part of DORA.

Remediation plan requirements: TLPT RTS Article 13.

Attestation requirements: TLPT RTS Article 14.

A practical 30-day preparation plan

The following is an internal mobilisation suggestion, not a new regulatory deadline and not a claim that TLPT can be completed in thirty days. Its purpose is to turn an obligation into a controlled procurement and preparation process before technical activity starts.

Budget for the full programme. Ask proposals to distinguish intelligence work, active testing, control-team support, third-party coordination, report production, replay, purple teaming and remediation support. There is no universal RTS price tariff. Pricing that looks attractive because it excludes mandatory work can create expensive scope changes later.

Use the DORA TLPT scoping brief builder to organise high-level information for a discussion. Avoid putting credentials, sensitive diagrams or customer data into an initial form. Attach an NDA or existing RFP through the contact flow before sharing detailed material.

Common RTS planning mistakes and how to avoid them

Before signing the statement of work, ask one final question: can every required output be traced to a named owner, an approval route and a date trigger? If the answer is no, the commercial scope is not yet specific enough to manage confidently.

DORA TLPT RTS: frequently asked questions

What is the DORA TLPT RTS?

It is Commission Delegated Regulation (EU) 2025/1190. It supplements DORA with rules for selecting entities for TLPT, organising and conducting tests, choosing providers, reporting, remediation, attestation and cooperation between authorities.

Is the DORA TLPT RTS final or still a draft?

The final regulation was published in the Official Journal on 18 June 2025 and entered into force on 8 July 2025. Use that adopted text rather than treating the earlier consultation or final draft as the binding instrument.

Does every DORA-regulated firm need a TLPT?

No. Advanced TLPT applies to financial entities identified under the relevant DORA and RTS selection process. DORA’s wider digital operational resilience testing obligations are separate. Confirm your status with the responsible authority.

Does the 12-week minimum cover the whole project?

No. RTS Article 11(5) specifies a minimum of 12 weeks for active red-team testing. Preparation, threat intelligence, reporting, replay, purple teaming and authority interactions require additional time.

When are the TLPT summary and remediation plan due?

Both have an eight-week deadline tied to the authority notification described in Article 12(7), concerning its assessment of the red and blue team reports. Do not automatically count those eight weeks from the end of active testing.

Can an ordinary penetration test replace DORA TLPT?

An ordinary penetration test is not automatically a DORA TLPT. The required authority involvement, scope, intelligence, testing process, closure evidence and other conditions must be met. A vendor’s naming convention does not establish regulatory recognition.

Can one supplier provide threat intelligence and red teaming?

The RTS contemplates providers within the same company, but the assigned threat-intelligence staff must be separated from, and not report to, the staff providing external testers for the same TLPT. Other independence and conflict requirements still apply.

Does a TLPT attestation mean the organisation is fully DORA compliant?

No. The authority attestation relates to the TLPT and supports mutual recognition. It is not a universal DORA compliance certificate, a clean bill of health or a guarantee that all weaknesses have been eliminated.

Plan a DORA TLPT engagement with Atlant Security

Atlant Security’s DORA TLPT service brings the discussion back to your critical functions, authority context, operational constraints and required evidence. Start with the legal entity, notification status, candidate functions, third-party dependencies and intended timeframe. Those details support a useful scoping conversation before a proposal is prepared.

Explore the TLPT DORA homepage, prepare a scoping brief, or send your RFP or NDA. If you want to examine the style of a technical deliverable first, request the sample DORA TLPT report; its download link is delivered by email.