Why does DORA require threat-led penetration testing instead of a standard vulnerability assessment?

DORA uses threat-led testing because compliance is not just about finding flaws. It is about proving the organisation can withstand, respond to, and recover from realistic ICT disruption. By simulating real adversary behaviour, including external attack paths and social engineering, TLPT measures whether controls work under conditions that resemble a live attack.

Why threat-led testing is different from finding vulnerabilities

DORA treats resilience as something you have to prove under realistic attack conditions, not just document through scan results. A vulnerability assessment can tell you what is weak; threat-led penetration testing asks whether those weaknesses can actually be chained into a disruptive scenario, whether defenders notice, and whether the organisation can sustain critical services while responding.

That distinction matters because operational resilience is about the whole attack path, including authentication abuse, privilege misuse, lateral movement, and recovery constraints. A technically accurate list of flaws does not show whether your controls hold up when an adversary behaves like an adversary.

For firms in scope, the regulatory logic is close to the resilience testing model described by EU Digital Operational Resilience Act (DORA): the test has to reflect ICT disruption risk, not just control inventory. That is why TLPT is aimed at operational relevance, not only technical completeness.

What TLPT adds that a standard assessment misses

A standard vulnerability assessment is usually breadth-first. It identifies known weaknesses, often with limited attacker context, and it is useful for hygiene, patching, and prioritisation. TLPT is scenario-driven and objective-driven, so it focuses on the paths that matter most to business continuity, sensitive data, or payment and trading operations.

TLPT also exercises control interaction. Real incidents rarely fail because of one unpatched server alone. They succeed when several conditions line up, for example exposed services, weak segmentation, credential misuse, or an alerting gap. That is why DORA expects testing that resembles a live campaign rather than a static checklist.

The practical value is that TLPT answers a different question: “Can a realistic attacker get far enough to cause material harm, and can we contain it in time?” The related control logic is well aligned with CISA cyber threat advisories, because the attack logic should be informed by actual adversary behaviour rather than abstract weaknesses.

Why regulators prefer realism, not just coverage

DORA is concerned with systemic impact. In financial services, the question is not whether a team can produce a remediation report. It is whether the institution can withstand a relevant intrusion, keep critical functions available, and recover in a controlled way. That makes the test itself part of the resilience evidence.

Threat-led testing also reduces false confidence. A green vulnerability report can hide the fact that a low-severity issue becomes severe once combined with poor identity controls, third-party exposure, or weak incident response. Conversely, a noisy scan result may look alarming without actually leading to exploitable impact. TLPT forces prioritisation by exploitability and consequence.

For organisations that need a practical testing baseline, OWASP Web Security Testing Guide can help structure technical verification, but TLPT goes beyond technical verification into operational resistance and recovery. The two are complementary, not interchangeable.

Risk and Threat Considerations

A vulnerability assessment can miss the business risk that emerges only when weaknesses are chained together. The main exposure is not simply “there is a flaw,” but “a realistic adversary can use that flaw to reach a process, identity, or dependency that matters to continuity.”

Failure mechanism: Attackers exploit the gap between theoretical weakness and operational impact by combining reconnaissance, access paths, privilege escalation, and control evasion until they can disrupt a critical service or prove that the organisation cannot detect and contain the intrusion fast enough.

Impact: The consequence is a blind spot in resilience assurance, where teams may believe they are compliant because vulnerabilities were found, while the organisation remains untested against the kind of chained, time-bound attack that causes real loss, outage, or regulatory scrutiny.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Vulnerability assessments map directly to finding and tracking weaknesses.
	CA-8 — Penetration Testing	TLPT is a penetration-testing approach aimed at realistic exploitation.
	IR-4 — Incident Handling	DORA-style testing checks whether the organisation can respond during attack conditions.
Recommendation — Use RA-5 to maintain vulnerability discovery and prioritisation. Use CA-8 to test exploitable paths with authorised adversary simulation. Use IR-4 to validate detection, response, and containment under realistic scenarios.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	Vulnerability assessments support systematic technical vulnerability management.
	A.5.29 — Information security during disruption	TLPT is about proving resilience during ICT disruption and recovery.
Recommendation — Track and remediate technical vulnerabilities through a formal vulnerability process. Verify that critical services remain protected during disruptive events.
DORA	Threat-led penetration testing	The question is specifically about DORA's requirement for realistic resilience testing.
Recommendation — Run threat-led tests against critical ICT services and remediate material attack paths.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	Vulnerability assessment is the baseline activity that TLPT goes beyond.
	RS.MA-01 — Incidents Are Managed	TLPT evaluates whether the organisation can manage attack conditions effectively.
	RC.RP-01 — Recovery Plan Is Executed During or After an Incident	DORA emphasises resilience and recovery, which TLPT is designed to evidence.
Recommendation — Identify and record weaknesses before prioritising deeper adversarial testing. Exercise incident management against realistic attacker behaviour. Validate that recovery plans work under realistic disruption.

Practitioner Guidance

What to verify: Treat TLPT as a test of detection, escalation, and containment, not a substitute for vulnerability management. If the exercise only produces a list of weaknesses, it has drifted back toward assessment mode and is not proving resilience in the way DORA intends.

Decision rule: Use vulnerability assessments to maintain baseline hygiene and TLPT to validate whether your most important services survive realistic attacker pressure. If you cannot explain which business services, attack paths, and recovery expectations the test is meant to prove, the scope is too broad or too shallow.

Practitioner takeaway: The regulatory point of TLPT is evidence of resilience under adversarial conditions, so the best test is the one that forces teams to demonstrate control effectiveness in a believable attack chain, not the one that merely finds the most findings.