DORA tlpt readiness is mostly a governance problem, not a testing one

At a glance

What this is: This is an analysis of DORA threat-led penetration testing requirements and the control gaps that cause financial entities to fail them.

Why it matters: It matters because TLPT readiness depends on continuous ICT governance, third-party visibility, and evidence-based remediation, all of which map directly to IAM-adjacent accountability and operational resilience.

By the numbers:

• 61% of surveyed financial institutions had not yet completed a formal mapping of their critical ICT functions to third-party dependencies.
• Financial services remains the second most targeted sector globally, with a median dwell time of 10 days before detection.

👉 Read Sprocket Security's analysis of DORA TLPT readiness and resilience gaps

Context

DORA threat-led penetration testing is a governance exercise as much as a security one, because regulated financial entities must prove that critical functions, supporting systems, and third-party dependencies are mapped, tested, and remediated in a way an overseer can verify. In practice, many programmes still rely on annual testing and static evidence packs, which leaves them exposed when regulators ask for current, defensible proof of control.

The article is strongest where it shows that TLPT failure usually comes from preparation gaps rather than catastrophic technical weakness. That pattern matters beyond DORA because the same evidence problem appears in IAM, PAM, and NHI programmes when ownership, scope, and remediation status are not maintained continuously.

For identity teams, the relevant lesson is that risk management collapses when access, dependency, and lifecycle records drift away from operational reality. The starting position described here is common rather than exceptional, especially in organisations that still treat assurance as a point-in-time activity.

Key questions

Q: What breaks when a financial entity treats TLPT as a one-off test?

A: A one-off approach breaks the evidence chain. DORA expects current scope, verified remediation, and leadership visibility, so point-in-time testing leaves gaps between cycles where new systems, third-party dependencies, and unresolved findings can accumulate unnoticed.

Q: Why do DORA TLPT requirements force better third-party governance?

A: Because critical functions often depend on external providers, and those dependencies must be included in scope and exercise planning. If contracts, ownership, and access rights are not already clear, the organisation cannot prove that its resilience controls extend beyond the internal perimeter.

Q: How do security teams know whether TLPT remediation is actually working?

A: They need retesting evidence tied to each finding, not just a ticket marked closed. The practical test is whether the control still holds after change, because that is what regulators will care about when they review operational resilience.

Q: Who is accountable when TLPT scope is wrong or incomplete?

A: The management body remains accountable under DORA for ICT risk governance, even if execution is delegated. That means scope failures are not just testing mistakes, they are governance failures that should surface in board reporting and remediation oversight.

Technical breakdown

How DORA TLPT uses TIBER-EU to simulate real adversaries

Threat-led penetration testing under DORA is not a generic red-team engagement. TIBER-EU requires threat intelligence specific to the entity, then uses that intelligence to shape scenarios that mirror real attacker behaviour against the sector, footprint, and technology stack. The process is structured around scoping, intelligence gathering, red-team execution, purple-team review, and remediation attestation. The key technical point is that the exercise is judged on realism and traceability, not novelty. If the threat model is vague, the test loses regulatory value even when the tooling is strong.

Practical implication: build TLPT scenarios from current threat intelligence and map each one back to a documented ICT risk framework.

Why scoping failures break DORA TLPT before testing begins

TLPT scope is a control problem, not an administrative formality. Regulators expect the entity to identify critical functions, the systems that support them, and the third parties that materially contribute to those functions. If that mapping is incomplete, the red team may test the wrong assets, or the overseer may reject the exercise outright. In identity terms, this is similar to losing lifecycle control over privileged dependencies: if you cannot define the population, you cannot govern it. Scope quality is therefore the first proof of programme maturity.

Practical implication: maintain a continuously updated inventory of critical functions, systems, and third-party dependencies before seeking TLPT designation.

Why remediation evidence matters more than findings volume

DORA cares less about how many issues a red team uncovers than whether the organisation can prove that findings were fixed and retested. That means the evidence chain must connect detection, ticketing, retesting, and closure in a way that survives supervisory review. This is where many programmes fail, because they treat remediation as a spreadsheet activity rather than a controlled assurance workflow. The broader governance lesson is that point-in-time testing cannot satisfy a regime built around verified operational resilience.

Practical implication: require verified retesting and closure evidence for every material finding, not just a remediation ticket.

Threat narrative

Attacker objective: The objective is to demonstrate that a real attacker could compromise critical financial functions and undermine operational resilience under realistic conditions.

1. Entry begins with externally exposed systems, phishing, or another initial access path that reflects the sector-specific threat intelligence used for the exercise.
2. Escalation follows when the red team pivots through internal networks, critical systems, or third-party-supported services that were not fully scoped.
3. Impact is measured by whether the attackers can reach critical data, disrupt key functions, or demonstrate credible exfiltration paths.

NHI Mgmt Group analysis

TLPT readiness fails first at governance, not at exploitation. The article shows that most problems arise before the red team even starts, when organisations cannot prove scope, ownership, or remediation lineage. That is a structural weakness in ICT governance, and it is visible in IAM and NHI programmes whenever inventories and account ownership drift away from current reality. Practitioners should treat evidence quality as a control outcome, not a reporting task.

Continuous assurance is now the real control objective. DORA exposes the limits of annual testing and one-off audit preparation because the regulator evaluates the current attack surface, not last year’s posture. This aligns with identity operations where standing access, stale entitlements, and unmanaged service accounts create hidden exposure between review cycles. The practical conclusion is that security programmes need live control evidence, not periodic compliance artefacts.

Third-party dependency mapping has become a resilience control, not just a vendor-management task. The article makes clear that critical functions often depend on external providers, which means scope, testing, and remediation can no longer stop at the internal perimeter. In identity terms, this is the same problem that appears when delegated access, service accounts, or cloud trust relationships are not lifecycle-managed. Practitioners should assume their TLPT scope will fail if third-party dependencies are not continuously mapped.

Evidence-based remediation is the named concept that separates mature programmes from audit-ready ones. Findings are only meaningful when retesting proves that the control actually works after change, which is what many point-in-time programmes still miss. For regulated financial entities, that creates a direct line from remediation discipline to supervisory confidence. The practitioner takeaway is simple: if a fix cannot be verified, it is not a fix in regulatory terms.

DORA is indirectly raising the bar for identity governance discipline. The article’s emphasis on critical-function mapping, third-party scope, and verified closure mirrors what strong IAM and NHI programmes already require for privileged access and credential lifecycle control. Where those disciplines are weak, TLPT becomes an exposed symptom rather than the root problem. Practitioners should use DORA as a forcing function to tighten identity ownership, access evidence, and dependency governance.

What this signals

TLPT readiness will increasingly behave like identity governance: the programmes that win are the ones that can prove current scope, ownership, and closure, not the ones that only pass annual review. For identity and security teams, that means treating access, dependency, and remediation evidence as live operational data rather than compliance documentation.

Evidence-based remediation: the control pattern that matters most here is the ability to prove a fix worked after the environment changed. That concept will become more familiar across NHI, PAM, and cloud governance because regulators are moving toward continuous proof, not static attestation.

For programmes that already struggle with service-account ownership, third-party trust chains, or stale access records, DORA is an early warning rather than a niche financial-services issue. The organisations that respond now by tightening inventory, approval, and verification flows will be better positioned for similar resilience expectations elsewhere.

For practitioners

• Complete critical-function and dependency mapping Map every critical function to the systems, services, and third-party providers that support it, then keep that mapping current enough to support regulator-approved TLPT scoping. The output should be traceable to the ICT risk framework and usable as evidence, not just a planning document.
• Establish continuous asset and exposure visibility Replace annual discovery with continuous attack surface monitoring so new infrastructure, cloud-hosted services, and externally exposed assets are visible before the next test cycle. This is the difference between a credible scope and a stale inventory.
• Verify every remediation with retesting Require proof that each material finding was fixed and retested, with closure evidence linked to the original issue and retained for supervisory review. Spreadsheet tracking without verification will not survive a DORA assessment.
• Review third-party contracts for TLPT participation rights Confirm that critical ICT providers can support scoping, threat intelligence, and red-team activity where required, and that contracts already grant those rights. If the agreement does not cover TLPT participation, it becomes a governance blocker later.
• Move board reporting to live evidence Give management bodies access to current finding status, remediation progress, and risk context rather than static PDFs prepared for audit season. DORA Article 5 expects leadership to demonstrate active governance, not passive receipt of reports.

Key takeaways

• DORA TLPT failures usually expose governance gaps in scoping, documentation, and remediation verification rather than dramatic technical weakness.
• The strongest evidence in the article is that many financial institutions still cannot map critical functions to third-party dependencies, which makes regulator-ready testing difficult before it starts.
• Continuous visibility, verified retesting, and live board reporting are the controls that turn TLPT from an audit burden into a resilience discipline.

Key terms

• Threat-Led Testing: A method of testing security controls by simulating realistic attacker behaviour rather than checking policy compliance alone. It is useful because it reveals how systems behave under pressure, where identity controls fail, and whether detection and containment can work in live conditions.
• TIBER-EU: The European framework for threat intelligence-based ethical red teaming. It provides the methodology for scoping, intelligence gathering, execution, and closure so regulators can evaluate whether the test was realistic, controlled, and evidence-backed.
• Critical Function Mapping: Critical function mapping is the process of identifying which systems, identities, vendors, and workflows are necessary for essential operations to continue. In healthcare, it links technical access to patient-care impact so teams can prioritise protections where interruption would create the greatest harm.
• Evidence-Based Remediation: A remediation model where fixes are not considered complete until the organisation can prove they worked through retesting or other objective evidence. This turns closure into a verifiable control outcome rather than a ticket status.

What's in the full article

Sprocket Security's full article covers the operational detail this post intentionally leaves for the source:

• The five-phase TIBER-EU workflow as applied to DORA TLPT, including how scoping, intelligence, and purple-team closure are sequenced.
• A requirement-by-requirement breakdown of what regulators expect versus the most common organisational shortfalls.
• A practical TLPT readiness checklist for financial entities preparing evidence, board reporting, and third-party participation rights.
• The vendor's view of how continuous testing and attack surface management fit into DORA compliance preparation.

👉 The full Sprocket Security article covers the TLPT workflow, readiness checklist, and remediation evidence requirements.

Deepen your knowledge

NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, IAM, and identity lifecycle control. It gives practitioners a common control language for programmes that need stronger identity evidence and lifecycle discipline.