DORA TLPT: Threat-Led Penetration Testing

No — TLPT is fundamentally different in four ways: (1) Intelligence-led — driven by real Targeted Threat Intelligence specific to your institution, not generic attack scenarios; (2) Live production scope — tests conducted on live systems, not test environments; (3) External mandatory — DORA requires accredited external Red Team and TI providers; internal teams cannot fulfil these roles; (4) Regulatory oversight — your competent authority is formally involved at every phase and issues a binding attestation. A standard penetration test has none of these characteristics and does not substitute for TLPT.

Your national competent authority (NCA) formally designates entities for TLPT and sends written notification. If you have not received this notification, you are not currently required. Key designation triggers include total assets above approximately €30 billion (for banks under SSM supervision), systemic importance classification (G-SII/O-SII), cross-border relevance, or SREP results indicating material ICT risk. Entities close to these thresholds should monitor their supervisory correspondence and can contact their NCA proactively. The designation list is updated periodically — being below-threshold today does not guarantee continued exemption.

No. DORA Article 26(2) explicitly requires the Red Team provider to be an external party, independent of the financial entity. This independence requirement prevents conflicts of interest and ensures the red team has no prior internal knowledge. The Threat Intelligence provider must also be independent from both the entity and the Red Team. However, internal security staff serve a critical supporting role as the "White Team" — coordinating test logistics, managing rules of engagement, and liaising with the competent authority. The Blue Team (SOC, defenders) must remain unaware that TLPT is underway until the purple team phase.

The White Team is a small, strictly compartmentalised internal group (typically CISO, legal counsel, senior IT risk officer, crisis management representative — maximum 3–5 people) who are aware TLPT is underway while the rest of the organisation remains unaware. The White Team manages rules of engagement and legal authorisations, defines abort/pause criteria, serves as the single point of contact with the competent authority during the test, and ensures the red team has necessary access without triggering real incident responses. Keeping the White Team minimal and compartmentalised is critical — any leak to the Blue Team invalidates detection measurement and may require scope adjustment or partial test replay.

The Rules of Engagement document (agreed before testing begins) defines abort and pause criteria, including discovery of critical zero-day vulnerabilities posing immediate risk to live operations or customer data. If the red team discovers such a vulnerability, the White Team can invoke an emergency pause: the vulnerability is immediately disclosed to the CISO, remediation begins, and the test resumes once the critical risk is mitigated. The TLPT RTS also requires contingency procedures for scenarios where red team activity inadvertently causes system instability. All such events must be documented and included in the final TLPT report submitted to the competent authority — they do not invalidate the TLPT, but they must be transparently disclosed.

DORA Article 26(5) explicitly states that a TIBER-EU test completed under the updated 2024+ framework before DORA's application date (17 January 2025) counts as the first TLPT cycle. The 3-year mandatory clock starts from that test's completion date. This means an institution that completed a TIBER-EU 2024 test in, say, October 2024 would not need to complete its first DORA TLPT until approximately October 2027 — well within the January 2028 deadline. Institutions that can credibly claim TIBER-EU credit should document this clearly in their regulatory correspondence with their NCA to avoid an unnecessary early-cycle TLPT obligation.

Yes — where third-party ICT providers host or operate systems supporting critical or important functions, those systems must be within TLPT scope. This includes CTPP-hosted cloud infrastructure supporting core banking, payment processing, or insurance platforms. The financial entity must have contractual audit and testing rights in place (required under DORA Article 30) enabling the red team to test third-party-hosted systems. CTPPs are expected to cooperate with TLPT exercises. For pooled TLPT under Article 26(5), multiple institutions sharing the same third-party infrastructure can conduct a joint exercise, dividing costs proportionately while satisfying all their individual TLPT obligations.

The attestation under Article 26(7) is substantive. Authorities verify: (1) scope compliance — all critical functions covered, exclusions justified; (2) provider independence and qualifications — TI and RT providers met requirements; (3) methodology compliance — test followed TLPT RTS framework, TTI report quality met standards; (4) findings completeness — all vulnerabilities documented with appropriate severity ratings; (5) remediation plan adequacy — each finding has an owner, priority level, and realistic timeline. Attestation may be conditional on critical finding remediation within a defined timeframe. Authorities who find significant methodology gaps may withhold attestation pending corrective measures — which may require supplementary testing.

Finding vulnerabilities in TLPT does not itself trigger fines — TLPT is designed to find and fix weaknesses. What can trigger enforcement: (1) failure to conduct TLPT when designated; (2) missing the January 2028 deadline; (3) materially inadequate scope; (4) failure to remediate critical findings within the timeframe agreed with the competent authority; (5) TLPT findings that reveal systematic ICT governance failures under DORA Articles 5–16. In the last scenario, the TLPT findings serve as evidence of broader compliance failures that existed before the test — the test itself is not the violation, but it is the evidence that supports enforcement.

Best practice — consistent with supervisory expectations — prioritises by a combination of exploitability (how easily a real attacker could use this finding), impact on critical functions (does exploitation affect payment processing, core banking, or customer data?), and detectability (would your current monitoring catch an exploitation attempt?). Critical findings — high exploitability, high impact, low detectability — should be remediated within 30–90 days. High findings within 90–180 days. Medium and low findings within the next cycle planning window. All remediation progress should be reported to the board quarterly and to the competent authority at the next SREP interaction. Failing to achieve remediation timelines agreed with the authority is itself a compliance risk.