DORA TLPT vs a standard penetration test

DORA asks almost every in-scope financial entity to test its digital operational resilience. It asks only a small subset, named by their authority, to undergo threat-led penetration testing. Two separate obligations, with different triggers and different mechanics — and conflating them is the most expensive mistake we see in procurement.

Two different obligations

Regulation (EU) 2022/2554 — the Digital Operational Resilience Act, applicable from 17 January 2025 — devotes Chapter IV to digital operational resilience testing. That chapter contains two distinct duties.

The first is general and nearly universal. Article 24 requires financial entities other than microenterprises to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as an integral part of their ICT risk-management framework. There is no designation step and nothing to wait for.

The second is narrow and conditional. Article 26 requires advanced testing by means of threat-led penetration testing — TLPT — but only from entities "which are identified in accordance with paragraph 8, third subparagraph". That subparagraph puts identification in the hands of competent authorities. Entities under the simplified ICT risk-management framework of Article 16(1), and microenterprises, are excluded outright.

So: the general programme is something you build because DORA applies to you; TLPT is something you perform because an authority has told you that you must. Most in-scope entities will spend their entire DORA lifecycle in the first category. A small population — systemically significant banks, the largest payment and e-money institutions, market infrastructure, the largest insurers — sits in the second. Only one of the two is a red team.

What the general testing obligation asks for

Article 24 is a programme requirement, not a test requirement, and asks four things of you.

• A risk-based programme, sitting inside the ICT risk-management framework and accounting for the evolving risk landscape, the entity's exposures and the criticality of its assets and services. Article 4(2) ties Chapter IV to size, risk profile and the complexity of operations.
• Independence of testers. Article 24(4) requires tests to be undertaken by independent parties, internal or external. Internal testing is permitted, but with sufficient dedicated resources and no conflicts of interest across design and execution. "Independent" does not mean "external" — it is a structural property you must evidence.
• Remediation with validation. Article 24(5) requires procedures to prioritise, classify and remedy all issues revealed by testing, plus internal validation methodologies confirming every weakness, deficiency or gap is fully addressed. Findings without a closed validation loop do not discharge it.
• At least yearly coverage. Article 24(6) requires entities to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions. Note the phrasing: appropriate tests, not one; all supporting systems, not a sample.

Article 25 supplies the toolbox: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario-based tests, end-to-end testing and penetration testing.

Where an ordinary penetration test fits. Penetration testing is one named instrument in that list, and for most entities the most informative. A well-scoped application, infrastructure, cloud or identity-platform test produces evidence of exploitability on a defined attack surface, severity-ranked findings for the Article 24(5) prioritisation process, and retest evidence for validation. What it is not is a substitute for TLPT. A standard test is scoped from an asset inventory, usually announced, run with the defenders' knowledge and measured against a target list — not deficiencies, but exactly the properties Article 26 removes.

What makes a test "threat-led"

Article 26 and its regulatory technical standards — Commission Delegated Regulation (EU) 2025/1190, published in the Official Journal on 18 June 2025 — define TLPT by structural properties rather than by technique. Four do most of the work.

• Intelligence-led scenario design. Scenarios are not chosen from a catalogue. An external threat intelligence provider builds a threat profile for the entity, identifying plausible threat actors and their tactics, techniques and procedures. Under the RTS the control team then selects at least three scenarios from that report, differentiated by actor and TTPs, each targeting a critical or important function in scope; at most one may be forward-looking rather than threat-led.
• Execution against live production. Article 26(2) is unambiguous: each test must cover several or all of the entity's critical or important functions and be performed on live production systems supporting them, including systems behind outsourced functions. The entity assesses which functions need covering, and the competent authorities validate the resulting scope.
• Oversight by a control team, and by the authority. The entity appoints a control team with a named lead who runs the test, keeps knowledge of it strictly need-to-know, selects the providers, and owns the management-body-approved scope document. Separately, the TLPT authority runs a cyber team of test managers which participates in all phases, validates the key artefacts, and can block a provider it considers non-compliant. This is not a test the entity marks for itself.
• A defined closure process. The blue team is told a test took place; testers and defenders each produce a report; both sides replay offensive and defensive actions; and purple teaming covers what went untested. Article 26(6) then requires a findings summary, remediation plans and compliance documentation to go to the authority, which under Article 26(7) issues an attestation — the mechanism allowing mutual recognition between competent authorities.

TIBER-EU is the European framework of reference. Article 26(11) directed the ESAs to develop the RTS "in accordance with the TIBER-EU framework", and the RTS states that it mirrors that framework's methodology, process and structure. TIBER-EU is the European Central Bank's framework for threat intelligence-based ethical red-teaming, updated by the Eurosystem in January 2025 to align with the DORA standards. It runs in three phases — preparation (notification, scoping, provider procurement); testing, split between threat intelligence and then active red teaming; and closure (reporting, replay, purple teaming, remediation, attestation) — and its roles map onto the regulation's equivalents. The RTS also sets a twelve-week minimum for the active red team phase: a two-week engagement is not a TLPT, however described.

                 Standard penetration test     TLPT under DORA Art 26
-----------------------------------------------------------------------------------
Trigger          Your own testing programme    Identification by the competent
                 (Art 24 and 25)               or TLPT authority

Scope            Defined asset list, agreed    Several or all critical or
                 with the business             important functions, incl.
                                               outsourced ICT services;
                                               validated by the authority

Intelligence     Tester experience, public     External threat intelligence
                 CVE / TTP knowledge           provider; threat profile;
                                               >= 3 actor-based scenarios

Target           Production, staging or a      Live production systems only;
environment      representative replica        no substitution

Oversight        Client test manager;          Control team, board-approved
                 no regulator in the loop      scope, authority test managers
                                               in every phase

Output           Technical report, severity    Red and blue team reports,
                 ratings, retest evidence      replay, purple teaming, findings
                                               and plans to the authority,
                                               authority attestation

Who is actually in scope

This should be settled before any budget is allocated, because the answer is not self-determined. Under Article 26(8), third subparagraph, competent authorities identify the entities required to perform TLPT, assessing impact-related factors, possible financial stability concerns including systemic character at Union or national level, and the entity's specific ICT risk profile, ICT maturity and technology features. The RTS turns these into a structured assessment covering size and market share, interconnectedness, criticality and substitutability of services, business-model complexity, group membership with shared ICT systems, threat landscape, reliance on ICT third parties, and the maturity of detection and response.

The RTS also names categories that TLPT authorities shall require to test, unless their own assessment indicates that impact, financial stability concerns or ICT risk profile do not justify it: global and other systemically important institutions and entities forming part of them; payment and electronic money institutions above defined transaction-value and outstanding-e-money thresholds; central securities depositories; central counterparties; trading venues meeting defined market-share tests; and the largest insurance and reinsurance undertakings. Check Article 2 of the RTS against your own figures rather than any summary, including this one.

The identification step is the whole point. An entity that has not been identified has no Article 26 obligation; one that has been identified cannot discharge it with anything less. You cannot opt in: a red team run of your own volition, however rigorous, produces no attestation under Article 26(7), because that comes from an authority that has overseen the test. Equally, you cannot opt out.

Article 26(1) sets frequency at at least every three years, and expressly allows the competent authority to reduce or increase it based on the entity's risk profile and operational circumstances. Oversight varies too: Article 26(9) lets Member States designate a single national TLPT authority, and Article 26(10) lets a competent authority delegate those tasks to another national authority. Your TLPT counterparty may not be the supervisor you deal with day to day.

One further point bears on supplier selection. Article 27 requires testers to be of the highest suitability and reputability, to demonstrate expertise in threat intelligence, penetration testing and red team testing, to be certified by an accreditation body in a Member State or adhere to formal codes of conduct or ethical frameworks, plus independent assurance on sound management of TLPT risks and professional indemnity cover. The control team must assess a candidate against those requirements and evidence compliance before contracting, and must not proceed where the authority disagrees. There is no pan-EU register of approved TLPT firms settling this in advance — suitability is assessed per test, per entity, by the authority overseeing it. More on how we approach that is on our DORA and TLPT page.

How the engagements actually differ

Both involve skilled people attacking your systems with permission. In practice they are run and governed differently, with consequences for cost and timetable.

Who knows the test is happening. A standard penetration test is announced: the SOC knows, change management has a ticket, and the firewall team has probably whitelisted the tester's traffic. A threat-led test inverts this. Knowledge sits with a small control team — under TIBER-EU, the equivalent white team is described as the only people in the tested entity who know it is happening. The TLPT regulatory technical standards require that team to be as small as possible, with information shared on a need-to-know basis, and staff outside it told only where there are cogent reasons and with the prior agreement of the authority's test managers.

The target environment. Penetration tests routinely run against staging or a carved-out slice of production, precisely to avoid operational risk. TLPT does not offer that option: testing is carried out on live production systems supporting critical or important functions, and staged replicas do not satisfy the obligation. The standards are explicit that testing critical functions in production risks denial of service, system crashes and loss or disclosure of data, and they require the control team to assess and manage those risks beforehand, consulting the authority's test managers on both.

How scope is set. For a penetration test, scope is a commercial conversation: you say what matters, we say what we think is missing, you sign. For TLPT, you identify the critical or important functions and the systems and processes supporting them — including those delivered by ICT third-party service providers — and submit a scope specification document, approved by your management body, to the authority, which validates it. The RTS also set the criteria you must weigh, among them the function's impact on financial stability, its importance to daily operations, and its interconnectedness. You cannot quietly scope out the uncomfortable system: the authority sees your reasoning, and validates your control team as well as your scope.

What success means. A penetration test succeeds when it achieves coverage: the tester has worked systematically through the attack surface, and a good report says honestly where it did not reach. TLPT succeeds when the red team pursues defined objectives against a live, unaware, actively defending organisation, and the exercise evidences whether that organisation noticed, how quickly, and what it did. A red team caught early is not a failed test — it is a good result, provided the detection is genuine.

Duration and intensity. A scoped application or internal network test runs in days or weeks. The TLPT timetable is longer and largely fixed by regulation. The TLPT regulatory technical standards require the active red team testing phase to last at least twelve weeks, the stated rationale being that a shorter window cannot credibly mimic a stealthy threat actor. That sits inside a longer process: preparation and procurement, a threat intelligence phase the RTS note typically runs around four weeks on TIBER-EU experience, the test plan, then closure. Add the lead time — the scope document is due within six months of the authority's notification — and treat the whole thing as a programme spanning the better part of a year.

The deliverable. A penetration test produces one report, usually with a retest. TLPT produces a documented chain: initiation and scope documents, a targeted threat intelligence report, a red team test plan and test report, a blue team report, the record of replay and purple teaming, a test summary report and a remediation plan — and finally an attestation issued by the TLPT authority, confirming the test met the requirements and identifying which functions were in scope. That attestation is what your supervisor cares about, and only the authority can issue it.

The people and roles a TLPT needs

Four parties are involved, and the separation between them is deliberate rather than bureaucratic.

• The control team, inside the entity. Led by someone senior enough, and with enough organisational knowledge, to direct the test without leaking it, and with access to the management body. The RTS make it responsible for communications, informing the management body of progress and risk, selecting the threat-intelligence provider and testers, preparing the scope specification document, and running risk management. It also provides any sanctioned assistance to the testers — the leg-ups that let a stalled scenario continue — and only with the authority's agreement.
• A separate threat-intelligence provider. It gathers intelligence specific to your entity — the realistic attack surface, the relevant threat actors and probable scenarios — producing the targeted threat intelligence report the test plan is built from. Where you use internal testers, DORA requires this provider to be external.
• The red team. The testers who execute scenarios against production. Article 27 of DORA sets requirements for external testers covering suitability and reputability, technical and operational capability, certification, independent assurance of sound management of testing risk, and professional indemnity cover. Internal testers are permitted only under conditions, including prior supervisory approval, absence of conflicts of interest, and contracting external testers every three tests.
• The authority's oversight. A TLPT cyber team within the authority, working through named test managers, validates the control team and the scope, is consulted on risk management, is involved in decisions during the test, and issues the attestation.

The separation matters because each party checks the others. Intelligence produced by the team that will exploit it converges on scenarios that team already likes. An entity that both sets and validates its own scope will, over time, scope towards what it can survive. And because no party holds the whole picture, the exercise lives or dies on governance: approvals, documented decisions, clean escalation, disciplined record-keeping. That is why TLPT consumes risk, legal and board attention out of proportion to the technical work.

Preparing for a threat-led test

Most of the preparation is not technical. In rough order of what blocks people:

• Identify your critical or important functions, then the systems beneath them. Not the application inventory — the mapping from business function to the ICT systems, processes and third-party services that support it. Entities repeatedly find this mapping stale, held in someone's head, or stopping at an outsourced boundary. Fixing it is months of work.
• Establish the control team and its escalation paths. Decide in advance who is woken at 03:00 if a scenario causes an outage, how a live incident is distinguished from test activity without telling the responders, what triggers a stop, and who may authorise a leg-up. Write it down before testing, not during.
• Ensure detection and response are genuinely unaware. Harder than it sounds where security leadership is also the natural control team. If your head of SOC sits in the control team, the SOC is not being tested.
• Get risk-management and legal approvals in place early. Production testing against critical functions needs a documented risk assessment, agreed mitigations, management body visibility, and clarity on contracts, data protection and any third party whose infrastructure may be touched.
• Rehearse, so the formal test is not the first time your organisation has attempted any of this.

Why a rehearsal is usually the right first step

If you are facing a first formal test, a scoped adversarial exercise beforehand is usually money well spent, for three fairly unglamorous reasons. It surfaces the obvious gaps cheaply: flat internal networks, over-permissioned service accounts, unmonitored egress and credentials in repositories are found in days, and a twelve-week regulated exercise is an expensive place to learn them. It exercises the control-team process — the first time an organisation attempts covert testing, what breaks is rarely the technology but the escalation path, who may approve what, and the discipline of keeping a secret over months. And it changes what the formal test is spent on, because an exercise consumed by basic misconfiguration gives a thinner answer to the question that matters: can this organisation detect and respond to a capable adversary pursuing its critical functions?

This is where red teaming aligned to the TIBER-EU approach earns its place as preparation: the same intelligence-led methodology and control-team discipline, but scoped and timed to your readiness rather than to a regulatory clock. PXL Security delivers that work and supports entities preparing for formal threat-led penetration testing: scoping support, control-team readiness, rehearsal exercises and remediation.

We should be equally plain about what a rehearsal is not. It is not a TLPT, it does not discharge the obligation, and it produces no attestation. Whether an engagement qualifies, and which testers may carry it out, is determined by your authority against DORA and the TLPT regulatory technical standards — not by any provider, and not by us. PXL Security does not present itself as an accredited or qualified TLPT provider under any national scheme, and a provider claiming otherwise about its own status is a reason for caution rather than comfort.

Common misconceptions

• "Every financial entity has to do TLPT." No. The general testing programme applies broadly; TLPT applies to entities identified by the competent authorities against criteria in DORA. Operating in a regulated sector does not put you in scope, and assuming you are wastes budget.
• "Our annual penetration test covers it." It does not, for structural reasons rather than reasons of quality. A penetration test is announced, often non-production, scoped between you and your supplier, and measured on coverage. None of that holds for TLPT.
• "We can run a red team and call it TLPT." You cannot self-declare. The scope document and control team are validated by the authority, the process has defined phases, tester requirements are set in regulation, and the attestation comes from the authority.
• "TLPT replaces the rest of the testing programme." It sits on top of it. A test on a multi-year cycle against selected critical functions tells you nothing about the application you shipped last month.
• "The output is a list of vulnerabilities." The output is an assessment of protection, detection and response under realistic attack, evidenced from both sides: what the red team did, what the blue team saw, and what the two agree happened on replay. A TLPT read as a vulnerability list has been misread.