DORA Article 26 test data for European banks: TIBER-EU and the first cycle to January 2028.

§ 01 / Eighteen months in

What European banks have learned since application

DORA entered into force on 16 January 2023 and became applicable on 17 January 2025. Eighteen months into the application period, the picture for significant European banks is one of accelerating preparation rather than calm compliance. The first mandatory TLPT cycle under Article 26(3) must complete by 17 January 2028, three years after the application date. Banks that aim to close their first cycle on time need to commence preparation no later than the second quarter of 2027, and pragmatically much earlier given vendor capacity constraints across the EU.

Survey work conducted across the European financial sector indicates that compliance maturity is significantly behind regulatory expectations. Industry analysts have estimated that the great majority of European financial services organisations still report material gaps in their data resilience capabilities against DORA expectations. Third-party risk oversight was widely cited as the hardest DORA requirement to operationalise. For TLPT specifically, the bottleneck is not the willingness of banks to invest but the availability of qualified test providers and the operational complexity of coordinating across multiple supervisory authorities.

The supervisory cadence has settled into a pattern. National competent authorities are working through entity identification under Article 26(8), placing significant banks on the TLPT list and engaging on scoping. The ECB, as consolidating supervisor for significant institutions in the Single Supervisory Mechanism, coordinates with national TIBER cyber teams to align expectations for cross-border groups. The TIBER-EU 2025 framework, published by the ECB in January 2025, provides the technical baseline aligned with DORA.

§ 02 / Regulatory timeline

From 17 January 2025 to 17 January 2028

§ 03 / Scope identification

Who must perform TLPT

DORA Article 26 does not impose TLPT on every financial entity in the EU. The regulation creates a two-tier approach. Global systemically important institutions (G-SIIs) under CRR III and CRD VI definitions are automatically subject to TLPT. Beyond G-SIIs, national competent authorities identify other entities based on a risk-based assessment using three criteria set out in Article 26(8): impact-related factors (the entity's market share, interconnectedness with other financial institutions, criticality of services), financial stability concerns (systemic character at Union or national level), and the entity's specific ICT risk profile and maturity.

In practice, NCAs are identifying for TLPT the largest banks, payment service providers with significant transaction volumes, central counterparties, central securities depositories, and large insurers. Smaller institutions with limited systemic importance are generally not identified. The identification is communicated by the NCA to the entity directly and triggers the obligation to plan for the first cycle.

Cross-border groups face a particular operational pattern. Each subsidiary in scope of national TLPT identification is potentially subject to TLPT in its home jurisdiction. For a banking group with significant subsidiaries in five Member States, that could theoretically mean five separate TLPT cycles for a single group. Article 26(8) on mutual recognition exists precisely to address this: a TLPT conducted under one NCA's supervision can be recognised by other NCAs for the same scope, avoiding duplicate testing. In practice, mutual recognition requires advance coordination between competent authorities and acceptance by all parties of the lead authority's methodology.

§ 04 / TIBER-EU methodology

The five-phase common framework

DORA TLPT follows the TIBER-EU methodology adapted as legally binding under RTS 2025/1190. The five phases are sequential, each with explicit deliverables and stakeholder authorisations. Phase compression is one of the most common reasons supervisory attestation is denied.

The Preparation phase typically runs four to six weeks and includes the appointment of the White Team (the small group inside the entity that knows the test is happening — typically CISO, Head of Resilience, Head of Internal Audit, Head of Legal, plus an external TLPT test manager), the formal scoping of critical or important functions to be covered, the engagement of two separate providers (one for Threat Intelligence, one for Red Teaming) registered with the relevant national TIBER cyber team, and notification to the competent authority and TIBER cyber team.

The Threat Intelligence phase typically runs four weeks minimum. The TI provider produces a Targeted Threat Intelligence report profiling the threat actors most likely to target the institution and their tactics, techniques and procedures. Many national TIBER implementations provide a Generic Threat Landscape report as input, summarising the national financial sector threat environment. From the TTI report, three attack scenarios are selected and approved by the TLPT authority.

The Red Teaming phase runs a minimum of twelve weeks on live production systems supporting critical or important functions. The Red Team executes the approved scenarios using realistic tactics including spear phishing, attempts to compromise Active Directory, supply chain attacks via ICT providers, and data exfiltration. The Blue Team is not aware of the test during the active phase, preserving the realism of the detection and response measurement.

The Closure and Purple Teaming phase reconvenes the teams after the active phase ends. The Red Team reports findings. The Blue Team assesses its own detection and response performance ex-post. A joint Purple Team exercise analyses gaps between attack and detection, producing a remediation plan with owners, priorities, and target dates.

The Attestation phase closes the cycle. The entity submits the summary of findings, the remediation plan, and the documentation evidencing compliance with RTS 2025/1190 to the competent authority. The authority issues an attestation, which other competent authorities recognise under Article 26(8) for the same scope.

§ 05 / National TIBER variations

How TIBER-XX implementations differ

National TIBER implementations adopt the TIBER-EU framework but maintain variations reflecting local supervisory traditions, sector structure, and pre-existing testing programmes. For cross-border banking groups, understanding these variations is operationally consequential.

Variations centre on three operational dimensions. Provider accreditation: each national TCT maintains its own list of accredited Threat Intelligence and Red Team providers. A provider accredited in Germany is not automatically accredited in France. Documentation language: some jurisdictions require key deliverables in the local language, adding translation overhead. Scope review: the depth of NCA review during scoping varies, with some authorities engaging more intensively than others on the definition of critical or important functions.

§ 06 / Mutual recognition

How Article 26(8) works in practice

Article 26(8) provides that a TLPT attested under one NCA can be recognised by other NCAs for the same scope, avoiding duplicate testing across jurisdictions. The mechanism is essential for the operational feasibility of TLPT in cross-border banking groups, but its practical use requires advance preparation.

Three preconditions apply. First, a lead competent authority must be agreed before the test commences. The lead is typically the home country supervisor of the parent entity. Second, the scope must cover the critical or important functions across all relevant jurisdictions, not just the home market. Third, the methodology must satisfy the requirements of each recognising authority, which in practice means full conformance with TIBER-EU 2025 and RTS 2025/1190.

Groups with branches or subsidiaries in multiple EU Member States and in the UK face additional complexity. UK PRA does not formally participate in TIBER-EU mutual recognition. PRA SS1/23 governs model risk management in UK-incorporated entities, and PRA SS1/21 governs operational resilience. UK CBEST (the PRA's intelligence-led penetration testing scheme) shares methodological lineage with TIBER-EU but operates independently. A group with UK and EU operations may need to run a coordinated programme covering both regimes, with the methodology and scope aligned but the formal attestations separate.

§ 07 / The GDPR Article 32 tension

Live production data in test scope

Article 26(2) requires TLPT to be performed on live production systems supporting critical or important functions. This requirement, unambiguous in the regulation text, creates direct tension with GDPR Article 32 obligations on security of processing. The Red Team, while contractually bound and operating under documented controls, has the capability to access personal data of customers, transactions, balances and credit decisions during the active phase. A breach in the test environment is treated under GDPR as a breach in production: up to 20 million euros or 4% of global annual turnover.

DORA does not waive GDPR. Both regulations apply in parallel. A bank that experiences a data leak during TLPT faces simultaneous exposure under both regimes. Supervisors expect the bank to manage these risks proactively: documented kill-switch procedures, restricted Red Team access to systems where personal data is unmasked, audit logging of all Red Team actions, and Data Protection Impact Assessment specifically for the test scope.

The pragmatic answer is not to mask production for TLPT — masking breaks the realism the test depends on — but to design the scope and the supporting infrastructure such that personal data exposure during the test is minimised by architectural design. Encryption at rest with tight key controls, tokenisation of high-sensitivity fields, and synthetic data layers for pre-test scope validation all contribute. The last of these is operationally important: White Team validation work, where the test scope is iterated and refined before formal NCA submission, can run entirely on synthetic data, avoiding production exposure for the most active iteration phase.

§ 08 / Pooled TLPT

Shared ICT providers and joint testing

Article 26(4) and Article 26(5) introduce pooled TLPT for financial entities relying on the same critical ICT third-party service provider. The mechanism is economically and operationally sensible: when five banks depend on the same cloud provider, a single TLPT covering the provider's operational resilience can be conducted once, with results proportionately shared among the participants. Pooled TLPT requires written agreement from all participating entities and the relevant supervisors.

The operational complexity of pooled testing rests in the data. The cloud provider being tested holds data from all participating banks in environments typically logically separated. A pooled Red Team conducting the test must have the ability to test attacks that could potentially expose one bank's data in another bank's environment. This extends GDPR Article 32 exposure from one controller to all participants. A breach in a pooled test environment affects every participating bank.

The practical operational answer is for participants to provide a shared synthetic data layer to the provider's test environment. Each bank delivers a synthetic equivalent of its production portfolio that preserves structural fidelity without retaining real customer records. The pooled Red Team tests the provider's resilience in this shared environment, without exposure to any participant's actual personal data. This requires a synthesis standard agreed between participants and acceptable to the supervisors.

§ 09 / What Infundum is designing

CAUSA AI Data Engine for TLPT

Infundum's CAUSA AI Data Engine is being designed as a causal multi-table synthesis infrastructure for the financial sector. CAUSA is pre-MVP; what follows describes design intent and architectural direction, not shipped feature set.

For TLPT under DORA Article 26, the design intent addresses three operational needs. First, synthetic environments for pre-TLPT scope validation: White Teams iterate the scope definition, communication protocols and kill-switch procedures on synthetic environments matching production fidelity, without inviting NCA scrutiny on each iteration. Second, synthetic shells for pooled testing: a common synthetic data layer for pooled TLPT, where multiple banks using the same ICT provider can jointly verify resilience without exposing each other's personal data. Third, audit-grade lineage: each synthetic dataset carries documented generation parameters, model, seed, and privacy threshold, suitable for presenting to the lead competent authority as evidence that test environment data carried no link to real customers.

Deployment is self-hosted within the bank's secure perimeter. Specific architecture details are available under NDA during formal evaluation.

§ 10 / Related

Regulatory context

For the cross-border BCBS 239 framework see BCBS 239 and ECB RDARR: synthetic data lineage for cross-border European banks. For PRA SS1/23 model risk management governing UK subsidiaries see PRA SS1/23 Model Risk Management: validating multi-table banking models without PII exposure. For the FCA SDEG considerations relevant to UK-EU groups see FCA SDEG governance considerations for synthetic data in UK financial services.

Conclusion

DORA Article 26 TLPT is not a marginal compliance topic. The regulatory cadence to 17 January 2028 is firm, the methodology is codified in RTS 2025/1190, and the national TIBER variations layered on top introduce operational complexity that cross-border banking groups must navigate proactively. Live production testing requirements collide with GDPR Article 32 in ways that no single technical control fully resolves, but architectural design choices and synthetic data layers can substantially reduce exposure. Pooled TLPT for shared ICT providers extends the economic and operational logic of cooperation but requires a synthesis standard among participants. Causal multi-table synthesis with audit-grade lineage maps to these needs, supporting both pre-TLPT scope validation and pooled testing infrastructure. Infundum is designing CAUSA AI Data Engine for this purpose.