DORA, the EU’s Digital Operational Resilience Act, has been directly applicable law since 17 January 2025, and its testing requirements are where most financial firms run into trouble first. The regulation sets up two genuinely different testing obligations under one name, and conflating them is the single most common mistake we see: basic ICT testing that applies to nearly every in-scope entity every year, and Threat-Led Penetration Testing (TLPT), a far heavier, specialised exercise that only a defined subset of firms ever has to run. This guide separates the two clearly, explains exactly who has to do what, and walks through what a TLPT engagement actually involves phase by phase.
The two tiers DORA actually sets up
DORA’s digital operational resilience testing programme, set out in Article 24 and detailed further in Article 25, requires every in-scope financial entity to test its ICT systems and controls that support critical or important functions. This baseline testing includes vulnerability assessments, network security assessments, gap analyses, source code reviews, scenario-based tests, and, for most firms, penetration testing. It has to happen at least annually and has to be carried out by testers who are independent of the staff who built and maintain the systems being tested, whether that independence comes from an external firm or a properly segregated internal team.
Threat-Led Penetration Testing, defined in Article 26, is a different animal entirely. TLPT is a live-fire, intelligence-driven simulation of a real adversary attacking your actual production systems, run at least once every three years, and it only applies to a specific, formally designated subset of financial entities. Confusing the two leads to two opposite failure modes: firms that assume they need full TLPT when they don’t, and firms that run a routine annual pentest and assume it covers TLPT when it does not come close.
Who actually has to run TLPT
This is where a lot of the guidance circulating online gets vague or simply wrong. DORA does not name a fixed revenue or transaction-volume threshold that automatically pulls a firm into TLPT scope. Instead, Article 26(8) and the Regulatory Technical Standards on TLPT direct national competent authorities to identify in-scope entities based on impact, contribution to financial-stability risk, and specific ICT-risk profile factors, not a single hard number.
In practice, that identification process converges on a few recognisable categories:
- Globally and other systemically important institutions. Entities designated as G-SIIs or O-SIIs under the CRR/CRD framework are treated as primary TLPT candidates by default, given their role in system-wide stability.
- Credit institutions supervised as significant by the ECB. For banks under direct ECB/SSM supervision, total assets in the region of €30 billion is a commonly cited practical indicator national authorities use, though it is an indicator, not a codified legal threshold.
- Market infrastructure operators. Central counterparties, central securities depositories, and major trading venues are typically designated given their systemic role in clearing and settlement.
- Other entities the competent authority designates. Large payment institutions, e-money institutions, and insurers can be pulled into scope where the national authority assesses their ICT risk profile warrants it, even without meeting a size threshold on paper.
Designation is formal, not self-assessed: an entity receives written notification from its national competent authority confirming it is in scope for TLPT, and the testing obligation runs from that date. If you have not received that notification, the working assumption for most mid-sized Cyprus-regulated and EU-regulated firms is that Article 24’s annual baseline testing is the relevant obligation, not full TLPT, and that is true for the substantial majority of CIFs, payment firms, and smaller banks operating in the EU today.
There is one hard exception worth flagging specifically: under Article 26(8), credit institutions classified as significant under Article 6(4) of the SSM Regulation must always use external testers for TLPT. Internal testing is not an option for that category, regardless of any other circumstances.
How a TLPT engagement is actually structured
TLPT under DORA has to follow the TIBER-EU framework, and the RTS breaks the engagement into a defined lifecycle rather than leaving scoping to the tester’s discretion. The four phases, with realistic duration ranges based on how TIBER-EU tests actually run in practice, look like this:
| Phase | Typical duration | What happens |
|---|---|---|
| Preparation | 4–8 weeks | Scope confirmation, identification of critical functions in scope, control team formation, generic threat landscape briefing. |
| Threat intelligence | 6–10 weeks | An accredited threat intelligence provider produces a Targeted Threat Intelligence report profiling realistic adversaries and attack paths specific to the entity’s actual risk profile. |
| Active testing (red team) | 8–12 weeks | Covert, live-fire attack simulation against production systems, built directly from the threat intelligence report. The blue team (SOC/defenders) is not informed in advance, by design. |
| Closure and purple teaming | Several weeks | Mandatory purple team replay workshop where the red team walks the blue team through every attack path, including the ones that went undetected, followed by root-cause analysis, remediation planning, and a formal attestation. |
End to end, a genuine TLPT engagement routinely spans six months or more once scoping, threat intelligence, live testing, and the closure process are all accounted for. That timeline is precisely why TLPT cannot be treated as an extended version of an annual pentest, it is a materially different undertaking in scope, duration, and the specialised roles involved.
Internal versus external testers
DORA does allow internal testers for TLPT, but within specific limits. A financial entity can use internal testers for up to two consecutive TLPT cycles, but must bring in an external tester at least once every three testing cycles. Internal testers now need a minimum of one year’s tenure at the entity before they can act in that role, and internal testers are held to the same qualification standard as external ones, there is no lighter bar for using in-house staff. As noted above, this internal option disappears entirely for SSM-significant credit institutions, which must always contract external testers under Article 26(8).
The RTS also requires separation between the threat intelligence provider and the red team provider carrying out the active testing, on the reasoning that a single vendor producing both the target profile and the attack against it introduces an obvious conflict of interest.
TLPT versus the annual Article 24 baseline
| Article 24 basic testing | Article 26 TLPT | |
|---|---|---|
| Who it applies to | Nearly every in-scope financial entity | Only formally designated significant entities |
| Frequency | At least annually | At least every 3 years |
| Duration | Days to a few weeks per assessment | Typically 6+ months end to end |
| Methods | Vulnerability assessments, penetration tests, scenario testing, code review | Live-fire threat intelligence-led red team simulation |
| Tester independence | Independent of build/maintenance staff | Accredited external red team plus separate TI provider (or limited internal use) |
| Regulatory reporting | Internal record-keeping, available on supervisory request | Formal reports submitted to the entity and the competent authority |
How TIBER-EU fits in
TIBER-EU was originally the European Central Bank’s voluntary threat-led testing framework, developed years before DORA existed, and several national central banks and financial supervisors across the EU had already adopted national versions of it. DORA’s TLPT requirement was deliberately built on top of TIBER-EU rather than inventing a separate methodology, so an entity that has already run a TIBER-based test under a national framework is generally in a strong position to satisfy DORA’s Article 26 requirement without starting from zero, provided the specific RTS requirements around provider separation, reporting, and attestation are met.
What this means if you are not a TLPT-designated entity
For the great majority of financial firms, including most Cyprus Investment Firms, payment institutions, and smaller banks, the immediate, actionable obligation is Article 24’s annual testing programme, not TLPT. That still means manual, evidence-backed penetration testing of the systems supporting your critical or important functions, carried out by testers independent of the team that built them, documented well enough to survive a supervisory review. It is a materially lighter undertaking than TLPT, but it is not optional, and “we ran a vulnerability scan last year” does not satisfy it.
Our penetration testing service is built around exactly this kind of manual, evidence-producing engagement rather than an automated scan with a report generator attached. Where the critical function in question is a customer-facing platform, our web application penetration testing work goes directly at the application and API layer most incidents actually originate from, and for the wider infrastructure and network perimeter supporting those functions, our website penetration testing services cover what Article 24 expects tested and documented. If your entity has received formal TLPT designation, that is a separate, specialised engagement requiring accredited threat intelligence and red team providers under the TIBER-EU methodology, worth confirming directly with your competent authority before scoping any test.
Frequently asked questions
Does every DORA-regulated firm need Threat-Led Penetration Testing?
No. Every in-scope entity needs annual basic ICT testing under Article 24. TLPT under Article 26 only applies to entities formally designated by their national competent authority, based on systemic importance and ICT-risk profile, not to every regulated firm by default.
How long does a TLPT engagement take?
Individual phases range from a few weeks to several months, and a full engagement, from preparation through threat intelligence, active testing, and the mandatory purple team closure, typically spans six months or more in practice.
Can a firm use its own staff to run TLPT?
Partially. Internal testers can be used for up to two of every three TLPT cycles, provided they meet the same qualification bar as external testers and have at least one year of tenure at the entity. At least one cycle in three must use an external tester, and SSM-significant credit institutions must always use external testers with no internal option.
Is TLPT the same as TIBER-EU testing?
They are closely related but not identical. TIBER-EU is the underlying methodology DORA’s TLPT requirement is built on. An entity that has already completed a TIBER-EU test under a national framework has a strong starting point for DORA compliance, but still needs to confirm the specific RTS requirements on provider independence and regulatory reporting are satisfied.
What happens if a firm fails to meet DORA’s testing requirements?
Enforcement runs through national competent authorities and can include formal corrective action orders, mandated remediation timelines, and financial penalties under the relevant national implementing law. Supervisory examinations increasingly check testing records directly as part of routine oversight, not only after an incident.
The practical takeaway
Most firms reading about DORA penetration testing requirements are not staring down a TLPT designation, they are staring down an annual testing obligation under Article 24 that still has to be manual, independent, and properly documented. Knowing which tier actually applies to your entity, and not over-building or under-building your testing programme around the wrong one, is the first real decision to get right before scoping anything.