Testing GuideEU

EU DORA Testing & TLPT Readiness

Build a repeatable testing program - and a TLPT capability that is production-safe and audit-ready.

Grounded in DORA Chapter IV and aligned to the ECB's TIBER-EU execution guidance.

Back to main artifact Review sources

Author

Sorena AI

Published

Feb 23, 2026

Updated

Feb 23, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Feb 23, 2026

Updated Feb 23, 2026

Overview

DORA testing is a program, not a penetration test. Chapter IV expects a risk-based resilience testing programme that covers critical or important functions, produces remediation backlog, and validates fixes. For certain entities, DORA requires advanced testing via threat-led penetration testing (TLPT) on live production systems at least every three years. This guide shows how to build the program and evidence model, and how to use the ECB's TIBER-EU framework as an execution handbook.

Section 1

Testing program vs TLPT (how DORA structures testing)

DORA distinguishes a general testing programme (Articles 24-25) from advanced TLPT (Article 26).

Build the programme first; TLPT then becomes a specialized, governed test type within it.

Testing programme: continuous, risk-based testing across ICT systems and processes supporting critical or important functions.
TLPT: advanced, intelligence-led test on live production systems, covering several or all critical or important functions, with authority-validated scope.
Evidence model: both require test reports, remediation tracking, and validation that weaknesses are addressed.

Recommended next step

Turn EU DORA Testing & TLPT Readiness into an operational assessment

Assessment Autopilot can take EU DORA Testing & TLPT Readiness from turning this guidance into a repeatable review process to a reusable workflow inside Sorena. Teams working on EU DORA can keep owners, evidence, and next steps aligned without copying this guide into separate documents.

Assessment workflow

Open Assessment Autopilot for EU DORA Testing & TLPT Readiness

Start from EU DORA Testing & TLPT Readiness and turn the guidance into owned tasks, evidence requests, and review checkpoints.

Explore next step

Talk to Sorena

Talk through EU DORA

Review your current process, evidence gaps, and next steps for EU DORA Testing & TLPT Readiness.

Explore next step

Section 2

Article 24 - Digital operational resilience testing programme (operating model)

Your testing programme should define: what you test, how often, who tests (independence), how you remediate, and how you validate fixes.

Treat tests as inputs to engineering and risk governance, not as compliance PDFs.

Annual testing plan: scope coverage for critical or important functions; include scenario-based and technical tests.
Independence: for non-microenterprises, ensure tests are performed by independent parties (internal or external) and conflicts are avoided.
Remediation governance: prioritize, classify and remedy issues; validate closure with retesting and evidence (Article 24(5)).
Coverage: ensure at least yearly appropriate tests on all ICT systems and applications supporting critical or important functions (Article 24(6)).

Section 3

Article 25 - Testing methods catalogue (make it measurable)

Article 25 lists example test types: vulnerability assessments, open source analyses, network security assessments, gap analyses, physical security reviews, source code reviews, scenario-based tests, end-to-end tests, and penetration testing.

Build a "test catalog" with acceptance criteria and evidence outputs per test type.

Create a test catalog: test type -> objective -> target systems -> cadence -> evidence output -> owner.
Define "critical function coverage": minimum test coverage per critical or important function.
Automate where possible: scanning and continuous controls reduce manual effort and improve cadence.
Link to incident learnings: post-incident reviews should adjust testing scope and priorities.

Section 4

Article 26 - TLPT program readiness (design before you test)

TLPT is high-stakes because it runs on live production systems and mimics sophisticated attackers.

Design the governance and safety controls before you select a vendor or define scope.

Scope definition: identify underlying ICT systems, processes and technologies supporting critical/important functions; decide which functions must be covered; scope validated by competent authorities (Article 26).
Production safety: define guardrails, kill-switches, and comms rules; isolate unacceptable business risks.
Authority interactions: plan timeline for scope validation, approvals, and reporting expectations.
Evidence: TLPT scope documents, approvals, safety plan, test outputs, and remediation validation.

Section 5

RTS 2025/1190: identify whether you are likely to enter the TLPT population

The practical TLPT question is not only how to run a test. It is whether your entity is the kind of entity that competent authorities may identify for TLPT under the RTS.

Use that as an early-readiness filter so you do not wait for a supervisory signal before building governance, procurement criteria, and production-safety controls.

Track your systemic importance, cross-border footprint, and dependency on ICT supporting critical or important functions.
Treat TLPT readiness as a staged capability even if you are not yet formally identified: scope inventories, control-team model, authority interaction plan, and provider due diligence.
If you are likely to enter scope, align early with TIBER-EU so the execution method does not become the bottleneck.

Section 6

Article 27 - Tester requirements (vendor selection acceptance criteria)

DORA sets explicit expectations for TLPT testers: suitability, expertise, independence assurance, and insurance coverage.

Make these requirements procurement gate criteria.

Suitability and reputability; technical and organizational capabilities; specific expertise in threat intelligence, penetration testing and red teaming.
Certification or adherence to formal codes of conduct/ethical frameworks.
Independent assurance or audit report on sound management of TLPT risks and protection of confidential information.
Professional indemnity insurance covering misconduct and negligence.
Internal testers: require authority approval and conflict-of-interest protections; threat intelligence provider must be external.

Section 7

Using TIBER-EU as an execution handbook (practical TLPT implementation)

The ECB's TIBER-EU framework provides a structured, intelligence-led red teaming methodology and roles (blue team, threat intelligence provider, red team testers, control team, and oversight teams).

Use it to implement TLPT with a consistent, controlled process aligned to DORA expectations.

Define roles: blue team vs control team separation; threat intelligence and red team provider governance.
Follow phased execution: threat intelligence -> testing execution -> closure and improvements.
Procurement guidance: use published procurement guidance to select service providers and structure deliverables.
Evidence: keep deliverables by phase (TTI report, attack narratives, findings, remediation plans, retest evidence).

Section 8

Evidence pack checklist (audit-ready testing artifacts)

Testing evidence needs to show: coverage, independence, remediation, and learning.

Use this checklist to ensure outputs are exportable and consistent across entities.

Testing policy + annual testing plan + coverage map for critical/important functions.
Test catalog definitions and evidence outputs per test type.
Remediation and validation artifacts: tickets, retest reports, closure evidence.
TLPT program artifacts (where applicable): scope validation, tester due diligence, safety plan, TLPT reports, remediation and retest evidence.
Linkage to incident management: post-incident reviews driving test plan adjustments.

Primary sources

References and citations

Commission Delegated Regulation (EU) 2025/1190 - TLPT identification criteria (RTS)

eur-lex.europa.eu

Referenced sections

Specifies the criteria used to identify financial entities required to perform threat-led penetration testing.

ECB - TIBER-EU framework (January 2025)

ecb.europa.eu

Referenced sections

ECB execution guidance for threat intelligence-based ethical red teaming, commonly used as a structured TLPT implementation handbook in EU financial sector contexts.

ENISA - Handbook for Cyber Stress Tests (May 2025)

enisa.europa.eu

Referenced sections