EU DORA TLPT Runbook

Open the runbook when the TLPT authority notifies the financial entity that a TLPT is to be carried out, or when internal planning confirms that a required TLPT cycle is approaching. 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 control team lead, the control team, the TLPT 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.

The scope section should list all critical or important functions considered for TLPT, 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 flags tied to confidentiality, integrity, authenticity, or availability.

DORA requires each TLPT 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.

Use the provider-control section to prove that the threat intelligence provider and testers meet DORA and TLPT RTS requirements before contracting or assigning them. The TLPT RTS expects an external threat intelligence provider, and it sets detailed evidence expectations 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 red team test plan. The threat intelligence provider must produce concrete, actionable, contextualised target and threat intelligence. The control team 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.

The closure section should not stop at the red team report. After active red-team testing ends, the control team informs the blue team, 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 purple teaming on jointly identified topics based on vulnerabilities found during testing and, where relevant, topics not fully tested during the active phase.

After the TLPT authority has assessed the blue team and red team reports, the financial entity submits the summary report of relevant findings for approval, then provides the remediation plans and documentation required under DORA. The remediation plan should track each finding to the shortcoming, remediation measure, priority and expected completion, root cause, responsible staff or function, and risks of not implementing the measure. Keep the attestation and notify the relevant competent authority of the attestation, summary findings, and remediation plans.