For the engagement owner. Commission the test that answers your decision. Routine penetration testing and statutory DORA TLPT have different coverage, governance and evidence requirements.
Begin with the decision you need
An organisation may need assurance on a new application, an internal trust path or a sensitive approval workflow. A scoped penetration test can answer those technical questions. Statutory DORA TLPT is an advanced intelligence-led exercise with a defined governance and authority process for identified financial entities; it is not a universal requirement for every enterprise.
Read diagram text
- Technical question
- Does a defined control work?
- Threat-led question
- How could a function be affected?
- Commissioning
- Agree the matching delivery model
Do not equate the deliverables
DORA Articles 26 and 27 and the TLPT RTS govern advanced testing and tester requirements. A conventional technical report does not become a compliant TLPT because its title uses the acronym. Confirm designation, scope validation and expected outputs with the applicable authority process.

Use the evidence for the right purpose
An application finding may feed the organisation’s vulnerability and risk programme. A TLPT also evaluates realistic attack paths and defender response across critical functions. These forms of testing can complement each other, but they should not be sold or recorded as interchangeable.
Read diagram text
- Routine organisation pentest
- Defined technical scope and evidence
- DORA TLPT
- Threat-led scope and authority process
- Preparation work
- Separate objectives and limitations
Write the distinction into procurement
State the purpose, environment, method, participants and reporting obligations in the request for proposal. Ask what is included in closure and retesting. Our service focuses on agreed penetration-testing scope. Financial entities assessing a DORA TLPT requirement need a separate applicability, governance and delivery assessment.
Read diagram text
- Starting point
- Access and assistance required
- Governance
- Owners, permissions and coordination
- Deliverables
- Evidence, reporting and closure work
Write the commissioning decision in one sentence
A organisation might need evidence that a new customer API enforces customer ownership before release. Another engagement might need to assess how a credible adversary could affect a critical function and how the defenders respond. Those are different questions even when some techniques overlap. Put the decision in the first paragraph of the brief, identify the responsible business owner and explain the intended use of the results. This helps suppliers avoid pricing fundamentally different services under the same testing label.
If the entity is subject to a TLPT requirement, involve the relevant internal governance and authority process early. A supplier's marketing description cannot establish regulatory applicability, approve a scope or replace the financial entity's responsibilities.
Keep preparation work distinct from the advanced test
Targeted application, identity or network assessments can identify weaknesses that deserve treatment before a larger exercise. Describe them as those assessments, with their own boundaries and limitations. Do not relabel a short technical engagement as TLPT because it references a threat actor or includes a polished attack diagram. Conversely, do not assume that a threat-led exercise exhaustively tests every application endpoint. The coverage model and the decision being informed differ.
For the detailed distinction, see DORA TLPT versus penetration testing. The related fintech testing requirements guide explains why payment technology, card-data scope and legal entity status also need to be separated.
Compare proposals by assumptions and deliverables
Request a clear starting position, testing environment, scope rationale, permission model and deliverable list. For routine testing, ask how the provider will establish reproducible findings and retest the agreed controls. For TLPT, ask for the delivery model and responsibilities appropriate to the applicable framework and authority arrangements. Keep missing inputs visible: supplier participation, critical-function mapping and internal coordination can materially affect the work.
A procurement comparison should show what each proposal actually covers and what remains outside it. Neither a larger day count nor a familiar acronym resolves a mismatch. The right output is a statement of work that your operational, technical and governance owners interpret in the same way.
Read diagram text
- Name the question
- State the decision the test informs
- Confirm applicability
- Use the responsible governance process
- Compare equivalent work
- Align scope, evidence and closure
Put the guidance to work
Use the readiness checklist to document assumptions, or inspect the fictional Meridian Group AG report for evidence and treatment-plan examples. Contact Atlant Security with a non-sensitive description of your scope.
Primary sources
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
Published by Atlant Security. Sources, editorial policy and corrections.

