By requirement
What DORA actually asks of your security testing
DORA makes resilience testing a legal duty for EU financial entities. Here is what Articles 24 to 27 and the TLPT technical standards require, and how red-team testing aligned to TIBER-EU supports that work.
What it asks for
What DORA says about testing
Chapter IV (Articles 24 to 27) requires financial entities other than microenterprises to establish, maintain and review a sound and comprehensive digital operational resilience testing programme as part of their ICT risk-management framework. It must be risk-based, use independent testers, internal or external, and include procedures to prioritise, classify and remedy every issue found, with internal validation that weaknesses are fully addressed. At least yearly, appropriate tests must cover all ICT systems and applications supporting critical or important functions. Article 25 lists suitable tests, from vulnerability scans and network security assessments to source code reviews, scenario-based tests and penetration testing.
Article 26 adds threat-led penetration testing (TLPT) for entities identified by their competent authority: at least every three years, covering several or all critical or important functions, on live production systems, with the scope validated by the authority and relevant ICT third-party providers included. Delegated Regulation (EU) 2025/1190, drafted in accordance with TIBER-EU, sets out the process: a control team, at least three threat-led scenarios, an active red-team phase of at least 12 weeks, replay and purple teaming, remediation plans and an attestation from the authority.
Art. 24(1)-(4) – Testing programme and independence
Non-microenterprise entities need a documented, risk-based testing programme within their ICT risk-management framework. Tests must be run by independent parties, internal or external, with conflicts of interest avoided in design and execution.
Art. 24(5)-(6) – Remediation and yearly testing
Every issue found must be prioritised, classified and remedied, with internal validation that it is fully addressed. At least yearly, appropriate tests must cover all ICT systems and applications supporting critical or important functions.
Art. 25 – Testing of ICT tools and systems
Lists appropriate tests, including vulnerability scans, network security assessments, source code reviews where feasible, scenario-based tests and penetration testing. Central securities depositories and central counterparties must also assess vulnerabilities before deploying or redeploying relevant components.
Art. 26 – Advanced testing based on TLPT
Entities identified by their competent authority must carry out TLPT at least every three years on live production systems supporting critical or important functions. The authority validates the scope and, at the end, issues an attestation.
Art. 27 – Requirements for testers
TLPT testers must be of the highest suitability and reputability, show expertise in threat intelligence, penetration testing and red teaming, be certified or follow formal codes of conduct, provide independent assurance and hold professional indemnity insurance.
Delegated Regulation (EU) 2025/1190 – TLPT RTS
Specifies who must perform TLPT and how: preparation and scoping, targeted threat intelligence with at least three scenarios, an active red-team phase of at least 12 weeks, closure with replay and purple teaming, then remediation plans.
What to test
What a DORA-aligned test should cover
Critical or important functions
Start from your inventory of critical or important functions and map the ICT systems, applications and processes behind each. Yearly testing must reach all of them, not only the internet-facing estate.
Third-party and outsourced services
Where ICT third-party providers support critical or important functions, plan how they take part. For TLPT, Article 26(3) requires you to secure their participation while you keep full responsibility for compliance.
A risk-based mix of test types
Article 25 expects a range of tests chosen by risk: vulnerability scanning, network and application penetration testing, source code review where feasible and scenario-based tests. A single external scan is unlikely to meet that range.
Detection and response
TLPT tests people, processes and technology on live production systems. Outside TLPT, scenario-based red-team or purple-team exercises show whether your detection and response would catch a realistic attacker.
What you receive
What PXL delivers and how it supports your evidence
Reports mapped to your programme
Each report records scope, methodology, dates, testers and findings, referenced to the critical or important functions and systems in your testing programme, so it fits directly into your Article 24 records.
Prioritised, classified findings
Findings carry severity, affected assets, evidence and remediation guidance, giving your own procedures the input they need to prioritise, classify and remedy issues as Article 24(5) expects.
Retesting and closure evidence
We retest fixes and confirm closure in writing, supporting the internal validation you need to show that identified weaknesses, deficiencies or gaps have been fully addressed.
TIBER-EU-aligned red teaming
We deliver red-team testing aligned to TIBER-EU and support TLPT preparation, from scenario-based exercises to purple teaming. Whether a provider is suitable for your TLPT is decided by your control team and TLPT authority.
Common pitfalls
Common mistakes
Mistakes that cost time at audit, and how to avoid them.
Treating TLPT as the whole programme
TLPT applies only to entities identified by their authority. Every other non-microenterprise entity still needs the Article 24 programme and yearly testing of systems supporting critical or important functions.
Testing without a function map
Without a current map of critical or important functions to systems and providers, scope becomes guesswork. Gaps then appear where supervisors tend to look, such as outsourced or shared infrastructure.
Findings that never close
Article 24(5) requires remediation and internal validation, not just a report. Untracked findings, undocumented risk acceptances and no retest leave your programme hard to evidence.
Weak independence
Using testers who built or operate the systems under test creates the conflicts of interest Article 24(4) asks you to avoid. Record how independence was ensured for every test.
Who decides what counts
PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice.
FAQ
Questions we're often asked
Does every financial entity have to do TLPT?
No. TLPT under Article 26 applies only to financial entities identified by their competent or TLPT authority, using the criteria in Article 26(8) and Delegated Regulation (EU) 2025/1190. Microenterprises and entities under the simplified ICT risk-management framework are excluded. Other in-scope entities still need the general testing programme in Article 24.
How does TIBER-EU relate to DORA TLPT?
The TLPT technical standards were drafted in accordance with TIBER-EU and mirror its methodology, process and structure. The ECB states that TIBER-EU was updated to align fully with those standards. Entities may apply TIBER-EU, or a national implementation of it, in so far as it is consistent with DORA and the standards.
Can PXL carry out our TLPT?
PXL delivers red-team testing aligned to TIBER-EU and supports TLPT preparation. We do not claim accreditation under any national TIBER or TLPT scheme. Your control team must assess any tester against Article 27 of DORA and Article 7 of the TLPT standards, and the TLPT authority can object before a provider is contracted.
Can we use internal testers?
For general testing, Article 24 allows internal or external testers provided they are independent and conflicts of interest are avoided. For TLPT, internal testers need authority approval and an external threat intelligence provider, and external testers must be used every three tests. Significant credit institutions may only use external testers for TLPT.
Is PXL an auditor or regulator?
No. PXL is a security testing firm. We do not audit, certify or attest DORA compliance, and under DORA the TLPT attestation is issued by the authority. Our reports are evidence you can use in your own compliance work and in dialogue with your supervisor.
Is this legal advice?
No. This page is general guidance on the testing provisions of DORA and its technical standards, based on the official texts. How DORA applies to you depends on your entity type, size and supervisor, so confirm your obligations with your legal and compliance advisers and your competent authority.
Services that deliver this
Scope your DORA & TLPT test.
Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.