The IT director of a mid-sized brokerage house asks at a meeting: “how much will TLPT cost us?” The question is a whole level too early. Before an answer is given, someone has to check whether the supervisory authority has designated that entity for TLPT at all — because if it has not, money spent on an advanced test buys prestige, not compliance. The same error works in reverse: an institution that hears six-figure TLPT quotes and concludes “we cannot afford it” often does nothing, even though the testing programme obligation applies to it regardless of TLPT.
Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 (OJ L 333, 27.12.2022, p. 1), known as DORA, has applied since 17 January 2025 (Article 64, second paragraph). Its Chapter IV describes testing in Articles 24 to 27 and splits it across two levels: a testing programme binding on almost everyone, and TLPT for a narrow, designated group. This text separates the two levels and cites, for every claim, the provision it comes from. The details of TLPT itself — methodology, preparation and conduct — we develop in separate articles that we point to along the way.
What does DORA require from a financial entity in terms of testing?
Establishing and maintaining a programme, not running individual tests. Article 24(1) obliges financial entities other than microenterprises to establish, maintain and review “a sound and comprehensive digital operational resilience testing programme as an integral part of the ICT risk-management framework referred to in Article 6”.
The programme has four purposes, stated in that same paragraph: assessing preparedness for handling ICT-related incidents, identifying weaknesses, identifying deficiencies and gaps, and promptly implementing corrective measures. The last one is the one most often skipped in practice — a test not followed by remediation does not fulfil the purpose of the provision, even though it formally took place.
Article 24(5) closes the loop: the entity establishes procedures and policies to prioritise, classify and remedy all issues revealed during testing, together with internal validation methodologies confirming that identified weaknesses have been fully addressed. A test report on its own is not evidence of compliance; the evidence is a closed cycle running from finding to verified remediation.
Who is covered by the testing obligation and who is exempt?
The obligation covers all financial entities other than microenterprises, and the definition is sharp and numerical. Under Article 3(60) of the Regulation, a microenterprise is a financial entity other than a trading venue, a central counterparty, a trade repository or a central securities depository, which employs fewer than 10 persons and has an annual turnover and/or annual balance sheet total not exceeding EUR 2 million.
The exemption is not complete. Article 25(3) requires microenterprises to perform the tests from the Article 25(1) catalogue by combining a risk-based approach with strategic planning of ICT testing — balancing the scale of resources against the criticality of information assets. What disappears is the comprehensive programme, not the testing.
The scale of the obligation is, however, graded by the principle of proportionality. Article 4(2) requires Chapter IV to be applied in a manner proportionate to the entity’s size and overall risk profile, and to the nature, scale and complexity of its services, activities and operations. In practice it is this provision, not the size of the budget, that justifies why a smaller entity’s programme looks different from a bank’s.
The decision at the entrance: until you know whether you are a microenterprise within the meaning of Article 3(60), you do not know which testing regime applies to you. That is a question about two figures from your own financial statements, not about a maturity assessment.
Which tests fall within the catalogue in the Regulation?
The catalogue in Article 25(1) is long and deliberately heterogeneous. The Regulation lists vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scanning software solutions, source code reviews where feasible, scenario-based tests, compatibility testing, performance testing, end-to-end testing and penetration testing.
Penetration testing is one of a dozen or so entries in a non-exhaustive list (“such as”), not a summary of it. That has a planning consequence: commissioning a single penetration test per year does not exhaust Article 25 if critical functions — as identified in the risk analysis — depend on code nobody has reviewed, or on a network configuration nobody has assessed.
For two categories of entity the provision goes further than the catalogue. Article 25(2) requires central securities depositories and central counterparties to perform vulnerability assessments before any deployment or redeployment of new or existing applications, infrastructure components and ICT services supporting critical or important functions. That is an event-driven requirement, not a calendar one.
How often do systems supporting critical functions have to be tested?
At least once a year — and that is the only hard cadence at the basic level. Article 24(6) requires entities other than microenterprises to ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.
Two words in that provision drive the cost. “All” means the denominator is the inventory of systems supporting critical functions, not the list of those that happened to change. “Appropriate” means the choice of test for a given system follows from risk analysis — and here the whole catalogue from Article 25(1) comes back, rather than one method for everything.
TLPT has its own clock, independent of that annual one. Article 26(1) requires advanced testing at least every three years, with the caveat that the competent authority may — based on the entity’s risk profile and operational circumstances — request that this frequency be reduced or increased.
Who may carry out a test, and what does an “independent tester” mean?
An independent party, whether internal or external — Article 24(4) allows both options at the basic level. Where an internal tester is used, the provision sets two conditions: the entity dedicates sufficient resources and ensures that conflicts of interest are avoided throughout the design and execution phases of the test.
Conflict of interest here is a broader notion than “do not test your own code”. It also covers the design phase of the test, that is the moment when scope is set. A team that decides for itself what the test will not cover, and is itself accountable for the security of that area, satisfies the letter of the requirement on paper only.
At the TLPT level the Regulation tightens the rule arithmetically. Article 26(8) requires entities using internal testers to contract external testers every three tests, and credit institutions classified as significant in accordance with Article 6(4) of Regulation (EU) No 1024/2013 may only use external testers meeting the conditions of Article 27(1), points (a) to (e).
How does TLPT differ from a penetration test under Article 25?
In scope, in stage and in who validates it. Article 26(2) requires each threat-led penetration test to cover several or all critical or important functions of the entity and to be performed on live production systems supporting those functions. The result of the assessment of which functions to cover determines the precise scope of the TLPT and is validated by the competent authorities.
A test from the Article 25 catalogue has none of those three features. Its scope is often a single application, its stage is usually a test or pre-production environment, and the entity sets the scope itself within its own programme. The difference is therefore not about the “depth” of the test, but about what the test is in legal terms: a tool of the programme, or a separate obligation under supervision.
The methodology of TLPT, the way scenarios are built and the intelligence layer we describe in detail in the article on TLPT cybersecurity testing based on cyber intelligence. Here we are interested only in the boundary between the levels.
Who actually has to carry out TLPT?
Entities designated by the authority — and since 2025 it is known who lands on that list by default. Article 26(8), third subparagraph, left the designation to the competent authorities, pointing to three groups of criteria: impact-related factors, in particular the extent to which the entity’s services and activities affect the financial sector; financial stability concerns; and the specific ICT risk profile and level of ICT maturity of the entity.
Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025 (OJ L series, 2025/1190, 18.6.2025) made this concrete. Its Article 2(2) lists the entities from which the authority requires TLPT unless the risk profile assessment indicates otherwise: global and other systemically important institutions and entities forming part of them, payment institutions with transaction value above EUR 150 billion in each of the two preceding years, e-money institutions above that same threshold or above EUR 40 billion of electronic money in circulation, central securities depositories, central counterparties, the largest trading venues, and insurance undertakings meeting the cumulative criteria on premiums, technical provisions and share of market assets.
The thresholds on the insurance list show the scale of the cut-off: gross written premiums above EUR 1.5 billion, technical provisions above EUR 10 billion and — for life and composite undertakings — assets exceeding 3.5 % of the assets of all undertakings established in the Member State concerned. An entity nowhere near those orders of magnitude is almost certainly not an addressee of TLPT. Practical preparation for those who are is described in the same article on TLPT testing, in the part on preparing for the test.
The order that saves money: first hold your own figures against Article 2(2) of Regulation 2025/1190, then calculate the cost of the test. The reverse order costs you either an unnecessary test, or a year of delay in building the programme that is mandatory anyway.
How long does TLPT take if you add up the deadlines in the delegated regulation?
The only hard minimum in the whole process is 12 weeks of active testing. Article 11(5) of Regulation 2025/1190 requires the duration of the active red team testing phase to be proportionate to the scope and complexity of the test and, in any case, to last at least 12 weeks. The other deadlines in that act are maximums — they set the latest permissible moment, not the earliest.
Added up, however, they give a realistic picture of the calendar. From the authority’s notification the entity has 3 months for the project charter and 6 months for the scope specification document (Article 9(2) and (6)). After the active testing phase ends, the testers have 4 weeks for the red team test report, the blue team has 10 weeks for its own report and for the replay of the exercise, the entity has 8 weeks for the summary report (Article 12(2), (4), (5) and (7)) and a further 8 weeks for the remediation plan (Article 13(1)).
If those deadlines are used in full, roughly fifteen months pass between the notification and the submission of the remediation plan — and that excludes the threat intelligence phase, which has no deadline of its own. The figure is a sum of provisions, not a market estimate; every component of it can be checked in the text of the regulation.
What does DORA require from a firm that is to carry out TLPT?
Five things at once, listed in Article 27(1) of Regulation 2022/2554. Testers must be of the highest suitability and reputability, possess technical and organisational capabilities and demonstrate specific expertise in threat intelligence, penetration testing and red team testing.
The three remaining requirements are formal, and they are the ones that most often decide a tender: certification by an accreditation body in a Member State or adherence to formal codes of conduct or ethical frameworks, an independent assurance or audit report on the sound management of risks associated with carrying out TLPT, and full professional indemnity insurance, including against risks of misconduct and negligence.
The delegated regulation adds an experience threshold counted in references. Article 7(1) requires the threat intelligence provider to present at least three references from previous assignments, and external testers at least five. The role of certification and team competencies on the supplier side is discussed in the same article on TLPT testing, in the part on the skills of the testing team.
How do ICT third-party service providers enter the scope of testing?
They enter when they operate functions within scope — and it is the financial entity that is accountable for their participation. Article 26(3) requires the necessary measures and safeguards to be taken to ensure the participation of ICT third-party service providers in the TLPT, while the financial entity “shall retain at all times full responsibility for ensuring compliance with this Regulation”.
The Regulation provides a release valve for situations where such participation would harm the provider’s other customers. Article 26(4) allows a written agreement under which the provider contracts directly with an external tester and a pooled test of several financial entities is conducted under the direction of one designated entity. Such testing is considered TLPT carried out by each participating entity.
The contractual consequence is simple, and worth drawing before the contract is signed rather than after designation for TLPT: an agreement with a provider of ICT services supporting critical functions should provide for its participation in testing from the outset. Adding it by amendment under the pressure of an authority’s deadline is the most expensive possible moment to negotiate.
Where should you start, depending on your category of entity?
With an unambiguous determination of your own category, because each one leads to a different first step. The map below joins three things that sit in different places in the Regulation: the status of the entity, the required action and the provision it comes from.
| Category of entity | First step | Basis |
|---|---|---|
| Microenterprise (Article 3(60)) | Selection of tests from the catalogue on a risk basis, without a comprehensive programme | Article 25(1) and (3) |
| Entity other than a microenterprise, not covered by TLPT | Testing programme + inventory of systems supporting critical functions + annual cadence | Article 24(1) and (6) |
| CSD and central counterparty | The above plus vulnerability assessment before any deployment and redeployment | Article 25(2) |
| Entity on the default RTS list | Preparation of the control team and the scope document before the notification arrives | Article 26(2), Article 9 of Reg. 2025/1190 |
| Significant credit institution | As above, assuming external testers only | Article 26(8), second subparagraph |
The third row from the bottom is where time is most often lost. An entity on the default list has no reason to wait for the notification: the scope specification document requires approval by the management body (Article 9(6) of Regulation 2025/1190), and therefore a passage through a decision cycle that cannot be shortened by instruction. The six-month deadline running from the notification is comfortable for those who already have an inventory of critical functions, and very tight for everyone else.
One more thing is worth noting, as it rarely appears in Polish commentary: the TIBER-EU framework, on which the delegated regulation is based (recital 1), was published by the ECB in May 2018 and updated in 2024 for alignment with the TLPT standards. Poland does not appear on the list of jurisdictions that have adopted it — as read from the ECB page on 18 September 2026. That exempts no one from anything, because the obligation flows from the Regulation and not from TIBER-EU, but it does mean that a Polish entity reaches for the TIBER-EU framework as a point of reference rather than as a national procedure.
The trap we see most often: a testing programme built from the tool rather than from the inventory. The list of systems supporting critical or important functions is simultaneously the denominator of the annual obligation under Article 24(6) and of the TLPT scope under Article 26(2). Until it exists, neither of those two things is countable — by the entity or by the authority.
If determining your own category and building that denominator is work nobody currently has capacity for, that is where we start in a DORA readiness and compliance audit. The order is always the same: inventory and category first, then the choice of tests, and TLPT only when the provision or the authority requires it.
