TLPT under DORA: Spain's first testing cycle

DORA · September 2026 · 7 min read

By Arturo Navarro · 19 September 2026

Article 26 of DORA (Regulation (EU) 2022/2554) requires certain financial entities to carry out at least every 3 years advanced testing by means of TLPT, threat-led penetration testing. The operational detail is set by Delegated Regulation (EU) 2025/1190, of 13 February 2025, published in the Official Journal on 18 June 2025. For a Spanish entity working on DORA compliance, the practical consequence is uncomfortable: the first cycle is not opened by the entity, it is opened by a notification from the authority, and from that point the deadlines belong to the regulation.

What a TLPT is and who decides an entity must run one

A TLPT is not a conventional penetration test. Article 26(2) requires each test to cover "several or all critical or important functions" of the entity and to be performed "on live production systems supporting such functions": there is no staging environment in which to get it wrong. The entity assesses which functions fall within scope, and that assessment is validated by the competent authorities.

Nor is the obligation self-service. Article 26(8), third subparagraph, assigns competent authorities the task of identifying which entities must run a TLPT, on three blocks of criteria: the impact of their services on the financial sector, possible financial stability concerns, and the specific ICT risk profile, level of ICT maturity or technology features involved. Article 26(9) leaves governance to each Member State, which "may designate a single public authority in the financial sector" for these matters; absent a designation, Article 26(10) allows a competent authority to delegate some or all of those tasks to another national authority in the financial sector. The Delegated Regulation defines the TLPT authority as any of the following: the single authority designated under Article 26(9), the authority to which some or all of the tasks are delegated under Article 26(10), or any of the competent authorities referred to in Article 46 of DORA (Article 1(7)).

In Spain two planes are often conflated. The framework that already exists is TIBER-ES: the Banco de España is the authority that owns the local framework, in close cooperation with the CNMV and the DGSFP, and its own page describes those tests as voluntary. DORA's TLPT is the obligation, and it applies only to identified entities. Methodology is what links them: Article 26(11) mandated regulatory technical standards "in accordance with the TIBER-EU framework", which the ECB published in May 2018 and updated in 2024 to align it with them.

The authority running the test is not always the usual supervisor

Recital 1 of Delegated Regulation (EU) 2025/1190 states that a national designation is "without prejudice" to competences entrusted at Union level, and names the European Central Bank for significant credit institutions. It adds that, where only some tasks are delegated to another national authority (Article 26(10)), the competent authority under Article 46 keeps the tasks not delegated.

Who the standard identifies, and at what thresholds

Article 2(1) of the Delegated Regulation requires TLPT authorities to weigh size, interconnectedness, criticality and substitutability of services, business model complexity, and a block of ICT risk factors that includes the maturity of detection and mitigation. Article 2(2) adds a list of entities that will be required to test unless that assessment says otherwise:

Type of entity	Threshold in Article 2(2)
Credit institutions	Being a G-SII or an O-SII, or part of one (Art. 2(2)).
Payment institutions	Payment transactions above EUR 150 billion in each of the two calendar years preceding the TLPT authority's assessment (Art. 2(2)).
Electronic money institutions	The same payments threshold, or more than EUR 40 billion of outstanding electronic money, in each of the two calendar years preceding the TLPT authority's assessment (Art. 2(2)).
Central securities depositories and central counterparties	No quantitative threshold: they qualify by type (Art. 2(2)).
Electronic trading venues	Highest national market share by turnover, or a Union-level share above 5%, in both cases in each of the two calendar years preceding the TLPT authority's assessment (Art. 2(2)).
Insurance and reinsurance	Gross written premium above EUR 1.5 billion, technical provisions above EUR 10 billion and, for life or composite insurers, total assets above 3.5% of the national market (Art. 2(2)).

The table reads in both directions. On the life or composite insurers that meet all three criteria, Article 2(2) applies a second filter of higher thresholds: clearing the first screen does not create the obligation. Conversely, an entity above a threshold may fall outside it if the authority's overall assessment does not justify the test, and another type may fall inside on qualitative criteria (recital 3 names crypto-asset service providers).

The calendar the first cycle imposes

What surprises entities is not the technical requirements but the deadlines, measured from three different starting points (the initial notification, the end of the active phase and the authority's assessment of the reports), plus the minimum duration of the active phase itself:

Milestone	Deadline
Test initiation information after the notification	3 months (Article 9(2))
Active red team testing phase	Minimum 12 weeks (Article 11(5))
Red team test report after the active phase ends	4 weeks (Article 12(2))
Blue team report and joint replay of the actions	Maximum 10 weeks (Articles 12(4) and 12(5))
Summary report to the authority	8 weeks from the authority's notification that it has assessed the red and blue team reports (Article 12(7))
Remediation plans and documentation	8 weeks from that same notification (Article 13(1))

Added up, a cycle approaches a calendar year, before any preparation. The active phase admits no shortcuts: if, as a last resort and subject to prior validation by the TLPT authority, the test continues as a limited purple teaming exercise instead of being suspended, the duration of that exercise counts towards the 12-week minimum (Article 11(10)). The remediation plan is not a task list either: Article 13(2) requires, per finding, the shortcoming, the prioritized measures, the root cause analysis, the owner and the risks of not implementing them.

Who may run the test

Article 27(1) sets five cumulative requirements for testers: suitability and reputability, demonstrated capabilities in threat intelligence, penetration testing and red team testing, independent assurance or an audit report, professional indemnity insurance and, on the point most often misquoted, being "certified by an accreditation body in a Member State or" adhering to formal codes of conduct or ethical frameworks: formal accreditation is one of two routes, not the only one.

The Delegated Regulation makes selection concrete: the threat intelligence provider supplies at least three references from previous assignments and external testers at least five (Article 7(1)). With internal testers, DORA requires contracting external testers every three tests, the threat intelligence provider must always be external, and significant credit institutions may only use external testers.

What architecture survives a test on production

This is where a TLPT stops being compliance and becomes architecture. The test runs on live systems, and recital 11 lists the risks plainly: denial-of-service incidents, unexpected system crashes, damage to critical live production systems and loss, modification or disclosure of data. Four properties separate the entities that measure themselves from those that discover themselves.

A bounded blast radius. If lateral movement from one compromised machine reaches the transactional core, the finding is not a vulnerability: it is the architecture.
Traceable internal traffic. Without east-west visibility there is no way to reconstruct the attack chain in the joint replay of Article 12(5).
Identity before network. Scenarios target people, processes and technology at once, not a perimeter.
Inventoried third-party dependencies. Article 26(2) reaches the systems supporting outsourced functions, and that inventory feeds the ICT third-party register of information.

One point deserves emphasis in point (b) of Article 2(1) (point (viii)): the maturity of detection and mitigation is at once a criterion for identifying the entity and subject matter of the test. Defensive capability is part of why the notification arrives.

Zero Trust as structural preparation

A TLPT cycle rewards decisions taken years earlier. Least-privilege access by identity, microsegmentation and verifiable authorization are not added during the active phase: they determine whether a scenario reaches the flags. That is the argument of Zero Trust applied to banking, developed in Zero Trust in banking, and the one behind governing AI agents with their own identity.

The test is prepared with architecture, not documentation

The summary report and the remediation plan are deliverables. The outcome is decided by three things: whether critical functions are isolated, whether every access is authorized by identity, and whether internal traffic leaves a trail.

Common mistakes before the first cycle

Mistaking TIBER-ES for the obligation. The Banco de España framework is voluntary; the obligation comes from Article 26 of DORA.
Planning from the annual pentest. A penetration test covers isolated systems; a TLPT simulates an adversary against the whole entity, with directed intelligence.
Leaving scope until last. The authority validates which critical functions are in scope, and the whole calendar hangs from that.
Underestimating the control team. Article 4 requires a lead responsible for the day-to-day management of the test and need-to-know access to information; recital 10 adds that the control team should be as small as possible.

Conclusion: a TLPT measures the architecture, not the report

DORA turned intelligence-led red teaming into a recurring obligation with an authority, a calendar and fixed deliverables. The cycle runs close to a year, executes on production and ends in a remediation plan with root cause analysis. Useful preparation is not accumulating documentation: it is reducing the blast radius, making internal traffic traceable and authorizing by identity before the notification arrives.

If your entity is assessing whether TLPT applies or how to prepare, at BlueUP we work DORA operational resilience as architecture, not paperwork. Start by measuring your maturity with the DORA Calculator, review the frame in the practical DORA guide, or let's talk about your case.

DORA for fintech and insurtech: a practical guide and 90-day checklist — The testing pillar inside a 90-day plan.
DORA Register of Information: why almost no one passes first time — The third-party inventory that feeds the scope.
Anatomy of a DORA incident: from first signal to notification — When the adversary is not simulated.

TLPT under DORA: Spain's first testing cycle ​

What a TLPT is and who decides an entity must run one ​

Who the standard identifies, and at what thresholds ​

The calendar the first cycle imposes ​

Who may run the test ​

What architecture survives a test on production ​

Zero Trust as structural preparation ​

Common mistakes before the first cycle ​

Conclusion: a TLPT measures the architecture, not the report ​

Related reading ​