DORA Article 26 TLPT: scope, cycle and SOC readiness

DORA, Regulation (EU) 2022/2554, splits digital operational resilience testing into two tiers. Every financial entity in scope runs a baseline testing programme under Articles 24 and 25. A smaller group must additionally run threat-led penetration testing, TLPT, under Article 26. The difference is not cosmetic. A TLPT is an intelligence-driven attack simulation against live production systems, executed covertly against the entity's defenders, with the regulator involved before, during and after.

Article 26 fixes the floor frequency: at least once every three years for each designated entity. The competent authority can adjust that cycle up or down based on the entity's risk profile. The scope must cover several or all critical or important functions, and the test must be performed on live production systems supporting those functions. Testing a staging environment does not satisfy the article.

The methodology question is settled in practice. Article 26(11) directed the European Supervisory Authorities to develop the technical standards in accordance with TIBER-EU, the ECB framework for threat intelligence-based ethical red teaming. Entities that already ran TIBER exercises will recognize the structure; entities new to it should treat TIBER-EU as the operating manual for DORA TLPT.

Not every bank, insurer or payment institution runs a TLPT. Article 26 applies to financial entities identified by their competent authorities based on impact, systemic character and ICT risk profile, with the identification criteria detailed in the regulatory technical standards. In plain terms: the authority designates you; you do not self-select in or out.

Designation follows criteria such as the entity's size and market footprint, the criticality of the services it provides, and its interconnection with the rest of the financial system. National authorities maintain the designated list per cycle and act as the TLPT authority for the exercise. In Spain, the TIBER-ES implementation is coordinated through Banco de Espana; other member states run equivalent national adoptions of TIBER-EU.

If you are not designated. Non-designated entities still owe the Article 24 baseline testing programme: vulnerability assessments, scenario-based tests, source code reviews where appropriate. Many supervised entities also run voluntary TIBER-style exercises to prepare for future designation. The readiness logic in this article applies to them equally.

Article 27 governs the testers. External testers must be of the highest suitability and reputability, technically and organisationally capable, certified or adhering to formal codes of conduct, covered by professional indemnity insurance, and independent from the entity's defenders. Internal testers are permitted only under additional conditions, including authority approval and the mandatory use of an external threat intelligence provider, and credit institutions classified as significant must use external testers.

Around the testers sits a fixed cast of roles, inherited from TIBER-EU:

The defenders, the SOC above all, are deliberately kept blind. That is the point of the exercise: the test measures what the SOC detects and how it responds when nobody warned it.

1. 1.Preparation: designation confirmed, white team formed, scope agreed with the authority, critical or important functions mapped to systems, rules of engagement and risk controls signed.
2. 2.Threat intelligence: the TI provider produces a targeting report with the actors most relevant to the entity and realistic attack scenarios based on their known TTPs.
3. 3.Red team execution: typically around twelve weeks of active testing against production, pursuing agreed flags such as access to payment systems or critical data stores.
4. 4.Closure and purple teaming: the red team and the blue team replay the attack path step by step, comparing what was done against what was detected, triaged and escalated.
5. 5.Reporting and remediation: findings, root causes and a remediation plan go to the authority, which issues an attestation confirming the test was performed per requirements.

The purple-teaming phase is the product. The attestation satisfies the regulator. The purple-teaming workshop is where the entity gets paid back: every undetected step in the kill chain converts directly into a detection engineering or response process backlog item. Entities that compress this phase to a slide deck waste most of the budget.

A TLPT tests the defenders, not the firewall. If the SOC cannot reliably detect, triage and escalate, the red team report reads as a long list of unobserved actions. That is an expensive way to document blindness. The finding first: a SOC needs working detection engineering, a rehearsed response process and a use of threat intelligence before a TLPT produces actionable signal.

The SOC-CMM gives you the vocabulary to check this in advance. The model, created by Rob van Os in 2016 and now at version 2.4, scores five domains and 27 aspects on a continuous 0 to 5 scale. Three aspect areas map directly onto TLPT survivability: detection engineering and use-case management (can you see the TTPs in the threat intelligence report at all), security incident response (do analysts escalate a real intrusion within agreed timelines), and threat intelligence (can you consume the TI report and convert it into hunting and detection content).

The 2026 sector data explains why this matters. Across assessed SOCs, domain averages sit at 2.7 for Technology, 2.5 for Business and around 2.2 to 2.3 for People, Process and Services, with MITRE ATT&CK technique coverage near 60 percent. Self-assessments overestimate maturity by roughly 0.6 points. An entity walking into a TLPT on the strength of its own scoring is, on average, half a maturity level less prepared than it believes. An independent SOC maturity assessment before the test corrects that picture and turns the TLPT from an exam you fail into an exercise you learn from.

• Twelve months out: run an independent SOC-CMM assessment scoped on detection, response and threat intelligence aspects; close the gaps that would make the test trivial for the red team.
• Six months out: validate ATT&CK coverage against the threat actors most likely to appear in the TI report; rehearse escalation paths with tabletop exercises.
• After the test: feed every purple-teaming finding into the detection backlog and re-score the affected aspects to evidence improvement to the board and the authority.

If you are designated, treat the three-year cycle as a programme, not an event: assess SOC maturity, remediate, test, purple-team, re-assess. If you are not designated, run the same loop voluntarily at lower intensity; designation criteria evolve and authorities can extend the list. In both cases the cheapest improvement per euro happens before the red team is hired, in the SOC, with an independent maturity baseline as the starting evidence.