The decision this guide helps you make
Choose the engagement from the obligation and decision you need to address. A conventional pentest examines an agreed technical scope; DORA TLPT adds a defined authority process, threat intelligence, critical-function scope and formal closure. An organisation may need both for different purposes.
For the engagement owner. Use the objective, governance and coverage model to distinguish the engagements. A technical finding can inform a TLPT without making its originating assessment a TLPT.
The difference is the question being tested
A conventional penetration test typically examines weaknesses in a defined technical scope. A threat-led penetration test asks a broader question: how would a credible adversary affect the organisation’s critical functions, and how would its people, processes and technology respond?
The distinction is more than duration or intensity. DORA TLPT has an authority process, targeted threat intelligence, requirements for testers, a scope tied to critical or important functions and formal closure work. Calling an exercise “red teaming” does not establish that these requirements were met.
Read diagram text
- Technical assessment
- Evaluate defined systems and controls
- Threat-led exercise
- Follow credible paths to function impact
- Governance
- Apply the required delivery process
Compare the engagement models
| Dimension | Conventional penetration test | DORA TLPT |
|---|---|---|
| Starting point | Often a technical asset list or defined application scope. | Critical functions, relevant threats and authority-validated scope. |
| Threat basis | May use standard techniques and a general attacker model. | Targeted threat intelligence informs realistic scenarios. |
| Environment | Depends on the agreed assignment. | Relevant critical live production systems. |
| Defensive capability | May be outside the test objective. | Prevention, detection and response form part of the learning. |
| Governance | Defined by the engagement and relevant standards. | DORA, RTS, authority involvement and specific participant roles. |
| Closure | Usually a technical report and agreed follow-up. | Red/blue reporting, replay, purple teaming, summary and remediation process. |
Why organisations may need both
DORA’s general testing programme and its advanced TLPT obligation serve related but different purposes. Routine technical testing can identify weaknesses before they become part of a broader attack path. TLPT can then show whether layers of controls work together under realistic conditions.
Finding a large number of vulnerabilities does not make a test equivalent to TLPT. Equally, a threat-led exercise is not intended to exhaustively inspect every asset for every possible flaw. The objectives and evidence requirements need to remain clear.
Read diagram text
- API finding
- A specific permission failed
- Threat-led observation
- A scenario exposed a resilience issue
- Untested surface
- No conclusion from absent coverage
Avoid the procurement mismatch
A procurement brief that simply requests a “DORA pentest” is ambiguous. One supplier may price a short application assessment while another assumes a multi-stage TLPT with threat intelligence and extensive closure obligations.
Specify whether the entity has been identified for TLPT, which authority is involved, the likely critical functions, the testing window and the expected deliverables. Ask suppliers to explain how their approach maps to the relevant requirements. Compare equivalent scope, resource and governance assumptions.
Do not buy a test solely because its proposal uses the right acronym. Verify the proposed team and evidence against Article 27, and agree operational safeguards before any testing starts.
Read diagram text
- Starting position
- Access, assistance and assumptions
- Observed activity
- Actions and defensive response
- Limitations
- Unattempted paths and excluded systems
Recognise a useful preparation assessment
A bank preparing for an advanced exercise may commission a focused review of a payment API, privileged access route or deployment pipeline. That work can identify weaknesses, improve scope knowledge and clarify operational safeguards. Record it as a separate assessment with its own starting positions and limitations. Its results may inform preparation, but they do not replace threat intelligence, authority coordination or the other elements of the applicable TLPT process.
Our bank penetration testing comparison turns this distinction into procurement questions. It helps a commissioning team explain whether it needs coverage of a defined technical surface or a broader assessment of a critical function against a credible threat.
Ask what each result actually establishes
An API test may demonstrate that a synthetic customer can perform an unauthorised transaction state change. A threat-led exercise may examine how an adversary could reach a consequential objective and how the organisation detects and responds along the way. Both observations can matter, but neither implies comprehensive coverage of the other question. A report should connect its conclusion to the tested starting position, actions and observations, with untested consequences labelled as such.
For products delivered through multiple APIs and service providers, the fintech API scope guide provides practical inputs for the technical part of that map. The entity must still determine the appropriate TLPT scope and governance through the relevant process. Use clear engagement names in the procurement brief, evidence register and management reporting so those responsibilities remain visible.
Read diagram text
- Name the objective
- Identify the decision the exercise informs
- Separate preparation
- Record focused assessments distinctly
- Agree the process
- Resolve scope and governance obligations
Continue your preparation
Primary sources
- DORA · Regulation (EU) 2022/2554
- TLPT RTS · Delegated Regulation (EU) 2025/1190
- ECB · TIBER-EU framework and guidance
General information, not legal advice. Confirm the applicable requirements and test arrangements with your relevant authority.
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.
