A cited runbook structure for financial entities that must perform DORA threat-led penetration testing.
Use it to organise authority touchpoints, critical-function scoping, tester and threat-intelligence controls, active red-team testing, closure reports, remediation evidence, and attestation records.
DORA has applied since 17 January 2025. DORA is an authority-coordinated test of live production systems supporting several or all critical or important functions. Under Article 26, identified financial entities must control the scope and risks, document results, prepare remediation plans, and obtain an authority attestation. This runbook organises those requirements without adding test steps beyond DORA and Delegated Regulation (EU) 2025/1190.
1
Section 1
1. Start from the authority trigger and TLPT governance
Use the runbook before notification to maintain readiness, but treat the authority's notification as the start of the formal test and its regulatory deadlines. DORA sets a baseline TLPT cadence of at least every 3 years for identified financial entities, with competent authorities able to adjust the frequency based on risk profile and operational circumstances.
The runbook should name the lead, the control team, the authority contact path, the test manager or managers when known, the management-body approval points, and the code name used to restrict knowledge of the test. Keep the test on a need-to-know basis: the TLPT RTS requires information about planned or ongoing testing to be limited to the control team, management body, testers, threat intelligence provider, and TLPT authority.
DORA and Delegated Regulation 2025/1190 are binding. The ECB's TIBER-EU framework is official implementation guidance aligned with the DORA standard, but financial entities still need to satisfy the formal scope, authority-validation, reporting, remediation, and attestation requirements.
Runbook opening record: authority notification date, assigned internal lead, authority contact, code name, intended communication channels, and internal confidentiality rules.
Governance record: management-body approval of the scope specification, control-team reporting to the management body on progress and associated risks, internal approval records for the project charter and remediation commitments where the entity's governance requires them, and any case-specific management-body approval of risk management measures.
Cadence record: previous completion or attestation, next planned TLPT window, and any authority instruction to reduce or increase the 3-year baseline cadence.
Escalation record: who can pause testing, who can approve changes to scope or timing, and how the will contain accidental detection by staff or service providers.
Article 9 of the TLPT RTS sets initiation information, control-team setup, scope documentation, provider selection, and authority validation steps.
A financial entity shall, within 3 months
2
Section 2
2. Define and validate the TLPT scope
The scope section should list all critical or important functions considered for , not only the functions selected for testing. For each function, record whether it is included, why it is included or excluded, the supporting ICT systems, outsourced or contracted ICT services, relevant jurisdictions, and preliminary tied to confidentiality, integrity, authenticity, or availability.
DORA requires each to cover several or all critical or important functions and to be performed on live production systems supporting them. The precise scope is determined by the financial entity's assessment and validated by the competent authority or TLPT authority. Where ICT third-party providers support in-scope functions, the runbook should show how their participation is covered, including whether pooled TLPT is being considered where direct provider participation could affect other customers or confidentiality.
Function inventory: critical or important function, business owner, supporting ICT systems, geographic location, service dependencies, and whether a third-party or intra-group provider supports it.
Inclusion criteria: criticality to day-to-day operations, impact on the financial sector or financial stability, exchangeability, interconnectedness, geographical location, sector dependence, and available threat intelligence.
Exclusion rationale: document why any critical or important function is outside this scope and whether it remains covered by another resilience test or future TLPT.
Scope validation package: scope specification document, management-body approval, authority approval, provider briefing record after contracting, and any approved changes to target systems, , scope, or timing.
Article 26 requires TLPT to cover several or all critical or important functions and requires the resulting scope to be validated by competent authorities.
cover several or all critical or important functions
Annex II specifies the scope specification content for critical or important functions, supporting ICT systems, outsourcing, jurisdictions, and flags.
Content of the scope specification document
3
Section 3
3. Control threat intelligence providers, testers, and red-team execution
Use the provider-control section to prove that the threat intelligence provider and testers meet DORA and RTS requirements before contracting or assigning them. The TLPT RTS requires an external threat intelligence provider, and it sets detailed evidence requirements for skills, references, certifications, insurance, independence, conflicts of interest, secure restoration, and prohibited conduct.
The testing section should keep three records together: the targeted threat intelligence report, the scenario-selection record, and the test plan. The threat intelligence provider must produce concrete, actionable, contextualised target and threat intelligence. The lead selects at least three scenarios using the provider's recommendation, test-manager input, tester feasibility judgement, and the entity's size, complexity, and risk profile. No more than one selected scenario may be non-threat-led.
Provider evidence: CVs, certifications, professional indemnity insurance, required references, conflicts check, separation between threat intelligence and tester staff where relevant, and authority evidence package before contracting.
Threat intelligence report fields: scope, geography, relevant ICT third-party providers, research period, actionable target intelligence, threat profiles, and at least three end-to-end threat scenarios covering availability, data integrity, and information confidentiality themes.
test plan fields: communication channels, allowed and prohibited tactics, ethical boundaries for social engineering, risk controls, target functions and systems, , expected attack paths, leg-up rules, schedule, and infrastructure constraints.
Active testing controls: an active testing phase of at least 12 weeks, scaled to the scope and parties involved; at least weekly progress reporting to the and test managers; threat intelligence provider availability for consultation; approved ; approved changes to the red team test plan; and suspension criteria for exceptional impact risks. A limited purple-team continuation approved under the exceptional-risk rule counts toward the 12-week minimum.
Articles 7, 10, and 11 set provider evidence, threat intelligence report, scenario selection, red team test plan, weekly reporting, leg-up, and active testing requirements.
Article 27 sets baseline tester suitability, capability, certification or ethical-framework, assurance, and insurance requirements for TLPT.
Requirements for testers for the carrying out of TLPT
4
Section 4
4. Close with reports, remediation, attestation, and evidence retention
The closure section should not stop at the report. After active red-team testing ends, the informs the , testers submit the red team test report, the blue team submits its report, and the parties replay offensive and defensive actions. The control team also runs on jointly identified topics based on vulnerabilities found during testing and, where relevant, topics not fully tested during the active phase.
The testers submit the report within four weeks after active testing ends. The report, replay, and are due no later than ten weeks after active testing ends. Once the authority confirms that it has assessed the red and blue team reports, the financial entity has eight weeks to submit the summary report for approval and eight weeks from the same notification to provide the remediation plan and supporting documentation.
The remediation plan must track each finding to the shortcoming, remediation measure, priority and expected completion, root cause, responsible staff or function, and risks of not implementing and, where relevant, implementing the measure. Keep the attestation and notify the relevant competent authority of the attestation, summary findings, and remediation plans.
Closure evidence: test report, test report, replay record, topics, feedback record, summary report of relevant findings, remediation plan, documentation showing requirements were followed, and attestation.
report evidence: functions and ICT systems targeted, scenario summaries, reached and not reached, successful and unsuccessful attack paths, tactics used, deviations, , discovered vulnerabilities, root causes, and remediation recommendations.
report evidence: detected attack actions, corresponding log entries, evidence collected by the blue team, blue-team root cause analysis, lessons learned, improvement opportunities, and topics for .
Remediation tracker: finding, shortcoming, root cause, proposed remediation measure, priority, expected completion, responsible staff or function, and risks associated with not implementing and, where relevant, implementing the measure.
Official ECB guidance explains that the updated TIBER-EU framework is aligned with the DORA TLPT regulatory technical standards and provides detailed guidance for controlled DORA TLPT.
updated its European framework for threat intelligence-based ethical red-teaming
Recommended next step
This runbook helps organise a cited TLPT record
Use the cited sources listed here to verify obligations and the supporting evidence requirements.
Regulatory technical standards for TLPT selection criteria, internal tester controls, scope, methodology, threat intelligence, red team testing, closure, remediation, cooperation, and mutual recognition.
Article 9 of the TLPT RTS sets initiation information, control-team setup, scope documentation, provider selection, and authority validation steps.
Annex II specifies the scope specification content for critical or important functions, supporting ICT systems, outsourcing, jurisdictions, and flags.
Show 2 more
Articles 7, 10, and 11 set provider evidence, threat intelligence report, scenario selection, red team test plan, weekly reporting, leg-up, and active testing requirements.
Articles 12 to 14 and Annexes V to VIII define closure reports, replay and purple teaming, remediation-plan content, and attestation content.
"requirements in relation to the scope, testing methodology and approach"
More quoted passages
"A financial entity shall, within 3 months"
"Content of the scope specification document"
"The duration of the active red team testing phase"
Primary DORA source for Article 26 TLPT cadence, live-production scope, authority validation, provider use, reports, remediation plans, and attestation.
Article 26 establishes the TLPT cadence, live-production testing expectation, scope validation, risk controls, reporting, remediation, and attestation obligations.
Article 26 requires TLPT to cover several or all critical or important functions and requires the resulting scope to be validated by competent authorities.
Show 2 more
Article 27 sets baseline tester suitability, capability, certification or ethical-framework, assurance, and insurance requirements for TLPT.
Article 26 requires relevant findings, remediation plans, supporting documentation, authority attestation, and competent-authority notification after TLPT.
"Advanced testing of ICT tools, systems and processes based on TLPT"
More quoted passages
"at least every 3 years"
"cover several or all critical or important functions"
"Requirements for testers for the carrying out of TLPT"
Official ECB guidance on the alignment of the updated TIBER-EU framework with the DORA TLPT regulatory technical standards.
Official ECB guidance explains that the updated TIBER-EU framework is aligned with the DORA TLPT regulatory technical standards and provides detailed guidance for controlled DORA TLPT.
"updated its European framework for threat intelligence-based ethical red-teaming"