Authorised testing. Evidence that matters.Atlant Security
Pentest/ServicesBY ATLANT SECURITY
Build your scope Free brief builder

Requirements

Penetration testing or DORA TLPT: which engagement do you need?

Separate a defined technical test from advanced testing obligations that apply to designated financial entities.

Discuss your requirements
Illustrative enterprise infrastructure and controlled service dependencies

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.

Choose the test from the decision. Technical question: Does a defined control work?; Threat-led question: How could a function be affected?; Commissioning: Agree the matching delivery model
Working model 01Choose the test from the decisionIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

Illustrative enterprise technology operations floor overlooking a city
Operational perspectiveConnect each test result to the people and services that depend on it.Generated illustrative setting; not a client location.

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.

Different coverage models. Routine organisation pentest: Defined technical scope and evidence; DORA TLPT: Threat-led scope and authority process; Preparation work: Separate objectives and limitations
Working model 02Different coverage modelsIllustrative planning diagram. Adapt the decisions to your authorised scope.
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 the proposal assumptions. Starting point: Access and assistance required; Governance: Owners, permissions and coordination; Deliverables: Evidence, reporting and closure work
Working model 03Read the proposal assumptionsIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

Remove ambiguity before procurement. Name the question: State the decision the test informs; Confirm applicability: Use the responsible governance process; Compare equivalent work: Align scope, evidence and closure
Working model 04Remove ambiguity before procurementIllustrative planning diagram. Adapt the decisions to your authorised scope.
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.

PUT THE GUIDANCE TO WORK

Choose your next step.

LET’S START A CONVERSATION

Define the scope.
Take the next step.

Your systems, operating constraints and security objectives. A clear starting point for the test.

Discuss your pentest