What a DORA TLPT Assessment Actually Requires

The Digital Operational Resilience Act (DORA) became fully enforceable across the EU on January 17, 2025. For financial entities subject to its requirements, one provision generates more anxiety in the boardroom than almost any other: the Threat-Led Penetration Test, or TLPT.

The fear is understandable. A failed TLPT isn't just an embarrassing audit finding — it can trigger regulatory sanctions, mandatory remediation windows, and public disclosure requirements. But here's what most security leaders don't realize: the majority of TLPT failures aren't caused by catastrophic vulnerabilities. They're caused by preparation gaps — misunderstood scoping requirements, undocumented risk frameworks, and security programs built around point-in-time testing rather than continuous assurance.

This post breaks down exactly what DORA's TLPT requirements demand, where organizations fall short, and what a security program needs to look like to not just survive a TLPT assessment, but to make it a competitive advantage.

By the Numbers

Sources: European Parliament Regulation (EU) 2022/2554 (DORA); European Banking Authority 2024 DORA Supervisory Convergence Report.

What Is a DORA TLPT And Who Has to Do One?

TLPT stands for Threat-Led Penetration Testing. Under DORA Article 26, it is a structured red-team exercise where simulated attack scenarios are designed based on real-world threat intelligence specific to the entity being tested. Unlike a standard vulnerability assessment or even a conventional penetration test, TLPT is designed to replicate the tactics, techniques, and procedures (TTPs) of actual threat actors targeting your industry and your organization specifically.

DORA does not require every financial entity to undergo a TLPT. The obligation applies to significant financial entities as designated by their lead overseer — typically large banks, insurers, payment institutions, and critical third-party ICT service providers. As of 2025, the European Banking Authority (EBA), European Insurance and Occupational Pensions Authority (EIOPA), and European Securities and Markets Authority (ESMA) jointly oversee the framework. According to the EBA's 2024 supervisory convergence work programme, TLPT designation notifications began in Q1 2025 with initial assessments rolling out across the year. [1]

Key Threshold: Even entities not currently designated for TLPT should treat its requirements as a maturity benchmark. Regulators have indicated that designation scope may expand as DORA implementation matures — and future M&A activity that increases systemic importance can trigger designation without warning.

TLPT under DORA also introduces the TIBER-EU framework as the technical standard for conducting exercises. TIBER-EU (Threat Intelligence-Based Ethical Red Teaming) was developed by the European Central Bank and provides the structured methodology that TLPT assessments must follow — from threat intelligence gathering through red team execution to purple team closure activities.

The Five Phases of a DORA TLPT Assessment

Understanding what a TLPT actually involves is the first step toward preparing for one successfully. Under the TIBER-EU framework, which DORA's implementing technical standards (ITS) adopt as the reference methodology, a TLPT follows a defined five-phase structure.

Phase 1: Scoping

This is where most organizations stumble before the test even begins. Scoping a TLPT is not the entity's decision alone, it requires approval from the lead overseer. The scope must define the critical functions, the underlying ICT systems, and the third-party providers that support those functions. Regulators expect scoping documents that are traceable to the entity's formal ICT risk framework.

According to PwC's 2024 DORA Readiness Survey, 61% of surveyed financial institutions had not yet completed a formal mapping of their critical ICT functions to third-party dependencies — a prerequisite for TLPT scoping. [2]

Phase 2: Threat Intelligence

A threat intelligence provider, independent of the red team, is engaged to produce a Targeted Threat Intelligence (TTI) report. This report documents the threat landscape relevant to the entity: which threat actor groups are actively targeting the sector, what TTPs they use, and what attack scenarios are most plausible. This is not generic threat intel. It must be specific to the entity's business profile, geographic footprint, and technology stack.

Mandiant's M-Trends 2024 report found that financial services remains the second most targeted sector globally, with a median dwell time of 10 days before detection — giving red teams a realistic simulation window. [3]

Phase 3: Red Team Testing

The red team — an accredited external provider under TIBER-EU — executes the attack scenarios defined by the threat intelligence phase. Critically, the test is unannounced to the blue team. Only a small 'White Team' inside the organization (typically 2-3 senior security/risk leaders) knows the test is occurring. This structure ensures that organizational defenses are tested as they actually operate, not as they perform when on alert.

The scenarios typically include initial access via phishing or exploitation of external-facing systems, lateral movement through internal networks, access to critical data or systems, and attempted exfiltration.

Phase 4: Closure — Purple Team Activity

After red team operations conclude, TIBER-EU requires a structured purple team phase where the red team and blue team collaborate to review every attack scenario step-by-step. The goal is not to assign blame but to identify detection gaps, improve defensive tooling, and validate that remediation actions are effective. This phase is often underestimated in time and resource requirements.

Phase 5: Remediation and Attestation

The entity produces a TLPT Summary Report that must be submitted to the lead overseer. This report documents scope, threat intelligence findings, red team scenarios executed, detection and response outcomes, identified gaps, and a time-bound remediation plan. The overseer may issue a certificate of completion — but only if the remediation plan is credible and the test was conducted in accordance with TIBER-EU standards.

Why Organizations Fail TLPT Assessments — And It's Rarely the Red Team Results

Here's the uncomfortable truth: most TLPT failures aren't caused by the red team finding catastrophic vulnerabilities. They're caused by documentation gaps, governance failures, and security programs that were built for point-in-time compliance rather than continuous operational resilience.

According to KPMG's Digital Operational Resilience Act — Insights from Early Adopters (2024), the top three reasons organizations struggled with TLPT-equivalent assessments were: [4]

• Inadequate ICT risk framework documentation - risk registers existed but weren't maintained or tied to critical function mapping
• Scoping failures - entities couldn't produce regulator-ready evidence that their defined scope encompassed all material systems and third-party dependencies
• Remediation verification gaps - prior audit findings and vulnerability disclosures had no documented evidence of retesting or closure

This last point is particularly relevant. DORA Article 13 requires that ICT-related incidents and vulnerabilities are not just documented — they must be tracked through to verified remediation. An organization that logs findings in a ticketing system but has no mechanism to confirm that fixes actually work is exposing itself to regulatory risk regardless of what the red team finds.

The Blind Spot Problem: Annual or point-in-time penetration testing creates a fundamental assurance gap. Your TLPT will be evaluated against your current security posture — not your posture at last year's test date. If your attack surface has changed since your last assessment (and it has), you're walking into a TLPT with unknown exposure.

Gartner's 2024 Market Guide for Penetration Testing Services notes that PTaaS (Penetration Testing as a Service) adoption is accelerating specifically because of regulatory frameworks like DORA that require demonstrable, continuous assurance rather than episodic testing artifacts. [5]

TLPT Requirement Breakdown: What's Required vs. Where Organizations Fall Short

What 'TLPT-Ready' Actually Looks Like

Being TLPT-ready is not about having a spotless security record. Regulators understand that no organization has zero vulnerabilities. What they're evaluating is whether your security program is mature, continuously operated, and evidenced.

A TLPT-ready security posture has three core characteristics:

1. Continuous Attack Surface Visibility

You cannot scope a TLPT if you don't know what you have. DORA's TLPT scoping requirements assume a current, complete inventory of ICT systems supporting critical functions including third-party and cloud-hosted infrastructure. Organizations that rely on annual discovery exercises or static asset inventories will struggle to produce credible scoping documentation.

Attack Surface Management (ASM) is not optional for DORA compliance, it's foundational. Continuous ASM provides the always-current asset inventory that scoping requires and gives you early warning when new infrastructure appears that might be material to your critical function mapping.

2. Continuous, Evidence-Based Testing

DORA's remediation requirements create a documentary burden that point-in-time testing cannot satisfy. Every material finding must be tracked to verified closure. This requires unlimited retesting capability - the ability to confirm that a fix actually works without scheduling and paying for a new engagement.

IBM's Cost of a Data Breach Report 2024 found that organizations using security AI and automation had a breach cost $2.2 million lower than those that didn't — a direct signal that continuous, technology-enabled security programs outperform episodic ones. [6]

3. Board-Level Reporting With Actual Evidence

DORA Article 5 places explicit responsibility on management bodies for ICT risk governance. The TLPT Summary Report must demonstrate that leadership received findings, understood risk context, and approved remediation priorities. Security teams that operate in isolation, producing reports that never reach the board, will find this requirement difficult to evidence.

The operational reality is that board-level reporting requires live data, not static PDFs. Role-based portals that provide executives with current finding status, remediation progress, and risk posture summaries are increasingly the expectation, not a premium feature.

Third-Party Providers: The TLPT Scope Risk Most Organizations Underestimate

DORA's TLPT requirements extend to critical third-party ICT service providers (CTPPs). Under Article 26(8), where a financial entity's critical functions depend materially on a third-party provider, the regulator may require the CTPP to participate in or support the TLPT — or to conduct a TLPT of their own systems relevant to the entity's critical functions.

This creates a supply chain assurance requirement that many organizations haven't accounted for. Accenture's State of Cybersecurity 2024 found that 40% of cyberattacks now originate from or leverage the extended supply chain, and that most financial institutions have limited visibility into their third-party providers' actual security posture. [7]

If your TLPT scope includes critical functions that run on third-party infrastructure, you need contractual rights to include that provider in your exercise — and you need current evidence of their security posture. Organizations that haven't built this into their vendor contracts before TLPT designation are in a difficult position.

A Practical Preparation Checklist

If you're a security leader at a financial entity that may be designated for TLPT, here's where to focus:

• Complete your ICT risk framework and critical function mapping. This is a scoping prerequisite. Every system, service, and third-party dependency that supports a critical function must be documented and current.
• Establish continuous attack surface monitoring. You need to know what your external footprint looks like today — not last quarter. ASM tools provide the always-current inventory that TLPT scoping requires.
• Audit your remediation tracking process. Can you produce evidence that every material finding from the past 12 months was verified as remediated? If not, close that gap before your TLPT.
• Review third-party contracts for TLPT participation rights. Engage critical ICT providers now to confirm they can support scoping, threat intelligence, or red team activities as required.
• Establish board reporting cadence with live data. Leadership needs to demonstrate active involvement in ICT risk governance. Static quarterly PDFs won't satisfy this requirement.
• Engage an accredited TIBER-EU test provider early. TIBER-EU accredited red team providers are a limited pool. Capacity constraints are real — don't wait until your designation notice arrives.

How Sprocket Security Supports DORA TLPT Readiness

Sprocket Security was built around a fundamental truth: security testing that happens once a year — or even once a quarter — doesn't reflect how attackers operate or how your environment changes. DORA TLPT requirements simply make that truth regulatory.

Our continuous penetration testing platform provides the foundational capabilities TLPT preparation requires: always-on attack surface management that maintains your external asset inventory, continuous testing that triggers when your environment changes, and unlimited retesting that verifies remediation rather than just documenting findings. Every engagement is delivered by OSCP- and CISSP-certified consultants using current real-world TTPs — the same threat intelligence-driven approach that TIBER-EU mandates.

The Sprocket Portal gives security teams and executives live, role-based visibility into finding status, remediation progress, and risk posture - the documented governance evidence that TLPT assessments require at the board level.

Organizations that wait for TLPT designation before investing in continuous assurance will find themselves under a compressed, high-stakes timeline. Organizations that operate continuous programs walk into TLPT preparation with documented evidence, current posture visibility, and a defensible remediation record.

Ready to Assess Your TLPT Readiness? Sprocket Security offers a complimentary attack surface assessment for financial services organizations preparing for DORA compliance. Start with visibility — it's where every strong TLPT preparation begins. Visit sprocketsecurity.com or contact us at contact@sprocketsecurity.com.

References

[1] European Banking Authority. (2024). EBA Work Programme 2024 — DORA Supervisory Convergence. eba.europa.eu

[2] PwC. (2024). DORA Readiness Survey: Financial Services Institutions' Preparedness for Digital Operational Resilience. pwc.com/dora-readiness

[3] Mandiant. (2024). M-Trends 2024: Special Report. mandiant.com/mtrends

[4] KPMG. (2024). Digital Operational Resilience Act — Insights from Early Adopters. kpmg.com/dora

[5] Gartner. (2024). Market Guide for Penetration Testing Services. gartner.com [subscription required]

[6] IBM Security. (2024). Cost of a Data Breach Report 2024. ibm.com/security/data-breach

[7] Accenture. (2024). State of Cybersecurity Report 2024. accenture.com/cybersecurity-report

[ECB] European Central Bank. (2020). TIBER-EU Framework — How to Implement the European Framework for Threat Intelligence-Based Ethical Red Teaming. ecb.europa.eu/tiber-eu

[DORA] European Parliament. (2022). Regulation (EU) 2022/2554 on Digital Operational Resilience for the Financial Sector (DORA). eur-lex.europa.eu