What is TIBER-EU testing?

TIBER-EU testing is a controlled, threat-intelligence-led red team exercise for financial entities, based on the European Union framework called Threat Intelligence-Based Ethical Red Teaming. It simulates the tactics of relevant attackers against an entity's critical functions so the organisation can assess how well its people, processes and technology prevent, detect and respond to a realistic cyber attack.

How TIBER-EU testing works

The exercise follows a structured process, typically overseen by the relevant national authority. The entity defines the critical functions in scope, such as payment processing or customer account access, and agrees boundaries, safety controls and rules of engagement before testing begins.

A threat intelligence provider researches plausible threat actors and produces targeted intelligence about their motives, methods and likely attack paths. A red team uses this intelligence to create and execute a test plan against the selected functions. The exercise may involve technical systems and human or procedural elements, within the agreed scope and safeguards.

A designated control group, often called the white team, coordinates the exercise and manages risks. The defenders, or blue team, generally do not know the test schedule or details, allowing the exercise to assess real detection and response. The precise arrangements depend on the scope and the applicable national implementation.

In the closure phase, the red team and defenders review what happened, including actions that succeeded, controls that failed and opportunities to detect the activity earlier. The organisation uses the findings to agree remediation and improve its response capability.

What TIBER-EU testing assesses

TIBER-EU testing examines whether an attacker could affect critical business functions by moving through realistic attack paths. For example, a scenario might test whether an attacker could obtain privileged access, reach a payment service and cause disruption before defenders detect and contain the activity.

The exercise assesses the interaction between technical controls and operational response. Findings can reveal gaps in monitoring, escalation, access management or coordination between teams. The purpose is to learn how the organisation performs under a realistic threat scenario, rather than to produce a simple list of software vulnerabilities.

TIBER-EU testing is distinct from a conventional penetration test. A penetration test usually targets specified systems or applications to identify exploitable weaknesses. TIBER-EU testing uses threat intelligence to guide a broader adversary simulation against critical functions, with attention to detection and response as well as access. It is also different from routine banking software testing, which checks whether software behaves as specified.

Practical example

Suppose a bank selects a high-priority payment function for an exercise. The threat intelligence report identifies a plausible route involving compromised staff credentials and access to a supporting service. The red team follows an approved plan to test that route. The blue team monitors its normal alerts and response processes.

The exercise records whether suspicious access was detected, whether the response team escalated it correctly, and whether the payment function remained within agreed safety limits. The final review maps observations to corrective actions, such as revising alert rules or clarifying incident escalation responsibilities. Testers must stop or change activity if it risks service availability, customer data or systems outside the authorised scope.

Relationship to DORA and threat-led testing

TIBER-EU provides a common methodology for threat-led red team exercises in the financial sector. The Digital Operational Resilience Act (DORA) includes requirements for threat-led penetration testing (TLPT) for certain financial entities. TIBER-EU is relevant to that work, while the applicable regulatory requirements, authority processes and entity obligations determine how a particular exercise must be conducted.

An exercise should have clear approval, scope, communication routes, safety limits and evidence handling before execution. Without those controls, a realistic attack simulation can cause operational disruption or expose sensitive information. Results should be treated as restricted security material, with access limited to people who need it.