DORA penetration testing requirements beyond TLPT — the Article 24–25 testing programme

Chapter IV of Regulation (EU) 2022/2554 builds testing in two tiers.

• The testing programme (Arts. 24 and 25) applies to financial entities other than microenterprises. Microenterprises also test, but under Art. 25(3) they combine a risk-based approach with strategic planning, balancing the resources spent against the urgency and type of risk.
• Threat-led penetration testing (Arts. 26 and 27) applies only to financial entities that the competent authorities identify, on the basis of their impact, systemic character and ICT risk profile. Microenterprises and the entities under the simplified ICT risk framework of Art. 16(1) are excluded. Designated entities run a TLPT at least every three years.

Most banks, insurers, investment firms, payment and e-money institutions will never receive a TLPT notification. None of them is exempt from the first tier, and the first tier is where supervisors look at whether testing is regular, covers the critical or important functions, and actually leads to remediation. For the second tier, see TLPT under DORA Art. 26 and the DORA TLPT engagement playbook.

Article 24 sets the frame. The programme must be:

1. Sound and comprehensive, part of the ICT risk-management framework of Art. 6, for assessing preparedness for ICT-related incidents, identifying weaknesses, deficiencies and gaps, and promptly implementing corrective measures (Art. 24(1)).
2. A range of assessments, tests, methodologies, practices and tools, applied under Arts. 25 and 26 (Art. 24(2)).
3. Risk-based, considering the evolving ICT risk landscape, the specific risks of the entity, and the criticality of information assets and services (Art. 24(3)).
4. Run by independent parties, internal or external. Internal testers need sufficient resources and the avoidance of conflicts of interest throughout design and execution (Art. 24(4)).
5. Tied to remediation: procedures and policies to prioritize, classify and remedy all issues found, and internal validation methodologies to confirm that every weakness is fully addressed (Art. 24(5)).
6. Annual on what matters: at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions (Art. 24(6)).

Article 25(1) lists the tests the programme provides for, in accordance with the proportionality criteria of Art. 4(2): 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. Article 25(2) adds one explicit trigger: central securities depositories and central counterparties perform vulnerability assessments before any deployment or redeployment of new or existing applications, infrastructure components and ICT services supporting critical or important functions.

Commission Delegated Regulation (EU) 2024/1774, the RTS on the ICT risk-management framework, adds operational detail that feeds the testing programme.

• Weekly scanning (Art. 10(2)): vulnerability management procedures must ensure automated vulnerability scanning and assessments on ICT assets, with frequency and scope commensurate to their classification and risk profile, and at least weekly for ICT assets supporting critical or important functions. The same article requires tracking third-party and open-source libraries, prioritizing patches by criticality and asset risk, monitoring and verifying remediation, and recording every detected vulnerability until it is resolved.
• Code and package testing (Art. 16): the acquisition, development and maintenance procedure includes source code reviews covering both static and dynamic testing, security testing of internet-exposed systems and applications, security testing of software packages no later than the integration phase, and, where feasible, analysis and testing of third-party and open-source code before it reaches production.
• Simplified framework (Art. 36): entities under Art. 16(1) of DORA establish an ICT security testing plan that validates the effectiveness of their security measures, and update those measures without undue delay after tests on systems supporting critical or important functions.

The weekly scan is the most concrete frequency in the whole DORA testing stack, and it sits in the risk-management RTS rather than in Articles 24 and 25. It is often missed by teams that plan only around the annual test.

Read strictly, Article 25(1) lists penetration testing as one of the tests the programme provides for, “such as”, and Article 24(6) requires “appropriate tests” on critical or important systems at least yearly. The regulation does not say that every system must be penetration tested every year.

In practice the room for leaving it out is small. The programme's stated purpose is to identify weaknesses and gaps (Art. 24(1)). A vulnerability scan tells you what is missing; it does not tell you whether an attacker can use it to reach a critical function. For an internet-facing service, a remote-access gateway or the identity infrastructure behind a critical function, it is difficult to argue that scans alone are the appropriate test. The defensible position is to write down, per critical or important function, which test types you apply and why, and to include penetration testing wherever the question is exploitability. If you choose a lighter test for a system, record the reasoning; the programme is risk-based, and a reasoned choice is what the text asks for.

A programme that holds up in supervision usually has:

• A map from critical or important functions to ICT systems and applications, including those outsourced to ICT third-party service providers. Art. 24(6) is measured against this list, so every system on it needs at least one appropriate test each year.
• A test matrix per system: weekly automated scanning (RTS Art. 10), vulnerability assessment and network security assessment, penetration testing from outside and from inside with the access of a standard user, source code review for in-house and customized code where feasible, scenario-based and end-to-end tests for the functions themselves.
• Independence on record: who tested, whether internal or external, how conflicts of interest were avoided, and what resources were dedicated (Art. 24(4)).
• A findings register: classification, priority, owner, target date, remediation, and a validation step that confirms the fix (Art. 24(5)). A finding closes when the re-test passes, not when the ticket does.
• Triggers outside the calendar: major changes, new internet-facing services and, for CSDs and CCPs, every deployment or redeployment on critical functions (Art. 25(2)).

Keep the black-box and gray-box distinction explicit in the matrix; see black-box vs gray-box testing. An inside-out test is what shows whether segmentation around a critical function holds when one workstation is compromised.

Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025, published on 18 June 2025, is the RTS on TLPT. It sets the criteria authorities use and a default list of entities they require to perform TLPT unless the assessment shows it is not justified: credit institutions that are G-SIIs or O-SIIs or part of one, payment institutions and e-money institutions above EUR 150 billion of payment transactions in each of the two previous years (or, for e-money institutions, EUR 40 billion of outstanding e-money), central securities depositories, central counterparties, trading venues with the largest national or a significant EU market share, and certain insurance and reinsurance undertakings (Art. 2).

The features that separate TLPT from any internal testing:

• Live production systems supporting several or all critical or important functions, with a scope validated by the authority (DORA Art. 26(2)).
• Threat intelligence-led scenarios from a threat intelligence provider that must be external to the financial entity, even when internal testers are used (DORA Art. 27(2)(c)).
• Testers: external testers meeting Art. 27(1), or internal testers only with the authority's approval, sufficient resources and no conflicts of interest; an entity using internal testers must contract external testers every three tests, and significant credit institutions under the SSM must use external testers only (DORA Art. 26(8) and 27(2)). According to the RTS recitals, a team mixing internal and external testers counts as a test with internal testers.
• An active red team phase of at least 12 weeks, then a replay and a purple teaming exercise with the blue team within 10 weeks of its end (RTS Arts. 11(5) and 12(5)).
• An attestation from the authority after the summary of findings and remediation plans (DORA Art. 26(6) and (7)).

No tool, however autonomous, turns internal testing into a TLPT. What internal testing can do is make sure the TLPT is spent on the right questions.

Twelve weeks of threat-led red teaming is expensive. If the external team gets in through an unpatched edge device or a default credential that a weekly scan could have found, the test proves something you already should have known, and the detection and response questions TLPT is designed to answer get less time.

Continuous internal testing in the months before a TLPT closes that gap:

• Clear the known-exploitable paths first. Validate which findings are really exploitable on the systems that will be in TLPT scope, fix them, and re-test.
• Test the inside, not only the perimeter. TLPT scenarios usually assume an initial foothold; gray-box campaigns from a standard user account show how far lateral movement goes today.
• Rehearse the evidence. The remediation plans and findings summaries that TLPT closure requires are easier to produce if the organization already runs a findings register with validation under Art. 24(5).
• Keep the blue team honest. Knowing that internal testing runs on a schedule is not the same as knowing whether the SOC detects it; compare what was tested with what was alerted.

The same work covers the Art. 24(6) annual test for entities that are never designated, so it is not wasted if the TLPT notification never comes.

An autonomous AI red team for networks and infrastructure is not a TLPT provider, does not supply threat intelligence, and does not make your internal team independent in the sense of Art. 24(4); resources and conflict-of-interest controls remain yours to document. It gives you a way to run and evidence much of the Art. 24–25 programme between external engagements.

• Scheduled and change-driven campaigns in black-box mode from outside and gray-box mode with standard-user access, on the systems that support critical or important functions.
• Findings proven exploitable, which is the input Art. 24(5) prioritization needs, and re-tests on demand as the validation step that closes each finding.
• Framework mapping of results to DORA (Arts. 24 to 27) and TIBER-EU controls, among the 34 frameworks the engine supports, with exportable compliance reports.
• Human approval of risky steps: five autonomy levels define what waits for an operator, and exploit proofs of concept can be held for review. On production systems supporting critical functions this is the control that keeps testing from becoming the incident; see human in the loop.
• Evidence integrity: every attack attempt is an Ed25519-signed entry in a SHA-256 hash chain per campaign, verifiable offline, and reports and bundles are signed.
• No customer data leaves the appliance: the models run on the appliance with no external AI service, so findings about your critical systems are not sent to an outside AI provider. See on-premise AI red team.

• Regulation (EU) 2022/2554 (DORA), Arts. 16 and 24 to 27 (EUR-Lex)
• Commission Delegated Regulation (EU) 2024/1774, RTS on the ICT risk-management framework, Arts. 10, 16 and 36 (EUR-Lex)
• Commission Delegated Regulation (EU) 2025/1190, RTS on threat-led penetration testing (EUR-Lex)