Most security leaders at regulated financial institutions already know their organization is supposed to do annual penetration testing under DORA.
Far fewer understand that DORA’s testing mandate has two entirely separate tiers, and that the second tier represents something categorically different from anything in a standard security testing programme.
Conflating them is the most expensive mistake in the market right now. If your organization has been designated for TLPT, or expects to be, and your plan is an expanded penetration test, you are not prepared for what Article 26 actually requires.
Here is what the regulation demands, what the frameworks look like in practice, and what the firms getting this right are doing differently.
Tier One: What every DORA-covered firm must do
Articles 24 and 25 of DORA require all in-scope financial entities to run an annual programme of digital operational resilience testing. This is not optional. It is not satisfied by a vulnerability scan. And it is not limited to the systems your security team already knew about.
The scope is comprehensive: all ICT systems supporting critical or important functions. In practice, that means significantly more than a traditional scoped penetration test would cover. The programme must be risk-based, approved at management body level, and findings must feed back into the ICT risk management framework at governance level, not sit in a technical report that nobody reads above the security team.
Testing types at this tier include vulnerability assessments, open-source intelligence gathering, network security assessments, gap analyses, physical security reviews, and scenario-based testing. This is a broader mandate than most firms currently run. But it is still testing that your internal teams, or an external provider, can plan and scope in advance.
Tier one is demanding. It is not, however, what most of the industry conversation about DORA testing is actually about.
Tier Two: DORA TLPT under Article 26
Article 26 introduces Threat-Led Penetration Testing as a separate, advanced requirement for institutions designated by their competent authority. The designation is a formal notification from your national regulator, based on your institution’s systemic importance and risk profile. If you have not been notified, you are not currently in scope for TLPT.
But if you have been notified, or if you expect to be, what follows is an entirely different category of exercise.
TLPT is not a penetration test with a bigger scope. It is an intelligence-led, full-spectrum red team simulation conducted on live production systems, with your defending team completely unaware the exercise is happening. No pre-notification to the blue team. No defined scope handed to the testers in advance. No comfortable boundaries that keep the exercise away from the systems that actually matter.
The exercise begins not with technical scanning but with a dedicated threat intelligence phase. This maps the threat actor groups known to target organisations like yours: their tactics, techniques, and procedures (TTPs), their preferred initial access vectors, and the specific assets in your environment that represent meaningful objectives. The red team then builds and executes a campaign against your live systems based on that intelligence, not against a pre-agreed target list.
Article 26 also requires that TLPT be conducted by accredited external testers, working under a recognised framework. That framework is TIBER-EU.
TIBER-EU, CBEST, and STAR-FS: What the frameworks actually are
TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) is the ECB’s framework for intelligence-led red team testing in the European financial sector. It is implemented at national level by each member state’s competent authority, with country-specific guidance on scope, process, and accreditation. The methodology and regulatory standing of the output do not vary.
In the UK, the equivalent frameworks are CBEST and STAR-FS.
CBEST is the Bank of England’s framework for advanced, intelligence-led cyber security testing of UK financial sector firms. CBEST-certified exercises are recognised by DORA as satisfying the TLPT requirement, given the alignment between CBEST and TIBER-EU methodology.
STAR-FS (Simulated Target Attack and Response for Financial Services) is CREST’s framework, designed to deliver CBEST-equivalent testing at scale across a broader population of regulated financial firms. It uses the same intelligence-led methodology and accreditation standards, making it the appropriate route for firms that need to demonstrate DORA-aligned resilience testing without undergoing a full CBEST exercise.
CovertSwarm holds accreditation under both CBEST and STAR-FS. That means the output of a CovertSwarm TLPT exercise is formally recognised by the Bank of England, the PRA, and the FCA as satisfying the most demanding regulatory testing requirements in the UK market, and maps directly to DORA’s Article 26 mandate.
What a DORA TLPT exercise actually looks like
Most security professionals have run or commissioned a red team engagement. TLPT is not that. The process is more structured, more operationally intensive, and considerably longer.
A TLPT exercise under the TIBER-EU and CBEST frameworks runs through three distinct phases.
Phase 1: Threat Intelligence
A dedicated threat intelligence provider, separate from the red team, conducts a targeted threat landscape assessment. This maps which threat actor groups are known to target organisations of your type, size, and geography, analyses their documented TTPs and preferred initialaccess vectors, and identifies the specific crown jewels in your environment that represent meaningful objectives. The output is a Targeted Threat Intelligence report that drives the entire red team engagement. The red team does not write this. An independent intelligence provider does.
Phase 2: Red Team
The red team, working from the threat intelligence report, plans and executes a campaign against your live production environment. Your blue team is unaware this is happening. The exercise has agreed objectives, reaching specific systems, data, or capabilities, rather than a defined list of systems to test. The red team uses real adversary TTPs, real tooling, and real attack chains, including digital, social engineering, and in some exercises, physical vectors. The exercise runs for weeks or months, not days.
Phase 3: Purple Team closure
Once the red team exercise concludes, your blue team is brought in for structured knowledge transfer. The attacks are walked through in detail: what worked, what did not, what was detected, what was not, and why. This is the phase where defensive capability is actually assessedand improved, not just the offensive capability of the red team.
The entire exercise is overseen by a control team including representatives from your organisation, the regulators, and the testing providers. The output is a formal report submitted to your competent authority, not a finding list for internal remediation.
This is not something you run in a week between quarterly board meetings.
The misconceptions that will cost you most
“Our annual penetration test covers this.”
A standard penetration test has a defined scope, a defined timeframe, and typically involves your security team knowing it is happening. TLPT has no predefined technical scope, runs against live production systems, and your blue team is deliberately kept unaware. These are not variations of the same exercise. They are different disciplines with different regulatory standing.
“We passed CBEST three years ago, so we are compliant.”
DORA requires TLPT to be conducted at least every three years. If your last exercise was more than three years ago, you are not compliant. And your environment has changed, your threat landscape has changed, and your results are not current.
“We have been designated, but the 2028 deadline gives us time.”
The January 17, 2028 deadline is when your first mandatory TLPT must be completed. Not started. A full exercise, including provider procurement, the threat intelligence phase, the red team campaign, and purple team closure, takes six to twelve months to run properly. Add procurement lead time and internal preparation, and if you have been designated and have not begun planning, you are already behind. The 2028 deadline is considerably closer than it looks.
“We can scope out our most sensitive systems to manage risk.”
TLPT is specifically designed to test the systems that actually matter. The entire point is that a real attacker would target those systems first. Scoping them out produces a result that is neither accurate nor regulatorily valid, and if an incident later exposes the gap, the scoping decision becomes part of the regulatory record.
The problem with a three-year cycle
Here is the part regulators will not say out loud, but practitioners already know.
A three-year TLPT cycle is a regulatory compromise. It reflects what is operationally feasible for large financial institutions to absorb, coordinate with regulators, and fund. It is not based on how often the threat landscape changes.
Real threat actors do not operate on a three-year cycle. The TTPs documented in a 2025 threat intelligence report may be partially obsolete by 2026. New groups emerge. Existing groups evolve their tooling. Your attack surface changes continuously: new acquisitions, new cloud infrastructure, new third-party relationships, new personnel with access to critical systems.
A TLPT exercise tells you what a sophisticated attacker could do to your organisation on the day the exercise was conducted. It does not tell you what they could do eighteen months later, after three major system migrations and a new managed service provider.
DORA’s architects understood this. It is why the regulation mandates continuous threat-led testing at tier one for all in-scope firms, and why the expectation is that TLPT sits within a broader, ongoing programme of adversarial validation. Not as a standalone exercise that satisfies the requirement and disappears from the agenda for another three years.
The firms that treat DORA threat-led penetration testing as a compliance checkpoint will pass their exercise. They will also carry a false sense of assurance for the thirty-five months that follow.
The firms that treat it as the most intensive point in a continuous testing programme will have something more useful: actual confidence in whether their defences hold up, right now, against the adversaries that are specifically interested in them.
What comes next
The third post in this series maps DORA’s requirements to the offensive security capabilities that address them, and what a DORA-aligned security programme looks like across twelve months rather than just the months when a regulatory exercise is running.
If the gap between your documented resilience and your tested resilience is the question this piece raised, the DORA Readiness Guide sets out the full picture: the five pillars, the most common compliance gaps, and what genuine operational resilience looks like in practice.
Download the DORA Readiness Guide