Artifact GuideEU DORA

EU DORA TLPT Runbook

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.

Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
Overview

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.

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.
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.
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.
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.
Primary sources

References and citations

eur-lex.europa.eu5 citations
Referenced sections
  • 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"
"Content of the red team test report"
eur-lex.europa.eu5 citations
Referenced sections
  • 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"
"summary of the relevant findings"
ecb.europa.eu2 citations
Referenced sections
  • 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"
Show all related guides (33)

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

Map DORA register fields to official templates for ICT contracts, provider chains, 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 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

Test DORA applicability against official sources for financial-entity scope, ICT services, critical or important functions, exclusions, proportionality, and evidence.

EU DORA Compliance Checklist for Financial Entities

Check DORA operating evidence against official sources for ICT risk governance, major-incident reporting, resilience testing, TLPT, third-party contracts, and the register of information.

EU DORA Compliance Obligations and Evidence Guide

Map DORA obligations to official sources and operating evidence for ICT risk management, incident reporting, testing, third-party risk, registers, governance, and oversight.

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.

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.

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 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 TLPT selection: who can be required to test?

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.

How does proportionality work under EU DORA?

DORA proportionality explained from official sources: what can be scaled, simplified-framework eligibility, supporting evidence, and duties that remain mandatory.