The DORA TLPT requirements push selected EU financial entities beyond standard penetration testing. TLPT must be based on realistic threat scenarios, relevant threat actors, and current intelligence about how attacks are actually carried out.
That makes threat intelligence a core part of the process. It helps define what should be tested, which TTPs matter, and which attack paths are most relevant to the organization.
Let’s look at the main TLPT requirements explained in practice, where threat intelligence fits into DORA TLPT, and what teams need to get right before testing begins.
What Are the DORA TLPT Requirements?
The Digital Operational Resilience Act (DORA), established under Regulation (EU) 2022/2554, sets cybersecurity and operational resilience requirements for financial entities across the European Union.
Under DORA Article 26 TLPT, certain financial entities must carry out threat-led penetration testing at least once every three years. The DORA TLPT frequency can be adjusted depending on the entity’s risk profile and operational circumstances.
The framework is maintained by the European Central Bank (ECB), while the DORA TLPT standards were developed by the European Supervisory Authorities — EBA, EIOPA, and ESMA — in cooperation with the ECB.
The DORA TLPT scope must cover several or all critical or important functions and include the ICT systems, processes, and technologies that support them. Testing is carried out on live production systems, which is one of the main differences between TLPT and more conventional security assessments.
The detailed methodology is set out in the Regulatory Technical Standards under Commission Delegated Regulation (EU) 2025/1190. These rules define how TLPT should be scoped, prepared, executed, and followed by remediation.
How TIBER-EU Fits into DORA TLPT
The TIBER-EU framework DORA connection is straightforward. DORA sets the regulatory requirements for TLPT, while TIBER-EU provides a practical framework for carrying out threat intelligence-based red team testing.
The updated TIBER-EU framework closely follows the DORA TLPT process, covering scoping, threat intelligence, red team testing, purple teaming, and reporting.
For financial organizations, this means TLPT is not just about testing systems for weaknesses. The exercise should reflect the threats, techniques, and attack paths that are actually relevant to the organization.
The Main TLPT Phases Under DORA
The TLPT phases DORA follows are grouped into three main parts: preparation, testing, and closure. The testing phase covers both threat intelligence and active red team testing, while reporting, replay, purple teaming, remediation planning, and attestation come later in the process.
1. Preparation Phase
The preparation phase sets up the exercise. The financial entity forms the control team, defines the scope, selects the threat intelligence and red team providers, and puts the necessary risk management and communication arrangements in place.
The relevant National Competent Authority (NCA) or TLPT authority also oversees key parts of the process, including the scope and overall test setup.
Because TLPT is performed against live production systems, this phase also includes assessing the risks of the test and agreeing the controls needed to keep it safe.
2. Testing Phase
The testing phase starts with threat intelligence. The threat intelligence provider analyzes relevant threats, gathers target-specific intelligence, and develops scenarios that reflect realistic attacks against the financial entity.
Once the targeted threat intelligence report is approved, the red team uses it together with the scope specification document to prepare the red team test plan and execute the selected attack scenarios. The active red team testing phase must last at least 12 weeks.
3. Closure Phase
After active testing ends, the red team and blue team prepare their respective reports. The teams then replay the offensive and defensive actions performed during the test and carry out purple teaming to review vulnerabilities, missed detections, and other areas for improvement.
The financial entity then prepares a summary of the TLPT findings, including a high-level remediation plan. The TLPT authority reviews the required documentation as part of the attestation process.
What Threat Intelligence Does in DORA TLPT
In threat intelligence DORA TLPT, the job is to work out which threats actually matter for the financial entity being tested. That means looking at the organization’s sector, exposure, systems, and current threat activity, then using that information to guide the exercise.
This is where threat intelligence in penetration testing becomes practical. Instead of starting with generic attack scenarios, teams can focus on the threat actors, TTPs, infrastructure, and attack paths that are more likely to be relevant to that organization.
For DORA threat-led penetration testing, this intelligence helps answer a few basic questions before the red team starts: who is most likely to target the entity, what they may try to reach, how they are likely to get in, and which techniques they are using now.
The result is a test based on evidence about the organization and its current threat environment, rather than a fixed set of generic attack cases.
How ANY.RUN Can Support Threat Intelligence for DORA TLPT
Threat intelligence for TLPT needs to be specific enough to support realistic scenarios. That means analysts don’t only need high-level threat reports but also current infrastructure, malware behavior, indicators, and relationships between them.
Threat Intelligence Lookup: Investigate Relevant Threat Activity
Threat Intelligence Lookup gives teams access to threat data generated from investigations across the ANY.RUN community, used by 700,000+ security professionals and 16,000+ organizations. That gives analysts a much broader base of real-world activity to work from when researching threats for TLPT.
Instead of stopping at a single IOC, teams can investigate the wider context around it:
- related domains, IPs, URLs, and infrastructure
- malware families and samples connected to the same activity
- links between indicators seen across different investigations
- behavior associated with active campaigns
- patterns that help show whether a threat is relevant to the financial entity
For TLPT preparation, this can help turn a broad threat hypothesis into something more concrete. If a team identifies a threat actor or malware family that matters to the organization, they can dig into the surrounding infrastructure and behavior, then use that evidence to make the scenario more specific and closer to what attackers are actually doing.
Teams can also use Threat Intelligence Feeds to keep TLPT scenarios aligned with current threat activity. 30% of unique malicious IOCs discovered by ANY.RUN customers during their Interactive Sandbox investigations are already available in ANY.RUN TI Feeds, giving teams more up-to-date context when reviewing indicators and infrastructure before testing begins.
Interactive Sandbox: Add Behavioral Context to TLPT Scenarios
Threat intelligence can show which malware, infrastructure, or attack chains matter. A sandbox helps teams understand how those threats actually behave once executed.
With ANY.RUN’s Interactive Sandbox, analysts can inspect process chains, persistence, network activity, dropped files, command-and-control behavior, and MITRE ATT&CK techniques in one investigation. That gives the testing team more concrete behavioral evidence when deciding which techniques and behaviors are worth including.
For example, if a malware family is relevant to the financial entity, the team can see how it establishes persistence, what infrastructure it contacts, and which techniques appear during execution. Those details can help make the scenario closer to observed attacker behavior instead of relying only on static indicators.
The sandbox does not replace the live production testing required by DORA. It supports the research and preparation that happens before the active TLPT exercise.
Who Is Involved in a DORA TLPT?
A DORA TLPT involves several teams, each with a different role in planning, executing, or overseeing the exercise.
- Control team: A small group within the financial entity that knows the test is taking place. It coordinates the exercise, manages risk, and can intervene if testing creates an unacceptable risk to production systems.
- Threat intelligence provider: Researches the threat landscape and the financial entity itself, then develops the intelligence and scenarios that guide the test.
- Red team: Carries out the simulated attack, using the agreed scenarios to test how far an attacker could get against the organization’s critical functions.
- Blue team: The organization’s defensive team. It is not told about the exercise in advance and is expected to detect and respond as it would during a real attack.
- TLPT authority: Oversees the test through designated test managers and checks that the exercise follows the required methodology.
Once active testing is over, the red and blue teams come together for replay and purple teaming. They compare what the attackers did with what defenders saw and responded to, then use those findings to identify gaps and remediation priorities. Purple teaming is mandatory under the DORA-aligned TIBER-EU framework.
What DORA Requires from Threat Intelligence Providers
DORA is fairly specific about who can support a TLPT exercise. Under DORA Article 27 TLPT, testers are expected to have the right technical expertise, relevant experience, and enough independence to work on an exercise that may involve live production systems.
The threat intelligence provider TLPT requirements are set out in more detail in the Regulatory Technical Standards (RTS) under Commission Delegated Regulation (EU) 2025/1190. The provider should be able to show relevant experience, bring together the right mix of technical, sector, and geopolitical knowledge, and avoid conflicts of interest that could affect the exercise.
That matters because the provider is not there simply to deliver a list of indicators. They need to judge which threats are genuinely relevant to the financial entity, which details are useful for the test, and how that intelligence should be turned into something the red team can actually work with.
What Goes into a DORA Targeted Threat Intelligence Report
The targeted threat intelligence report is one of the main outputs of the TI phase. It brings together the threat information most relevant to the financial entity and gives the testing team a stronger basis for building realistic scenarios.
The report can include:
- critical or important functions in scope
- relevant threat actors and TTPs
- exposed credentials and look-alike domains
- vulnerable or exploitable systems
- malicious infrastructure linked to current activity
- malware families connected to relevant campaigns
- other technical evidence that can help shape the test
ANY.RUN can support this work by adding technical context and behavioral evidence to the threat intelligence process. Threat Intelligence helps teams connect domains, IPs, URLs, malware families, and related infrastructure, while the Interactive Sandbox shows how relevant threats behave during execution.
Together, this gives analysts a clearer picture of the activity behind the indicators — not just what is malicious, but how it operates. That context can help strengthen threat profiles, validate TTPs, and give the red team more concrete evidence when building attack scenarios.
Strengthen DORA TLPT With Better Threat Intelligence
For financial organizations, TLPT is not just a regulatory exercise. Its value depends on whether the test reflects the threats the business is actually exposed to and gives security teams something useful to act on afterward.
ANY.RUN is already used by 1,811 financial organizations, giving teams access to threat intelligence and investigation data that can support the preparation behind DORA TLPT.
With stronger threat context going into the exercise, teams can make better testing decisions, focus on the risks that matter most, and get more value from the TLPT process.
About ANY.RUN
ANY.RUN helps security teams investigate threats, analyze malware, and work with current threat intelligence. The platform is used by 700,000+ security professionals and 16,000+ organizations worldwide.
Its solutions include the Interactive Sandbox, Threat Intelligence Lookup, and Threat Intelligence Feeds, giving teams access to malware behavior, related infrastructure, and fresh threat data in one environment.
The company is also SOC 2 Type II attested, reflecting established controls around security, availability, and data protection.
Frequently Asked Questions
Yes, in some cases. Internal testers can be used if the relevant TLPT authority approves them and the entity meets the requirements for independence, resourcing, and experience. When internal testers are used, the threat intelligence provider must remain external.
The control team lead must select at least three scenarios. They should reflect different threat actors and TTPs and cover the critical or important functions included in scope. No more than one selected scenario can be non-threat-led.
Yes, but the teams must be separated. Staff providing threat intelligence for the TLPT cannot report to or overlap with the staff carrying out the external red team testing for the same exercise.
DORA requires restoration procedures after the test. This includes secure handling and deletion of compromised passwords, credentials, and secret keys, removal of backdoors or malware, and deactivation of command-and-control infrastructure used during the exercise.
Yes. Risk management continues throughout the exercise because testing takes place on live production systems. The control team is responsible for managing risks such as service interruption, data corruption, incident escalation, and impacts on third parties.
Yes. The RTS allows both joint TLPTs and pooled TLPTs, including cases involving shared ICT third-party providers. Each participating entity still has responsibilities for assessing and managing its own risks.
0 comments