Notifications
Clear all
Topic starter
19/08/2026 3:44 pm
TL;DR: Most DORA TLPT failures come from scoping, documentation, and remediation evidence gaps rather than from dramatic red-team findings, according to Sprocket Security, with 61% of surveyed institutions still lacking formal critical-function-to-third-party mapping. The real issue is continuous assurance: without current inventories, verified closure, and board-visible evidence, TLPT becomes a governance test that many programmes are not built to pass.
NHIMG editorial — based on content published by Sprocket Security: DORA TLPT readiness and the governance gaps that cause failure
By the numbers:
- Financial services remains the second most targeted sector globally, with a median dwell time of 10 days before detection.
Questions worth separating out
Q: What breaks when a financial entity treats TLPT as a one-off test?
A: A one-off approach breaks the evidence chain.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Sprocket Security's analysis of DORA TLPT readiness and resilience gaps →
DORA TLPT readiness: where financial entities keep failing?
Explore further
19/08/2026 4:22 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: DORA tlpt readiness is mostly a governance problem, not a testing one
