DORA TLPT and TIBER-EU: Preparing Financial Entities

Financial entities operating in the European Union face growing expectations to demonstrate that their critical systems can withstand sophisticated cyberattacks. The Digital Operational Resilience Act (DORA) establishes requirements for digital operational resilience, including threat-led penetration testing for selected financial entities.

DORA Threat-Led Penetration Testing (TLPT) uses intelligence about realistic cyber threats to test an organisation's ability to prevent, detect, and respond to attacks. The European Central Bank's TIBER-EU framework provides a structured methodology for this type of testing. Although closely related, DORA TLPT and TIBER-EU are not interchangeable legal terms. Financial entities must understand the regulatory requirements, determine whether they fall within the scope of TLPT, and prepare their people, systems, and governance arrangements accordingly.

What Is DORA TLPT?

DORA TLPT is a threat-led testing requirement established under Article 26 of Regulation (EU) 2022/2554. It is designed to assess how effectively selected financial entities can withstand advanced cyber threats affecting their critical or important functions.

Unlike conventional vulnerability scans or standard penetration tests, TLPT uses threat intelligence to simulate realistic attack scenarios. Qualified testers attempt to identify and exploit weaknesses in the entity's live production environment within an agreed scope and under controlled conditions.

The objective is to assess the effectiveness of an organisation's security controls, detection capabilities, incident response processes, and operational resilience. The testing should produce evidence of how the organisation responds to realistic threats, rather than simply identifying technical vulnerabilities.

Build Digital Operational Resilience With DORA Compliance. Demonstrate Regulatory Alignment With INTERCERT.

DORA TLPT Requirements

DORA Articles 26 and 27 establish the principal requirements for threat-led penetration testing and the testers who perform it. Commission Delegated Regulation (EU) 2025/1190 sets out the regulatory technical standards specifying the detailed requirements for TLPT.

The main requirements include:

Risk-based scope: Testing must cover the relevant ICT systems and infrastructure supporting critical or important functions.
Threat intelligence: Scenarios must reflect credible threats and the entity's specific risk environment.
Qualified testers: Testing must be performed by testers who meet the applicable independence, competence, confidentiality, and security requirements.
Controlled execution: Testing must follow approved procedures to manage operational risk and protect business continuity.
Governance and oversight: The financial entity must establish responsibilities for planning, coordinating, monitoring, and reviewing the test.
Remediation: Findings must be documented, assessed, and addressed through an appropriate remediation process.
Regulatory reporting: The entity must provide the required information and attestation to its competent authority in accordance with the applicable rules.

Financial entities subject to TLPT must generally undergo testing at least once every three years. However, competent authorities may set a different frequency based on the applicable regulatory framework and the entity's circumstances.

TLPT Requirements for Financial Institutions

DORA does not require every financial entity to undergo TLPT automatically. Competent authorities identify the entities that must conduct testing using the criteria established by the regulation and its related technical standards.

The assessment considers factors such as the entity's systemic importance, risk profile, ICT maturity, and the potential impact of disruption to its services. Relevant exclusions and special provisions may apply to certain entities.

Financial institutions should establish whether their competent authority has identified them for TLPT. They should also maintain evidence of the decision, understand the applicable testing requirements, and determine which critical functions and supporting systems may fall within the scope.

Preparation should involve senior management, information security, technology, risk management, compliance, business continuity, and other relevant teams. These functions need clearly defined responsibilities before testing begins.

What Is TIBER-EU?

TIBER-EU stands for Threat Intelligence-Based Ethical Red Teaming. Developed by the European Central Bank, it is a framework for conducting controlled, intelligence-led red team tests against financial entities.

The framework simulates the tactics, techniques, and procedures that sophisticated attackers might use against an organisation. It combines targeted threat intelligence with red team testing to assess the effectiveness of an entity's preventive, detective, and response capabilities.

TIBER-EU is a framework, not a separate EU regulation. DORA establishes the legal requirement for TLPT for entities identified by their competent authorities, while TIBER-EU provides a methodology that can be used to conduct testing where it meets the applicable DORA requirements.

TIBER-EU Threat-Led Penetration Testing

TIBER-EU testing starts with threat intelligence relevant to the financial entity. This intelligence informs realistic attack scenarios that reflect the threats facing the organisation, its business model, and its critical functions.

A red team then uses the approved scenarios to test the entity's defences. The activity may examine technical weaknesses, security monitoring, incident detection, escalation processes, and the effectiveness of the response teams.

The test is designed to assess the organisation as a whole, not only the security of individual devices or applications. For example, a test involving a banking service could examine whether attackers can move from an exposed system towards infrastructure that supports a critical financial function, subject to the approved scope and safeguards.

Testing must be carefully controlled. The organisation establishes rules of engagement, communication arrangements, escalation procedures, and safety measures to limit unintended disruption.

TIBER-EU Penetration Testing vs Standard Penetration Testing

Standard penetration testing generally examines defined applications, networks, devices, or other technical assets to identify exploitable vulnerabilities. It may be broad or narrowly targeted, depending on the objective and agreed scope.

TIBER-EU testing takes a broader, threat-led approach. It uses tailored threat intelligence to design realistic attack scenarios and evaluates how the organisation's security controls and response capabilities perform during those scenarios.

A conventional penetration test may establish that a vulnerability exists in an internet-facing application. A threat-led red team test may examine how an attacker could exploit an initial weakness, move through the environment, and attempt to reach systems associated with a critical business function.

Both approaches have value, but they serve different purposes. Standard penetration testing can provide focused technical findings, while TLPT assesses resilience against realistic attack paths. A standard penetration test does not automatically satisfy DORA TLPT requirements.

How DORA TLPT and TIBER-EU Relate

DORA and TIBER-EU share the objective of testing whether financial entities can withstand realistic cyber threats. Their relationship is important because entities must satisfy the binding regulatory requirements rather than rely solely on the name of a testing methodology.

DORA establishes the legal obligation for selected financial entities to undergo TLPT. TIBER-EU offers a structured testing methodology that can be applied where the test complies with DORA and the applicable technical standards.

Common Objectives and Testing Principles

Both approaches focus on realistic threats, critical business functions, and the practical effectiveness of cybersecurity controls.

Their common principles include:

Using threat intelligence to develop relevant attack scenarios.
Testing the systems and infrastructure associated with critical or important functions.
Evaluating the effectiveness of preventive and detective controls.
Examining incident response and escalation arrangements.
Maintaining clear rules of engagement and appropriate safeguards.
Documenting findings and identifying corrective actions.
Involving relevant stakeholders throughout the testing process.

These principles distinguish threat-led testing from assessments that focus only on a checklist of security controls or known vulnerabilities.

Key Differences Between DORA TLPT and TIBER-EU

The principal difference is their regulatory status and purpose. DORA is an EU regulation that establishes legally binding requirements. TIBER-EU is a testing framework developed by the European Central Bank.

DORA TLPT must comply with the regulation and the applicable regulatory technical standards. Using the TIBER-EU methodology does not, by itself, prove compliance. The entity must ensure that the test meets the relevant scope, governance, tester qualification, reporting, and other requirements.

TIBER-EU provides a structured methodology for planning, conducting, and closing a threat-led red team test. DORA specifies the obligations applicable to financial entities identified for testing.

Financial entities should therefore evaluate the actual testing process and its regulatory alignment rather than assume that every TIBER-EU exercise automatically meets DORA requirements.

Which Financial Entities Must Prepare for TLPT?

DORA applies to a range of financial entities, including banks, payment institutions, electronic money institutions, investment firms, and other entities within its scope. However, inclusion within DORA does not automatically mean that every entity must undergo TLPT.

The competent authority identifies entities subject to TLPT based on the relevant criteria. Financial entities should confirm their status with the appropriate authority and review any specific requirements that apply to their sector.

Even entities that are not selected for formal TLPT may benefit from understanding threat-led testing, particularly when they operate critical services or depend on complex ICT environments.

TIBER-EU for Financial Institutions

Banks and other financial institutions may depend on interconnected platforms for customer transactions, account management, payments, identity verification, and market operations. A successful cyberattack against one part of this environment could affect several related services.

Threat-led testing evaluates whether an attacker could exploit weaknesses across these connected systems and whether the institution's controls can detect and contain the activity.

Preparation should include identifying critical business services, mapping the ICT assets and dependencies that support them, and establishing which systems are suitable for inclusion in the approved test scope.

Financial institutions should also determine who can approve testing activities, who monitors operational risks, and how the organisation will respond if a test produces an unexpected result.

TLPT for Banking Systems

Banking systems can include online banking platforms, core banking applications, customer databases, authentication services, transaction processing systems, and supporting infrastructure.

The relevant scope depends on the critical or important functions selected for testing and the applicable regulatory requirements. It should not be based solely on a list of high-profile applications.

Banks should map the relationships between critical services and their supporting technologies. This can include identity and access management, network connectivity, data stores, cloud services, monitoring platforms, and third-party dependencies.

A well-defined scope enables the testing team to develop realistic scenarios while reducing the risk of disrupting essential banking operations.

TIBER-EU for Payment Systems

Payment systems are important targets because disruption or unauthorised access may affect transaction integrity, service availability, and customer confidence.

Threat-led testing may examine relevant payment processing infrastructure, interfaces, authentication mechanisms, administrative access, and monitoring controls where these fall within the approved scope.

Entities should identify the services and dependencies that support payment processing, including connections with external providers. They should also define safety limits for testing, establish escalation contacts, and agree on procedures for handling unexpected effects on transactions or service availability.

Testing must be planned so that the exercise does not unintentionally compromise real payments, customer data, or the continuity of critical services.

TLPT for Financial Transaction Systems

Financial transaction systems may include trading platforms, settlement infrastructure, transaction monitoring, payment gateways, and other technologies that enable financial operations.

The relevant risks differ by system. For example, an attack against a trading platform may threaten availability or the integrity of trading operations, while an attack against a transaction processing service may affect data integrity or service continuity.

Financial entities should identify the transaction systems associated with critical or important functions and understand their technical and operational dependencies. The testing scope should reflect realistic attack paths while preserving the safeguards required for live production testing.

TIBER-EU TLPT Requirements

A successful TLPT requires more than selecting a red team and scheduling an exercise. The entity must establish a controlled testing process, define responsibilities, and ensure that the scope and methodology meet the applicable requirements.

Scope and Critical or Important Functions

The scope should be based on the critical or important functions identified by the financial entity. The organisation must determine which ICT systems, applications, infrastructure, and dependencies support those functions.

Scope definition should consider the business impact of disruption, the sensitivity of the information processed, the potential consequences of unauthorised access, and the dependencies between systems.

The entity should maintain a documented record of the approved scope and any exclusions. It should also identify restrictions on testing, including activities that could affect customer services, third-party environments, or essential operations.

Where third-party ICT providers are involved, the entity must consider the relevant dependencies and applicable regulatory requirements. Their involvement should be assessed according to the approved scope and the rules governing the test.

Threat Intelligence Provider and Red Team Tester Requirements

Threat intelligence informs the scenarios used during TLPT. The intelligence provider analyses relevant threat actors, their methods, and the risks that apply to the financial entity.

The red team uses this intelligence to design and execute the approved attack scenarios. Testers must meet the applicable requirements for competence, independence, confidentiality, security, and experience.

Financial entities should evaluate the qualifications and relevant experience of proposed providers. They should also confirm that contractual arrangements address confidentiality, information handling, test boundaries, escalation, and the protection of sensitive data.

DORA Article 27 establishes requirements for TLPT testers, while the related technical standards provide further detail. The use of internal testers is subject to specific conditions, including requirements concerning external testers. Entities should verify the applicable provisions before finalising their testing arrangements.

Control Team and Governance Requirements

The control team coordinates the exercise and oversees its safe execution. Its responsibilities may include approving test activities, monitoring operational risks, managing escalation, and ensuring that relevant stakeholders understand their roles.

The control team must be able to respond if the exercise creates an unexpected operational impact or approaches a defined safety boundary. Communication arrangements should be established in advance, including who can pause or stop testing when necessary.

Governance should also address confidentiality. Only authorised personnel should receive information about the test, according to the agreed operating model. At the same time, the organisation must ensure that designated control personnel can oversee the exercise effectively.

Clear governance helps maintain the integrity of the test while protecting business operations and sensitive information.

TIBER-EU Red Team Testing Phases

TIBER-EU organises testing into three main phases: preparation, testing, and closure. Each phase has a distinct purpose and requires coordination between the financial entity and the relevant testing providers.

Preparation Phase

The preparation phase establishes the foundations of the test. The entity defines the objectives, identifies the critical or important functions in scope, establishes governance arrangements, and confirms the roles of the parties involved.

Threat intelligence is gathered and analysed to develop realistic scenarios. The entity also agrees on rules of engagement, communication procedures, escalation arrangements, and safety measures.

Preparation should include identifying relevant system owners, operational contacts, incident response personnel, and decision-makers. Where third-party services or dependencies are involved, the entity should determine how they affect the test scope and what approvals are required.

Before testing begins, the parties should confirm that the scope, scenario design, responsibilities, and operational safeguards are sufficiently documented and approved.

Testing Phase

During the testing phase, the red team executes the agreed scenarios against the approved environment. The activities are designed to simulate realistic attacker behaviour while remaining within the authorised scope.

Testing may involve attempts to gain initial access, exploit weaknesses, move between systems, escalate privileges, or reach assets associated with critical functions. The precise activities depend on the threat intelligence, test objectives, and approved rules of engagement.

The control team monitors the exercise and manages operational risks. Relevant escalation procedures must remain available throughout the test.

The entity's detection and response teams may be evaluated through their handling of the simulated activity. Depending on the test design, the organisation may assess how alerts are identified, investigated, escalated, and contained.

The testing phase must follow the applicable regulatory standards and agreed safeguards. The duration and execution requirements should be confirmed against the rules governing the specific exercise.

Closure Phase

The closure phase focuses on analysing results, documenting findings, and establishing corrective actions.

The red team reports the attack paths and weaknesses identified during the exercise. The financial entity evaluates the implications for its critical functions and determines which findings require prioritised remediation.

Where applicable, the process includes a purple teaming or knowledge-sharing activity in which the red team and the organisation's defenders review relevant observations. This can help explain how attack activity was detected or missed and identify improvements to defensive controls.

The entity should record remediation owners, priorities, deadlines, and verification activities. It must also prepare the information and attestation required by the applicable regulatory framework and submit them to the competent authority as required.

Closure does not mean that every finding must be fixed immediately. It means that findings are assessed, responsibilities are assigned, and corrective actions are managed through a documented process consistent with the applicable requirements.

What Financial Entities Need to Prepare for TLPT

Financial entities should approach TLPT as a governed operational exercise rather than a standalone technical test. Preparation needs to cover scope, people, suppliers, production risks, evidence, and remediation.

Defining Scope and Critical Systems

Start by identifying the critical or important functions that may fall within the scope of testing. Map the applications, networks, data stores, identity systems, infrastructure, and external dependencies that support those functions.

The scope should reflect how services operate in practice. A critical function may rely on multiple systems owned by different internal teams or external providers. Overlooking these relationships can result in an incomplete view of the risks.

Document the selected assets, exclusions, testing boundaries, and relevant business owners. Confirm that the scope is consistent with the applicable DORA requirements and the instructions of the competent authority.

Setting Up Internal Roles and Stakeholders

Identify the teams responsible for approving, coordinating, monitoring, and reviewing the test. Depending on the organisation, these may include cybersecurity, IT operations, risk management, compliance, legal, business continuity, incident response, and senior management.

Assign clear responsibilities for decisions such as approving test activities, escalating unexpected effects, communicating with providers, and stopping the exercise if required.

The organisation should also establish how sensitive test information will be handled. Access to scenario details should follow the agreed confidentiality arrangements while preserving effective oversight.

Selecting Qualified External Testers

Financial entities should assess potential testing providers against the applicable requirements for competence, independence, experience, confidentiality, and security.

Relevant considerations include previous experience with financial sector environments, the ability to conduct intelligence-led testing, knowledge of the regulatory framework, and experience working within controlled production environments.

Before appointing a provider, review the proposed scope, methodology, contractual terms, deliverables, data handling arrangements, and escalation procedures. Confirm that the testing team can meet the requirements applicable to the entity and its planned exercise.

The selection process should also account for any DORA provisions governing the use of internal and external testers.

Managing Risk During Live Production Testing

TLPT may involve testing live production systems, so operational risk management is essential. The entity should establish safeguards to protect service availability, transaction integrity, customer information, and other critical assets.

Rules of engagement should specify permitted activities, prohibited actions, system boundaries, testing windows where relevant, and the conditions under which the exercise must be paused or stopped.

The organisation should agree on escalation channels and ensure that the control team can respond quickly to unexpected outcomes. Relevant operational teams should understand the safeguards that apply to the exercise.

Third-party dependencies require particular attention. The entity should confirm which systems may be tested, what permissions are necessary, and how testing will be managed if an external provider's infrastructure is involved.

Reporting, Remediation, and Attestation

The value of TLPT depends on what the entity does with the findings. The organisation should establish a process for recording weaknesses, assessing their impact, assigning owners, and tracking corrective actions.

Findings should be prioritised according to their potential effect on critical functions, the likelihood of exploitation, and the effectiveness of existing controls. Remediation may involve technical changes, improved monitoring, revised incident response procedures, or changes to access controls.

The entity should retain evidence of the testing process, relevant approvals, results, remediation decisions, and required regulatory communications. It should also plan how remediation will be verified.

DORA requires relevant reporting and attestation to the competent authority under the applicable rules. Financial entities should confirm the required content, format, deadlines, and any follow-up obligations for their specific test.

Common Challenges in Preparing for DORA TLPT and TIBER-EU

Financial entities can encounter several challenges when preparing for threat-led testing.

Unclear scope: Organisations may struggle to identify all the systems and dependencies supporting critical functions. Incomplete asset inventories can lead to gaps in the test scope.

Limited internal coordination: Testing requires cooperation across technology, security, risk, compliance, and business teams. Unclear ownership can delay approvals or weaken operational oversight.

Third-party dependencies: Critical services may rely on cloud providers, software vendors, payment processors, or other ICT suppliers. These dependencies can introduce restrictions on what can be tested and require additional coordination.

Production risk: Realistic testing must be balanced against the need to protect live services. Inadequate safety controls can increase the risk of unintended disruption.

Tester selection: Financial entities must confirm that their chosen testers meet the applicable regulatory requirements. Experience in conventional penetration testing alone may not establish suitability for TLPT.

Remediation delays: Findings may involve legacy systems, complex architectures, or multiple system owners. Without clear priorities and accountability, corrective actions can remain unresolved.

Regulatory documentation: The entity must maintain suitable evidence and meet the applicable reporting and attestation requirements. Poor recordkeeping can make it harder to demonstrate that the exercise was properly governed.

Addressing these challenges early can make the testing process more controlled and ensure that the results translate into measurable improvements in digital operational resilience.

Strengthen Digital Resilience Across Financial Operations .Verify Your DORA Compliance With INTERCERT.

Best Practices for TLPT Readiness

Financial entities can strengthen their preparation by establishing a repeatable process for threat-led testing and remediation.

Confirm regulatory status: Determine whether the competent authority has identified the entity for TLPT and establish which requirements apply.
Maintain accurate asset inventories: Map critical functions to the ICT systems and dependencies that support them.
Establish clear governance: Assign responsibilities for approvals, oversight, escalation, and remediation.
Validate provider qualifications: Confirm that threat intelligence providers and red team testers meet the applicable requirements.
Define operational safeguards: Establish clear testing boundaries, escalation routes, and stop conditions before testing begins.
Coordinate with stakeholders: Ensure that relevant teams understand their roles and know how operational risks will be managed.
Document decisions and evidence: Maintain records of scope, approvals, test execution, findings, and regulatory communications.
Prioritise remediation: Assign owners and deadlines based on the significance of each finding.
Verify corrective actions: Confirm that remediation addresses the underlying weakness and that improvements operate as intended.
Review lessons learned: Use the results to strengthen detection, response, governance, and resilience over time.

These practices help financial entities prepare for a structured testing exercise while maintaining focus on regulatory obligations and the resilience of critical services.