DORA Threat-Led Penetration Testing (TLPT): What Firms Must Actually Commission

A reading of what DORA’s Threat-Led Penetration Testing regime actually requires, written for the firms that have to commission and survive one.

DORA’s Article 26 introduces a mandatory threat-led penetration testing regime for financial entities identified as significant by their competent authorities. The technical implementing standards — built on the TIBER-EU framework that European central banks have been refining since 2018 — set out what a test actually looks like. For the firms in scope, TLPT is the most expensive single piece of DORA compliance.

This is a reading of what TLPT substantively demands, what the test costs in time and attention, and what “good” looks like for the tech function being tested.

What TLPT is

Threat-led penetration testing is what it sounds like, but with discipline. Rather than a generic penetration test against a defined scope, TLPT is an exercise where external red-team testers, working from current threat intelligence about the kinds of attackers your firm faces, attempt to breach the firm’s critical functions over a multi-month period, without the defenders being told it is a test.

Three things make TLPT different from a normal penetration test:

• It is threat-intelligence-led. The testers do not work from a generic threat model; they work from a current threat-intelligence report specific to the firm and its sector.
• It is unannounced to the defenders. The blue team — the security operations centre and the incident responders — are not told a test is happening. The point is to measure how the defenders actually perform, not to measure how a coordinated team performs when it knows it is being watched.
• It targets critical functions, not infrastructure for its own sake. The test scope is defined by the financial entity’s critical functions — the services that, if disrupted, would have a material impact on operations, customers, or the market.

Who must do TLPT

Not every DORA-in-scope entity has to do TLPT. The regulation reserves it for entities identified by the competent authorities as having a significant impact on financial stability or the operation of financial markets. The identification criteria are set out in the implementing standards.

In practice, the in-scope population includes:

• Significant credit institutions — the larger banks.
• Central counterparties, central securities depositories, and trading venues above a defined size.
• Significant payment institutions, e-money institutions, and account information service providers.
• Crypto-asset service providers identified as significant — typically the larger exchanges and custodians.
• Insurance and reinsurance undertakings above a defined size.

The frequency is at least every three years. The first round of testing for the larger entities has been under way since mid-2025.

The three phases

A TLPT exercise has three formal phases, each with its own deliverables and competent-authority engagement points.

Preparation phase. Typically three to four months. Identification of critical functions in scope, threat intelligence gathering, test scenario development, test plan approval by the competent authority, selection of testers, NDA arrangements, and the establishment of the test control team — the small group inside the firm that knows the test is happening and acts as the bridge between testers and the firm’s management.

Testing phase. Typically three to six months. The testers attempt to compromise the critical functions using TTPs derived from the threat intelligence. Multiple attack vectors are usually attempted — phishing, supply chain, infrastructure exploitation, social engineering. The defenders detect what they can. The test control team observes both sides.

Closure phase. Typically two to three months. Test report, root cause analysis, remediation planning, debrief with the defenders (now told the test was a test), purple-team exercise where the testers and defenders work together, and submission of the test report to the competent authority.

Total elapsed time from kick-off to report submission: typically nine to twelve months. The cost — testers, threat intelligence, internal time, remediation — runs into multi-hundred-thousand-euro territory for a mid-sized entity, and significantly higher for the larger ones.

Where firms underestimate the work

From the TIBER-EU exercises and the first TLPT rounds under DORA:

The critical-functions identification is harder than it looks. “Critical function” has a specific meaning under DORA — services whose disruption would have material impact. Most firms have not formally documented their critical functions to this standard. The test scope cannot be agreed until this is done.

The test control team needs preparation. The small group inside the firm that knows the test is happening — usually the CISO, CIO, head of internal audit, and the test lead — has to maintain strict information barriers while the test runs. The blue team must not be tipped off. Maintaining this for six months while running the rest of the business is harder than it sounds.

Tester selection takes time. The competent authority has to approve the testers. The number of approved providers is small. Lead times are months, not weeks. Firms that start tester selection late find themselves waiting.

The remediation budget is rarely planned in advance. A TLPT exercise will find things. Things cost money to fix. Firms that have not allocated a remediation budget alongside the test budget find themselves with findings they cannot act on. Competent authorities expect remediation plans, not just findings.

The purple-team closure is treated as optional. It is not. The exercise where testers and defenders work through what happened, jointly, is where most of the operational improvement comes from. Skipping it means the test has identified gaps but the defenders have not learned how to close them.

What “good” looks like for the tech function

For the technology function being tested, a successful TLPT is not one where the testers fail to get in. It is one where the firm understands what happened, can demonstrate that the defenders performed as the firm expected them to perform, and can show credible remediation of identified gaps.

Specifically, a tech function in a defensible position has:

• Documented critical functions and the ICT systems supporting them.
• A security operations capability that can detect at least some of the activities the testers will perform — not all, but a credible proportion.
• An incident response capability that, when notified of something suspicious, follows the playbook and escalates appropriately.
• Logging and forensic capabilities sufficient to reconstruct what the testers did after the fact.
• A remediation budget and an executive sponsor able to authorise spend on findings.

The competent authority is not measuring whether you stopped the testers. They are measuring whether your operational resilience is what you said it was.

How we engage with this

We do not run TLPT exercises. We are not approved testers. We do not provide threat intelligence. What we do, before a TLPT exercise begins, is read whether the firm is ready for one — whether the critical functions are documented, whether the architecture is understood, whether the detection capability is what the firm believes it is. As a Technology Control Review scoped to DORA Article 26 readiness, the output is a written assessment of where the firm stands and what to address before the test starts.

The TLPT itself goes to approved testers. We do not compete with them. Our reading exists to give the tech function the best chance of a successful exercise.

Pricing is published at /pricing/. If your firm has been identified for TLPT and you would like an independent reading of readiness, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.