DORA penetration testing, article by article

DORA's testing obligations (Articles 24–26)

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 — has applied since 17 January 2025, and it turns ICT security testing from a good-practice recommendation into a binding legal obligation for EU financial entities and their critical ICT third-party providers. Testing sits under three linked articles, and knowing which one governs a given engagement is the first thing a supervisor will check.

Article 24 sets the general principles for the digital operational resilience testing programme itself — proportionate to the entity's size, risk profile, and the criticality of the ICT systems and services it depends on, with results fed back into the risk-management framework rather than filed away. Article 25 covers testing of ICT tools and systems, and names a range of test types financial entities must run — 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 26 layers advanced threat-led penetration testing (TLPT) on top, but only for the subset of entities their competent authority identifies as in scope for it.

• ✅ Art. 24 — the testing programme's general principles and proportionality
• ✅ Art. 25 — testing of ICT tools and systems, including penetration testing
• ✅ Art. 26 — advanced TLPT, for entities identified by their competent authority

Who is in scope

Scope under DORA is layered, and conflating the two layers is the most common way a testing programme falls short. The general testing programme under Articles 24–25 applies broadly: DORA's financial-entity definition sweeps in banks, payment and e-money institutions, investment firms, insurers, crypto-asset service providers, and a long list of other regulated entities, all of whom must run a documented ICT testing programme covering the tools and systems that support their critical or important functions. TLPT under Article 26 is narrower by design — it applies only to entities that their competent authority has identified, based on factors such as systemic relevance and ICT risk profile, and typically concentrates on larger or more critical firms rather than every regulated entity across the market.

In practice that means most DORA-covered firms need to get Article 25 testing right — a recurring, evidenced programme, not a one-off exercise — well before TLPT designation is ever a question. The management body carries the accountability either way: DORA places ICT-risk ownership at that level, so a testing gap is not a finding for the IT team alone to remediate, it's a governance exposure the board is answerable for.

Annual testing vs threat-led (TLPT)

The two testing tracks differ in cadence, scope, and depth, and a supervisor reviewing your programme will expect you to be able to state the difference in one sentence. Article 25 testing of critical or important ICT systems is expected on a regular, risk-based cadence — for most entities, at least annually — using the mix of methods the article lists, penetration testing among them. It is proportionate: the depth and frequency scale to the entity's size and the criticality of what's being tested, and it's the layer nearly every DORA entity has to satisfy continuously, not episodically.

TLPT under Article 26 is a different exercise entirely: a live, intelligence-led red-team engagement against production systems, run at least every three years for entities identified by their competent authority, and aligned with the TIBER-EU framework— the threat intelligence-based ethical red-teaming approach that gives TLPT its methodology, threat intelligence, and red-team phases. TLPT accreditation and oversight run through national competent authorities per engagement, not through any vendor — a testing platform is aligned with TIBER-EU, and describes itself that way, rather than claiming an accreditation that isn't a vendor's to hold. What a platform can be architected for is alignment: supporting the threat-intelligence, red-team, and reporting phases TIBER-EU defines, and the fact that autonomous AI agents alone cannot deliver a compliant TLPT engagement — the accredited human judgment TIBER-EU requires has to sit in the loop. breachr's model is a hybrid of accredited human testers and agentic-AI testing, architected to support Article 26 engagements rather than to replace the human accreditation TLPT depends on.

Article-mapped, signed evidence

What a DORA testing obligation actually produces, in front of a supervisor or the management body, is evidence — and evidence that requires interpretation before it can be cited against a specific article is evidence that hasn't done its job. breachr maps every finding from an engagement to the DORA article and requirement it addresses, so a report reviewer can trace a result directly to Article 24's programme principles, Article 25's testing scope, or Article 26's TLPT obligation, rather than reconciling a generic pentest report against the regulation by hand.

Every finding also carries a cryptographic chain of custody — who or what performed the test action, a named accredited human tester or an identified AI agent, when, and against which target — so provenance is never in question when it's reviewed. That combination is what the management body needs: not an approval no testing vendor is in a position to grant itself, but evidence built to be read, article by article, by the people who are personally accountable for DORA's ICT-risk requirements.

• ✅ Findings mapped to the specific DORA article and requirement they address
• ✅ A cryptographic chain of custody recording who or what tested, when, and where
• ✅ A single evidence trail the management body can cite without reinterpretation

Related guides