DORA Penetration Testing: Ordinary Testing, TLPT, and How to Define Scope

DORA creates two materially different buying decisions. One is an ordinary, risk-based test within a digital operational resilience programme. The other is a much larger threat-led penetration test (TLPT) overseen by an authority. The two can share techniques, but they differ in purpose, scope, governance, duration and evidence. A supplier therefore cannot price “DORA pentesting” responsibly until the required engagement is clear.

This guide is educational procurement guidance for financial entities and the teams that support them. It does not decide whether DORA applies to a particular organisation or whether an entity has been designated for TLPT. Confirm those questions with the competent authority and qualified legal counsel. A conventional pentest can support DORA testing, but it does not by itself satisfy every DORA obligation and should never be sold as certification.

Start with the testing track, not a vendor label

DORA has two related testing layers. Under Article 24, financial entities other than microenterprises maintain a risk-based digital operational resilience testing programme. At least yearly, appropriate tests must cover all ICT systems and applications supporting critical or important functions. Article 25 lists many possible methods, including vulnerability assessments, source-code reviews, scenario tests, end-to-end tests and penetration testing. It does not say that every system needs an annual pentest.

TLPT is the advanced layer under Articles 26 and 27. It applies to financial entities identified by the relevant authority under the regulatory criteria. The mandatory TLPT population excludes microenterprises and the entities addressed by the first subparagraph of Article 16(1). A designated entity ordinarily performs TLPT at least every three years, although its authority may shorten or lengthen that interval based on risk profile and operational circumstances. The test covers several or all critical or important functions and exercises live production systems through threat-intelligence-led red teaming.

The first procurement artefact should therefore be a short applicability memo: the legal entity, regulator, critical or important functions, TLPT designation status and the exact decision the test must support.

Build scope from critical or important functions

An IP list is an output of scoping, not its starting point. Begin with the functions whose disruption could materially harm financial performance, service continuity or ongoing compliance with authorisation conditions. For each function, map the business service, process owners, user journeys, supporting applications, identities, infrastructure, data flows, recovery dependencies and ICT third parties. Record where each dependency runs and who can authorise testing.

For ordinary risk-based testing, this map supports a defensible choice of technique. An internet-facing customer portal may justify authenticated application testing; an identity platform may need configuration review plus attack-path testing; a settlement workflow may need scenario and end-to-end checks. To make the annual coverage requirement auditable, record which method covered each system in the current cycle, what changed, and any permitted limitation. A mandatory coverage gap should be escalated; documenting risk acceptance does not waive the requirement.

For TLPT, function mapping becomes a formal scope specification. The entity identifies the critical or important functions proposed for inclusion and the supporting ICT systems, processes, technologies and services. The TLPT authority validates the precise scope. Excluded functions need reasons; included systems need preliminary objectives, or “flags”, tied to confidentiality, integrity, authenticity or availability. A buyer should not let a provider turn this into a perimeter inventory.

The audit-readiness guide shows how to connect controls, systems and test evidence without attributing an auditor’s conclusion to the test.

Treat live testing as a managed operational change

TLPT deliberately exercises live production systems supporting critical or important functions. That creates information value that staging cannot reproduce, but also real operational risk: service interruption, system damage, corrupt or disclosed data, false incident escalation and effects on counterparties. “Be careful” is not an adequate control.

The control team should maintain a live risk register and decision log. Before testing, agree allowed and prohibited tactics, social-engineering boundaries, target windows, test accounts and data, restoration checks, evidence handling, escalation paths and emergency contacts. Define measurable stop conditions: a production error-rate threshold, an unexpected data write, a safety concern, a third-party alert or an incident that the entity cannot confidently distinguish from the exercise. Assign who may pause the test and how the authority and providers are informed.

Secrecy is a control too. A small control team knows about the exercise and manages it; the blue team normally does not, so its real prevention, detection and response behaviour can be observed. The control-team lead needs enough seniority and system knowledge to balance realism with safety. Keep an out-of-band channel for the testers and control team, and rehearse the stop process before active testing begins.

A conventional production pentest should adopt the same discipline in proportion to risk, even when the TLPT rules do not apply. Written authorisation, rules of engagement, data handling and restoration evidence make the work safer and the result easier to rely on.

Procure capability and independence, not a DORA badge

DORA sets specific criteria for TLPT testers: suitability and reputation; technical and organisational capability; expertise across threat intelligence, penetration testing and red teaming; certification by an accreditation body in a Member State or adherence to formal codes of conduct or ethical frameworks; independent assurance over risk management; and professional indemnity insurance. Contracts with external testers must also control the creation, storage, aggregation, reporting, communication and destruction of test data.

These are due-diligence subjects, not marketing phrases. Ask for the named delivery team, relevant roles, how threat intelligence and red-team work are separated when supplied by one company, evidence of insurance, quality controls, conflict checks, subcontractors, data locations and secure deletion. Ask who can make operational decisions at 03:00 during an active scenario. Verify claims rather than accepting an “approved DORA provider” badge. There is no safe basis for assuming that a familiar pentest supplier automatically has the governance and intelligence-led red-team capability required for TLPT.

Internal testers are possible only within the applicable approval and independence conditions. The threat-intelligence provider remains external to both the entity and its ICT intra-group providers, significant credit institutions must use external testers, and an entity using internal testers must use external testers for at least one of every three TLPTs. A mixed internal-external testing team counts as internal for that rotation rule. Ordinary Article 24 testing also requires independence, whether testers are internal or external, and internal testing needs resources and conflict controls.

Before selection, compare an anonymised report sample against your acceptance criteria. The sample pentest report is useful for judging whether a conventional technical report explains evidence, impact and remediation. A TLPT procurement needs further deliverables: threat intelligence, attack scenarios, red- and blue-team reports, replay material, a summary and a remediation plan.

Bring ICT third parties into the design early

A critical function often crosses cloud, SaaS, managed security and group-service boundaries. DORA does not let the financial entity erase those dependencies from scope. It must identify outsourced systems and ICT services that support critical or important functions, take safeguards to secure relevant third-party participation, and retain responsibility for compliance.

Start with contracts. Check testing rights, notice periods, acceptable-use limits, subcontractor dependencies, evidence-sharing restrictions, incident routes and data-location constraints. If a provider cannot support production testing, the gap needs an authority-visible decision rather than a quiet exclusion. A third-party risk assessment can prepare this evidence, although questionnaires alone cannot demonstrate how shared controls behave during an attack.

Pooled TLPT is a narrow mechanism, not a blanket way to keep a provider out of testing. DORA permits it where direct participation is reasonably expected to harm services for non-DORA customers or the confidentiality of their data. With the required written agreement, the ICT provider can contract directly with an external tester, one financial entity directs the pooled exercise, and participation is calibrated to preserve test quality. Each financial entity still carries its own obligations and risk management. Joint TLPT may also be considered where group entities share ICT systems or an intra-group provider.

Plan TLPT as an end-to-end programme

The active red-team phase must span at least twelve weeks under the TLPT regulatory technical standard. This is a minimum phase duration, not a promise of continuous hands-on activity, a fixed number of person-weeks or a twelve-week timetable for the whole project. Preparation, scope validation, threat intelligence, closure and remediation add substantial time. After the authority notifies the entity, initiation information is due within three months. Procurement should therefore begin before calendars become critical, while respecting the formal start and authority process.

1. Initiate and scopeEstablish the control team, providers, risk controls, functions, systems and flags; obtain required authority validation
2. Build threat scenariosUse targeted intelligence to select realistic actors, attack paths and objectives for the agreed scope
3. Test live systemsRun a controlled active red-team phase spanning at least twelve weeks, with weekly progress reports and documented changes
4. Replay and learnProduce red- and blue-team reports, reconstruct offensive and defensive actions, then conduct purple teaming
5. Remediate and attestSubmit the summary and remediation plan, track owners and dates, and retain the authority attestation for mutual recognition

The workflow is designed to test more than exploitability. The control-team lead selects at least three scenarios informed by targeted threat intelligence and the required expert input. The red team tests entry, movement and action on objectives; the blue team’s evidence shows which actions were detected and how it responded. “Leg-ups” can help testers continue where progress stalls, but should be agreed and recorded because they change how the result is interpreted.

When active testing ends, the red team reports, the blue team maps detections and evidence, and both sides replay the sequence. Purple teaming then explores alternative or incomplete paths collaboratively. This is where a failed intrusion can still reveal weak telemetry, and a successful intrusion can expose a control that worked later than expected. The result is a learning record, not a pass/fail badge.

Accept evidence that supports remediation

Define acceptance before signing. For an ordinary pentest, require a confirmed scope, test dates and environment, methods and limitations, reproducible evidence, affected function, business consequence, remediation advice and a retest convention. Keep findings traceable to the systems and critical-function map rather than flattening everything into severity scores.

For TLPT, the evidence chain is broader. The red-team report should distinguish reached and unreached flags, successful and unsuccessful attack paths, tactics used, deviations and any leg-ups. The blue-team report maps detections and logs to each attack step, includes its own root-cause analysis and names purple-team topics. The summary then links the validated scope, scenarios, actions, detections, risk controls and lessons.

The remediation plan should give each finding a shortcoming, prioritised action, expected completion, root cause, accountable owner and risk of delay or of the remediation itself. Within the regulatory timetable, the eight-week period for the summary and remediation plan begins when the TLPT authority notifies the control-team lead that the red- and blue-team reports contain the required information. It does not run from the start of the test.

Retesting is how a technical claim becomes closure evidence. It should reproduce the original condition where safe, test relevant adjacent paths and record the environment, date and outcome. The remediation-validation guide explains how to distinguish “patched” from “verified”. An authority attestation supports mutual recognition of a properly conducted TLPT; it is not certification of the entity’s overall security or an endorsement of every control.

A hypothetical buying decision

Consider a hypothetical payment institution whose critical payment function depends on a customer API, cloud identity, a managed detection service and an outsourced transaction processor. It has confirmed its applicability and designation position with its competent authority and legal team and is not currently designated for TLPT. Its annual testing programme shows that the API changed substantially, identity privileges expanded and the processor contract limits intrusive testing.

The defensible purchase is not automatically a full TLPT. The entity could commission authenticated API and identity attack-path testing, review the processor evidence and contract limits, and run a scenario exercise across incident hand-offs. The scope memo records why those methods are appropriate this year and how every supporting system is covered across the programme. If the authority later designates the entity for TLPT, that function map and third-party groundwork become inputs to a different, authority-governed project; the earlier pentest does not transform into TLPT retroactively.

For a conventional technical engagement, Pentest.red can help turn that decision into an agreed penetration-testing service scope: authorised targets, access level, production safeguards, evidence and retest terms. The scope planner helps capture those boundaries before pricing. Pentest.red does not certify DORA compliance or claim that an ordinary pentest replaces TLPT. Confirm regulatory applicability and any TLPT programme with the competent authority and legal team, then buy the technical work that answers the remaining, clearly stated question.