DORA TLPT engagement playbook — from the authority notification to the attestation

Use this playbook when both of the following are true:

• Your entity is in scope of DORA — Regulation (EU) 2022/2554 and has been identified by its competent authority as required to perform threat-led penetration testing under Art. 26. Designation is not automatic with entity size: the authority applies the qualitative and quantitative criteria set out in Commission Delegated Regulation (EU) 2025/1190, taking account of the impact of the entity on the financial sector, its ICT risk profile and its systemic importance.
• You have received the formal notification from the TLPT authority that a TLPT shall be carried out. That notification is time zero for every deadline in this playbook.

The same sequence applies to voluntary tests run under a national framework — in Italy, TIBER-IT is the single methodological instrument for both mandatory DORA tests and voluntary ones — but only designated entities receive an authority-issued attestation.

Not in scope of this playbook: the routine digital operational resilience testing programme under DORA Art. 24 and Art. 25 (vulnerability assessments, network security assessments, source code reviews, scenario-based tests, ordinary penetration tests) — that runs continuously and is inspected separately; incident reporting duties on a live incident (see the DORA major ICT incident playbook); and national supervisory testing obligations that predate DORA, which continue to run in parallel rather than being absorbed by the TLPT.

Two anchors drive everything: T0, the authority notification, and E0, the agreed end of the active red team testing phase. Every deadline below is binding under RTS 2025/1190.

Preparation phase

• T0 + 3 months — TLPT initiation documents to the test managers (Art. 8(1)): project charter with high-level plan, control team lead contact details, declared intent to use internal or external testers or both, communication channels, and the TLPT code name.
• T0 + 6 months — scope specification document (Art. 8(5)), approved by the management body of the financial entity, not by the CISO alone.
• Before the testing phase can start: testers and threat intelligence provider contracted (Art. 8(8)), TLPT risk assessment consulted with the test managers (Art. 8(9)), and evidence of provider compliance filed (Art. 8(10)).

Testing phase

• Targeted threat intelligence report produced and approved by the authority (Art. 9(5)-(6)). In the European Supervisory Authorities final report on the RTS, this phase is described as typically lasting approximately four weeks.
• Red team test plan approved by the control team and the TLPT authority (Art. 10(3)).
• Active red team testing phase: at least 12 weeks (Art. 10(5)). Scenarios may run in sequence or concurrently. Its end date is agreed jointly by the control team, the threat intelligence provider, the testers and the test managers — that agreement is E0.

Closure phase

• E0 + 4 weeks — red team test report to the control team (Art. 11(2)).
• E0 + 10 weeks — blue team test report to the control team (Art. 11(4)), and the replay of offensive and defensive actions plus the purple teaming exercise (Art. 11(5)).
• N0 — the authority notifies the control team lead that both reports contain the required content.
• N0 + 8 weeks — the report summarising the relevant findings, the artefact DORA Art. 26(6) actually requires (Art. 11(7)).
• N0 + 8 weeks — the remediation plan (Art. 12(1)).
• Attestation issued by the TLPT authority under DORA Art. 26(7), confirming the test was carried out in accordance with the requirements.

Add it up honestly before you commit a date to the board: six months of preparation, roughly a month of threat intelligence, a minimum of three months of active testing, and four to five months of closure. Twelve to eighteen months is the realistic envelope, and the TLPT cadence itself is at least every three years — so the next engagement begins planning before the previous attestation has aged out.

This is the phase teams underestimate, and it is where the first missable deadline sits.

Stand up the control team. The control team supports the control team lead and owns, under Art. 8(3): communication channels with testers and threat intelligence providers, briefing the management body on progress and risk, subject-matter decisions throughout the test, compliance of the execution with the RTS, selection of the threat intelligence provider, selection of the testers, and preparation of the scope specification document. The authority validates the composition and every subsequent change to it.

Scope the critical or important functions. Art. 8(6) sets the criteria you must consider for inclusion: criticality of the function and its impact on the financial sector and on financial stability nationally and Union-wide, importance to day-to-day operations, exchangeability, interconnectedness with other functions, geographical location, sectoral dependence of other entities on the function, and available threat intelligence about it. Document the reasoning for each function you include and each one you exclude — the exclusions are what supervisors read first.

Procure against the RTS bars, not against a rate card. Art. 5(2) sets qualification floors that a cheap bid will not clear:

• Threat intelligence provider: at least three references from previous engagements; staff comprising at least a manager with 5+ years in threat intelligence and one further member with 2+ years; combined participation in at least three previous threat intelligence assignments in a testing context; no simultaneous blue team work for the entity; organisationally separated from the red team staff of the same provider.
• External testers: at least five references; a manager with 5+ years in penetration and red team testing plus at least two further testers with 2+ years each; combined participation in at least five previous assignments; not employed by, nor providing services to, a provider performing blue team tasks for the entity.
• Both: appropriate certifications to recognised market standards, and professional indemnity insurance covering misconduct and negligence.

If the authority assesses that your selected provider does not ensure compliance, you may not contract them (Art. 8(10)). Build a second-choice shortlist before you need it.

Preparation checklist

• Authority notification logged with its date, and the T0 + 3 and T0 + 6 dates entered in the programme plan.
• Control team appointed, lead named, authority validation received.
• Code name assigned; secrecy arrangements documented for entity staff, ICT third-party staff, testers and the threat intelligence provider.
• Scope specification document drafted, mapped to Annex II, tabled at the management body with a recorded decision.
• TLPT risk assessment produced, covering testing of live production systems and potential impact on the financial sector and on financial stability, and consulted with the test managers.
• Provider compliance evidence (references, certifications, insurance, CVs mapped to the Art. 5(2) thresholds) filed before contracting.
• Internal-tester policy in place if internal testers are used: test lead plus at least two members, all employed by the entity or an intra-group ICT provider for the preceding 12 months.

Threat intelligence comes first, and it drives the scenarios — not the other way round. The provider analyses generic and sector-specific intelligence, identifies threats and existing or potential vulnerabilities concerning your entity, and gathers concrete, actionable and contextualised target intelligence (Art. 9(1)). It then proposes scenarios that differ by threat actor and by associated tactics, techniques and procedures, and that target each and every critical or important function in scope (Art. 9(2)).

The selection rule is specific. The control team lead selects at least three scenarios (Art. 9(3)) weighing the provider recommendation and the threat-led nature of each scenario, the test manager input, the feasibility judgement of the testers, and the size, complexity and risk profile of the entity. No more than one selected scenario may be non-threat-led — a forward-looking, potentially fictive threat with predictive value given the anticipated threat landscape (Art. 9(4)). Three real adversaries and at most one hypothesis; a test built on four hypotheses is not a TLPT.

The red team test plan is a controlled document. Built from the scope specification and the targeted threat intelligence report, it must be consulted on with the control team, the threat intelligence provider and the test managers, covering communication, procedural and project management arrangements, the preparation and use-cases for leg-up activation, and reporting agreements (Art. 10(2)). It is then approved by the control team and by the TLPT authority. After approval, any change to timeline, scope, target systems or flags needs the control team lead and the test managers to sign off (Art. 10(6)).

Running the window

• Minimum 12 weeks of active red teaming, proportionate to scope and to the number of entities and providers involved.
• Testers report at least weekly to the control team and test managers; the threat intelligence provider stays available for additional intelligence on request (Art. 10(7)).
• Leg-ups — assistance or information provided by the control team to move a stalled scenario forward, typically information or access — are designed in advance in the test plan and provided in a timely way (Art. 10(8)). Improvised leg-ups negotiated mid-test are a governance finding, not a courtesy.
• If entity or provider staff detect the testing, the control team proposes measures to continue while preserving secrecy, for validation by the test managers (Art. 10(9)).
• Under exceptional circumstances risking data impact, asset damage or disruption to critical functions, counterparts or the sector, the control team lead may suspend the test — or, as a last resort and with prior authority validation, continue it as a limited purple teaming exercise. That time still counts toward the 12-week minimum (Art. 10(10)).

Testing-window checklist: targeted threat intelligence report mapped to Annex III and authority-approved; at least three scenarios selected with the selection rationale minuted; red team test plan mapped to Annex IV and approved; leg-up catalogue with activation criteria and deadlines; weekly progress reports retained; every change request to the plan recorded with approver and timestamp; detection events logged with the continuation measure and its validation.

Closure is where the engagement is graded, and its deadlines run in parallel rather than in series — plan the calendar backwards from E0.

Immediately after E0: the control team lead informs the blue team that a TLPT took place (Art. 11(1)). Until that moment the blue team has been responding to what it believed was a real intrusion; the debrief you owe them is operational, not ceremonial.

E0 + 4 weeks — red team test report (Art. 11(2), content per Annex V), provided without undue delay to the blue team and the test managers. At test manager request it is produced without sensitive information.

E0 + 10 weeks — blue team test report (Art. 11(4), Annex VI): what was detected, when, through which control, what was escalated and what was missed. This is the document that decides whether your detection story survives contact with evidence.

E0 + 10 weeks — replay and purple teaming (Art. 11(5)): the blue team and the testers replay the offensive and defensive actions together, and the control team runs a purple teaming exercise on topics jointly identified — vulnerabilities found during the test, and issues that could not be tested during the active phase. Purple teaming in closure is mandatory under the RTS, not optional as it was under earlier framework versions. Afterwards the control team, blue team, testers and threat intelligence provider give each other structured feedback on the process (Art. 11(6)).

N0 + 8 weeks — the summary report (Art. 11(7), Annex VII), submitted once the authority has confirmed both team reports contain the required content. This is the artefact DORA Art. 26(6) names.

N0 + 8 weeks — the remediation plan (Art. 12), to the TLPT authority and, where different, to the competent authority. Per finding it must carry: a description of the shortcoming; the proposed remediation measures with prioritisation and expected completion, including measures to improve identification, protection, detection and response capabilities; a root cause analysis; the named staff or function responsible for implementation; and the risks of not implementing the measures, plus any risks created by implementing them.

The attestation is then issued by the TLPT authority under DORA Art. 26(7), confirming the test was performed in accordance with the requirements. It is the artefact your auditors, your insurers and your counterparties will ask to see — and the only one you cannot produce yourself.

Assemble these as the engagement runs, signed and timestamped at the moment of creation. Ordered by the gate that consumes them.

Consumed at the T0 + 3 gate: authority notification with received date; project charter mapped to Annex I; control team roster with roles, and the authority validation of it; declared internal or external tester intent; communication channel inventory; code name register.

Consumed at the T0 + 6 gate: scope specification document mapped to Annex II; the function-by-function inclusion and exclusion rationale against the Art. 8(6) criteria; management body minutes recording approval; TLPT risk assessment and risk management measures with the test manager consultation record.

Consumed before the testing phase: provider due-diligence pack — references, certifications, indemnity insurance policies, and named-staff CVs mapped line by line to the Art. 5(2) experience thresholds; internal-tester policy and the 12-month employment evidence where applicable; contracts with the secrecy arrangements.

Consumed during the testing phase: authority approval of the targeted threat intelligence report; scenario selection rationale; approved red team test plan and every subsequent change with approver and timestamp; weekly progress reports; leg-up log recording what was granted, when and why; detection-event log with the continuation measures and their validation; suspension record if Art. 10(10) was invoked.

Consumed at closure: red team test report; blue team test report; replay and purple teaming records including the topic list; process feedback records; summary report; remediation plan with named owners and root causes; and finally the authority attestation.

Consumed continuously, between engagements: the evidence that findings were actually closed. The remediation plan states expected completion dates; the next supervisory interaction asks what happened on those dates, and the next TLPT begins from whatever posture you actually reached. This is where the engagement quietly fails for most entities — not at a gate, but in the eighteen months of silence afterwards, because the closure evidence lives in ticket exports whose provenance nobody can prove. The position the Zero Hunt team takes here is the AI Generative Pentest rail run continuously between the three-year exercises: a ten-agent swarm chaining reconnaissance, exploitation, credential attack, post-exploitation and pivoting against production targets, each generated chain backtested in the AI Gym before it runs, and every finding and retest ECDSA-signed at write time. The signed retest for a TLPT finding becomes a first-class artefact rather than a screenshot in a slide, and the next targeted threat intelligence report starts from a measured posture instead of a hopeful one.

1. Treating the 12 weeks as the project. The binding constraints are the three-month initiation gate and the six-month scope gate, both of which land before any testing. Entities that start programme planning when the red team is procured have already missed two deadlines.

2. Procuring on price and failing Art. 5(2). The reference counts, the years of experience per named individual, the certifications and the indemnity insurance are hard floors, and the authority can refuse your contracting decision. Verify against the thresholds during the tender, not after signature.

3. A scope specification the management body rubber-stamps. Art. 8(5) requires management body approval precisely so the scope decision is owned at board level. Supervisors read the minutes, and a five-minute agenda item on a document that excluded three critical functions is a governance finding on its own.

4. No measured detection baseline going in. The blue team test report at E0 + 10 weeks is where *we would have caught that* meets the timeline of what was actually detected. If the only prior evidence of detection capability is an annual exercise, the report writes itself against you — and the remediation plan then commits you to improvements you cannot demonstrate before the next test.

5. A remediation plan that is a list of tickets. Art. 12(2) demands root cause analysis, prioritisation with expected completion, named responsible staff or functions, and the risks of not acting. A Jira export satisfies none of those four.

6. Using internal testers on a third consecutive test. DORA Art. 26(8) requires external testers every three tests, and the RTS is explicit that a team mixing internal and external testers counts as internal for that purpose. Track the count across the whole three-year cycle, not per business unit.

7. Letting the attestation become the end state. The attestation confirms the test was run properly. It says nothing about whether the findings were closed, and it ages: the ECB supervisory priorities for 2026-2028 place threat-led penetration testing inside a continuous supervisory programme alongside on-site inspections, not as a triennial box to tick.

The methodology is TIBER-EU. The ECB TIBER-EU framework and its 2025 guidance set — service provider procurement, control team, purple teaming, scope specification, targeted threat intelligence, red team test plan and report, blue team report, remediation plan, test summary report and attestation guidance — is the operating manual behind the RTS articles. Read them together: the RTS says what is due when; TIBER-EU says what the document should contain.

In Italy, the instrument is TIBER-IT. Banca d’Italia, Consob and IVASS jointly published version 2.0 of the national TIBER-IT guide in November 2025, announced by joint communication on 11 December 2025, incorporating the DORA TLPT provisions. It is the single methodological instrument for Italian financial entities, covering both mandatory DORA tests and voluntary tests by entities not designated.

Cross-border entities. Where the entity provides services in more than one Member State, its TLPT authority determines which host authorities to involve, based on whether critical or important functions are operated in or shared across those states (Art. 14(1)). Host authorities then have 20 working days to express interest in observing or to assign a test manager. Unless otherwise agreed, the home authority leads and shares the scope specification document, the summary report, the remediation plan and the attestation with the observers. Practical consequence: your control team may be coordinating with several authorities on one calendar, and the lead authority may cap participation to keep the test workable.

Pooled and joint TLPTs. A pooled TLPT under DORA Art. 26(4) lets several entities sharing an ICT third-party provider test together where separate tests would adversely affect service quality or security. For a pooled test, at least one scenario must include the third-party provider underlying ICT systems, processes and technologies that support the in-scope functions. A joint TLPT is the related case of entities using common ICT systems or a shared intra-group provider, again with at least one scenario reaching the intra-group provider. In both cases each participating entity keeps its own control team and its own risk management, and scenarios must not degrade any participant service.

What this does not replace. TLPT sits on top of the Art. 24 and Art. 25 testing programme, it does not substitute for it — the point Frank Elderson made at the Goldman Sachs European Financials Conference on 3 June 2026, warning that AI-driven offensive tooling can discover and exploit vulnerabilities at a speed and scale beyond what defenders have previously faced, and that the time available to defenders is shrinking. A three-year cadence answers a supervisory question; it does not answer an operational one. The relationship between the triennial exercise and continuous validation is covered in the TLPT definition and in CTEM.