TIBER-EU
threat-led penetration testing for financial entities
TIBER-EU is the European Central Bank framework for threat intelligence-based ethical red teaming. It is the methodology national competent authorities and the ECB use to standardise threat-led penetration testing across the European financial system, and it is the reference framework for TLPT under DORA. Run a defensible TIBER-EU test from preparation through closure, with the white team, control team, threat intelligence provider, red team, and supervisor record on a single workflow.
No credit card required. Free plan available forever.
TIBER-EU in context: the European framework for threat-led penetration testing
TIBER-EU stands for Threat Intelligence-Based Ethical Red Teaming, European Union. It is the framework published by the European Central Bank in 2018 that sets a common methodology for threat-led penetration testing across the European financial system. The ECB and the national competent authorities adopted TIBER-EU so that red team tests run on critical financial entities follow a consistent structure, are comparable across jurisdictions, and produce evidence the supervisor can rely on. Most national implementations carry their own jurisdiction-specific names (TIBER-NL, TIBER-DE, TIBER-IE, TIBER-IT, and others) but they share the same phases, role separation, and attestation requirements.
TIBER-EU sits inside a wider regulatory picture. Under the Digital Operational Resilience Act, in-scope financial entities run threat-led penetration testing at least every three years on systems supporting critical or important functions, and the regulatory technical standards for DORA TLPT explicitly reference TIBER-EU as the reference methodology. Where an entity is not in DORA TLPT scope, TIBER-EU is still adopted voluntarily as the defensible methodology for a credible red team test. For UK financial services, the CREST STAR FS scheme operated alongside CBEST plays a similar role under the Bank of England and the Financial Conduct Authority.
Who runs TIBER-EU and where it applies
TIBER-EU applies primarily to financial entities supervised in the European Union, but the framework is publicly available and is adopted voluntarily by other organisations in the sector. The cadence and depth scale with the size and systemic relevance of the entity, and the inclusion list for each cycle is set by the national competent authority. Critical ICT third-party providers supporting the in-scope functions are pulled into the scoping conversation and may be tested in coordination with the entity.
Significant credit institutions and banks
Banks identified by the European Central Bank or the national competent authority as systemically relevant. Under DORA, significant credit institutions are required to run TLPT at least every three years on systems supporting critical or important functions, and TIBER-EU is the reference methodology adopted across most jurisdictions.
Insurers, asset managers, and investment firms
Solvency II insurers and reinsurers, UCITS management companies, AIFMs, MiFID investment firms, central counterparties, central securities depositories, and trading venues. Inclusion in TLPT scales with size and systemic relevance, and the national competent authority designates the in-scope entities for each cycle.
Payment institutions, e-money institutions, and crypto-asset service providers
Payment institutions, e-money institutions, and MiCA-authorised crypto-asset service providers operating in the European Union. The proportionality regime under DORA softens the cadence for smaller firms, but the methodology remains TIBER-EU when TLPT is required.
National implementations (TIBER-NL, TIBER-DE, TIBER-IE, TIBER-IT, and others)
TIBER-EU is implemented at the jurisdiction level by national competent authorities, often under jurisdiction-specific names that align to the same core methodology (TIBER-NL in the Netherlands, TIBER-DE in Germany, TIBER-IE in Ireland, TIBER-IT in Italy, and so on). The core phases, role separation, and attestation requirements are common across implementations even when the local authority adds bespoke guidance.
The Generic Threat Landscape: where every TIBER-EU test starts
Every TIBER-EU test starts from a Generic Threat Landscape, or GTL, produced for the jurisdiction by the TIBER cyber team and the intelligence community supporting it. The GTL is the reference document that profiles the threat actors plausibly targeting the financial sector in the jurisdiction, the prevailing tradecraft, and the attack patterns the supervisor expects to see reflected in test scenarios. The GTL feeds the entity scope and the Targeted Threat Intelligence report that follows.
- Published per jurisdiction by the national TIBER cyber team and the relevant intelligence community, refreshed periodically
- Profiles the threat actors that are likely to target the financial sector in the jurisdiction: state-aligned groups, organised crime, hacktivists, and insider threat profiles
- Describes the prevailing tradecraft, common initial access vectors, persistence mechanisms, lateral movement patterns, and exfiltration techniques
- Sets the baseline that every Targeted Threat Intelligence report builds from, so individual TTI reports are comparable across entities and over time
- Feeds the scope conversation: which threat actors are credible against the entity, and which scenarios should be in the test plan as a result
Roles and segregation of duties: white, control, blue, red, and TI
Role separation is the structural feature that makes TIBER-EU credible. The framework names five roles, with explicit boundaries between who knows about the test, who runs the test, who oversees the test, and who defends against it. The audit of who knew what and when is part of the attestation, so the role record is captured before launch and maintained throughout the engagement.
White team
A small group inside the entity, typically two to five people, that owns the test end to end. The white team commissions the providers, holds the rules of engagement, has authority to pause or escalate, and is the only group inside the entity that knows the test is happening. White team membership and authority are documented before launch.
Control team
The TIBER cyber team at the national authority and the European Central Bank where applicable. The control team oversees the test across entities, validates that the framework is being followed, and is the route of escalation if the test deviates from the rules of engagement. The control team does not run the test on the entity's behalf.
Blue team
The operational defence: the security operations centre, the incident response team, the IT operations group, and any third parties involved in detection and response. The blue team is unaware that a TIBER-EU test is in progress. The blue team learns about the test only at the replay phase, where the joint debrief happens.
Red team provider
The external red team commissioned by the entity, accredited per the framework expectations. The red team builds the test plan from the Targeted Threat Intelligence, executes the controlled red team test, and produces the test report. The red team is contractually bound by the rules of engagement and reports through the white team only.
Threat intelligence provider
A separate external provider, accredited per the framework expectations, that produces the Targeted Threat Intelligence report tailored to the entity. The TTI takes the Generic Threat Landscape and the entity-specific scope as input, and produces threat actor profiles, scenarios, and tradecraft expectations that the red team uses to build the test plan.
Phase 1: Preparation
Preparation is the longest phase by elapsed time and the phase that most determines whether the test is defensible. The launch document, the procurement of accredited providers, the legal pack, and the rules of engagement all sit in preparation, and the national TIBER cyber team is engaged early so the supervisor expectations are baked into the plan rather than discovered later.
- Engage early with the national TIBER cyber team to confirm jurisdiction-specific guidance, expected timelines, and authority oversight expectations
- Define the entity scope: critical or important functions, the systems and applications supporting them, and the rationale for inclusion or exclusion
- Form the white team with explicit board mandate, authority to commission and pause the test, and a documented contact tree across all roles
- Procure an accredited threat intelligence provider and an accredited red team provider with the credentials and the segregation of duties expected by the framework
- Agree the legal documentation: rules of engagement, authorisation letter, data handling, indemnity, and the joint attestation template
- Hold the launch meeting with the TIBER cyber team, the white team, and the providers, and lock the scope specification before testing begins
Phase 2: Testing (Targeted Threat Intelligence and red team execution)
Testing is what most readers picture when they hear TIBER-EU. The threat intelligence provider builds the Targeted Threat Intelligence report from the GTL and the entity scope. The red team builds the test plan from the TTI, with scenarios and flags. The white team approves and the controlled red team execution runs against live production. Operator notes, evidence per flag, and timestamps are captured during execution rather than reconstructed afterwards.
- The threat intelligence provider produces a Targeted Threat Intelligence report tailored to the entity, the in-scope functions, and the relevant threat actors derived from the Generic Threat Landscape
- The red team builds the test plan from the TTI, with attack scenarios, flags, the proposed attack paths, and the rules of engagement aligned to the scope
- The white team approves the test plan, the flags, and the rules of engagement, and triggers the controlled red team execution against live production
- The red team executes against live production with controlled access, prearranged escalation paths, and a live communication channel back to the white team and the control team
- Operator notes, screenshots, attack timestamps, and evidence per flag are captured during execution so the post-test record is the working record rather than a rebuilt one
Tagging every red team finding by tactic and technique sharpens the test report and the replay conversation. The MITRE ATT&CK framework page covers how to tag findings end to end, the threat-led penetration testing workflow covers the TLPT cycle end to end on a single engagement record, and the red teaming workflow keeps the timeline, attack paths, and operator notes structured rather than scattered across chat history.
Phase 3: Closure (replay, attestation, and lessons learned)
Closure is what separates TIBER-EU from a normal red team engagement. The replay phase pairs the red team and the blue team, walks the attack path together, identifies the detection and response gaps, and agrees the remediation. The joint attestation, signed by the entity, the red team provider, and the threat intelligence provider, goes to the TIBER cyber team and the supervisor as the formal record that a TIBER-EU test was completed.
- The red team produces the test summary report covering scope, methodology, attack paths, observations, and findings against the agreed flags and scenarios
- The replay phase pairs the red team and the blue team, walks through the attack path, identifies the detection and response gaps, and agrees the remediation actions
- The white team consolidates the remediation plan, with owners, deadlines, and re-test conditions tied to the engagement record
- The entity, the red team provider, and the threat intelligence provider sign the joint attestation, which goes to the TIBER cyber team and the supervisor
- The closure pack (TTI report, test plan, red team report, replay notes, remediation actions, attestation) is retained in full so the supervisor and audit trail are addressable from a single record
For the operational side of the remediation work after the attestation, the remediation tracking workflow keeps owners, deadlines, and retest evidence linked to the engagement record so the supervisor cycle does not turn into a second forensic exercise twelve months later.
TIBER-EU and DORA: how they fit together
DORA Article 26 introduces threat-led penetration testing as a formal expectation for in-scope financial entities, and the regulatory technical standards on TLPT specify that TIBER-EU is the reference methodology. In practice this means the TIBER-EU attestation pack is the evidence record that satisfies the DORA TLPT requirement. Entities that ran TIBER-EU before DORA can carry that history forward; entities new to TLPT under DORA build the programme on the TIBER-EU methodology from launch.
For the wider DORA programme around TLPT (the ICT risk framework, incident reporting, and the third-party register), the DORA framework page covers the surrounding articles. For the supervisor expectations on the broader resilience programme, the NIS2 framework page covers risk measures and incident reporting that often run alongside TIBER-EU at group level.
TIBER-EU vs CBEST, GBEST, CREST STAR FS, and HKMA iCAST
TIBER-EU is the European Union framework, but it is not the only intelligence-led red team scheme used in financial services. CBEST is the long-running scheme operated by the Bank of England and the Financial Conduct Authority for UK financial entities, and GBEST is the UK government variant. CREST STAR FS is the CREST scheme used alongside CBEST. In Hong Kong, the HKMA C-RAF Cyber Resilience Assessment Framework runs iCAST as the intelligence-led testing pillar for Authorised Institutions whose tier and maturity profile make controlled offensive testing proportionate. The frameworks share the structural ideas: a generic threat landscape, accredited providers, a small white team, role separation, controlled execution, replay, and a joint attestation. They differ in jurisdiction, accreditation body, and some procedural detail. Many groups operating across multiple jurisdictions run more than one scheme, mapping the common artefacts across the frameworks rather than building separate evidence packs.
Evidence the supervisor (and your board) actually want
TIBER-EU programmes that fail review usually fail because the artefacts are scattered across drives, secure email threads, and screenshots. Build the closure pack as the work happens, retain raw evidence alongside the structured record, and tie every artefact back to the phase, the role that produced it, and the approver who signed it off. The attestation reads the way the underlying record reads.
- Scope specification covering critical functions, systems, applications, threat actors in scope, and the rationale for inclusion or exclusion
- Board approval, white team membership, and the contact tree with authority to escalate and pause
- Procurement records for the threat intelligence provider and the red team provider, including credential evidence and conflict-of-interest checks
- Targeted Threat Intelligence report, the red team test plan, and the rules of engagement signed by the white team
- Operator notes and evidence per flag captured during execution, retained in raw form alongside the structured engagement record
- Red team test summary report, replay notes, gap analysis, and the agreed remediation plan with owners and deadlines
- Joint attestation signed by the entity, the red team provider, and the threat intelligence provider
- Re-test evidence and lessons learned feeding back into the broader resilience programme
Where SecPortal fits in the TIBER-EU workflow
SecPortal is the operating layer for the TIBER-EU engagement, not a replacement for the national TIBER cyber team, the threat intelligence provider, or the red team. The platform handles scope, role records, findings, replay notes, attestation artefacts, and the closure pack so the work runs as a structured workflow rather than a long encrypted email thread. Compliance tracking maps the TIBER-EU evidence pack to DORA, NIS2, and ISO 27001 for entities that have to satisfy more than one regime from the same body of work.
- Engagement management dedicated to a TIBER-EU test, with phases (preparation, testing, closure) tracked as workstreams rather than as a single PDF
- Findings management with CVSS 3.1 scoring, MITRE ATT&CK tagging, and 300+ templates so each red team finding ties to the scenario, the flag, and the technique it evidenced
- AI report generation that turns the test summary, findings, and remediation actions into a structured red team report and a board-ready narrative without manual rewriting
- Attack surface management to map the external footprint of the in-scope critical functions before the red team builds the test plan
- Continuous monitoring with scheduled scans so the entity has a baseline of evidence before launch and a coverage record across the cycle
- Compliance tracking that maps the TIBER-EU evidence pack to DORA Article 26, NIS2 testing expectations, and the entity's wider control framework
TIBER-EU is a multi-month engagement, not a one-week test. The first cycle for a new in-scope entity typically takes between nine and twelve months from launch to attestation, with preparation alone taking three or more months. Subsequent cycles run faster because the white team, the providers, and the evidence patterns are reusable. Running the work as a managed workflow pays off most over time: prior TTI reports, prior red team findings, and prior remediation timelines stay linked, so each cycle is an iteration rather than a rebuild. For consultants delivering TIBER-EU work to multiple clients, the security consultants workspace bundles the platform with branded client portals and AI report generation so the deliverable looks as polished as the work behind it.
For programmes that want continuous detection and trend evidence between TIBER-EU cycles, the continuous monitoring capability and attack surface management capability produce the cadence and coverage record that TLPT programmes are expected to keep between formal tests.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Generic Threat Landscape (GTL) and entity scoping
TIBER-EU starts with a Generic Threat Landscape produced for the jurisdiction by the TIBER cyber team and the relevant intelligence community. The GTL feeds the entity-specific scope: which critical functions are in scope, which systems support those functions, and which threat actors and tactics the test will simulate. Capture the scope specification, the critical function mapping, the rationale for inclusion and exclusion, and the board approval as a structured record so the launch document holds up to supervisor review.
Test phases (preparation, testing, closure)
TIBER-EU runs in three phases. Preparation covers scoping, procurement of providers, and the launch meeting with the TIBER cyber team. Testing covers the targeted threat intelligence report, the red team test plan, and the controlled red team execution against live production. Closure covers the replay phase, the test report, the joint remediation plan, the attestation, and the lessons learned. Track each phase as a workstream rather than as separate documents, with timestamps and approvals captured as the work happens.
White team, control team, blue team, and red team roles
The white team is the small group inside the entity that runs the test, owns the rules of engagement, and is the only group that knows about the test. The control team at the TIBER cyber team and the supervisor oversees the test across entities. The blue team is the operational defence and is unaware until the replay. The red team is the external provider commissioned to execute. Capture the membership, the contact tree, the legal authority, and the segregation of duties record on the engagement so the audit of who knew what and when is provable.
Targeted Threat Intelligence (TTI) and red team test plan
A TIBER-EU test is intelligence led. The threat intelligence provider produces a Targeted Threat Intelligence report tailored to the entity, the in-scope functions, and the relevant threat actors derived from the GTL. The red team builds the test plan from the TTI, with attack scenarios, flags, and rules of engagement signed off by the white team. Tag every red team finding to the scenario, the flag, and the MITRE ATT&CK technique it evidenced so the report and the attestation align without rework.
Replay phase and joint debrief with the blue team
The replay phase is what separates TIBER-EU from a normal red team test. After the controlled execution, the red team and the blue team walk the attack path together, identify detection and response gaps, and agree on the remediation work. Capture the replay timeline, the gap analysis, and the agreed remediation actions on the same engagement record that holds the red team report so the closure pack reads as a single narrative rather than two competing versions.
Attestation, remediation tracking, and supervisor reporting
TIBER-EU closes with a joint attestation signed by the entity, the red team provider, and the threat intelligence provider, supported by the test summary report and the remediation plan. The attestation goes to the TIBER cyber team and the supervisor, and feeds the TLPT evidence record under DORA Article 26 where applicable. Retain the raw artefacts (TTI report, test plan, red team report, replay notes, remediation actions, retest evidence) inside the engagement record so the attestation pack is a click rather than a forensic exercise.
Related features
Run a defensible TIBER-EU test without spreadsheet sprawl
Bring scoping, threat intelligence, red team execution, replay, and attestation into one workflow. Start free.
No credit card required. Free plan available forever.