Cyber Stress Testing, TLPT and Sovereign Infrastructure Under DORA

Cyber stress testing, in the regulatory sense used by ENISA and DORA, is a structured process in which an organisation’s ICT systems are subjected to realistic adversarial scenarios, under controlled conditions, to measure whether defences hold and whether recovery procedures work as documented. For European financial entities and critical-sector operators, this is no longer an optional best practice: it is a legal obligation with supervisory consequences, documentation requirements and, increasingly, a direct dependency on where infrastructure physically sits and under whose legal jurisdiction data resides during the test.

What the ENISA 2025 Handbook Requires

The ENISA Handbook for Cyber Stress Testing (2025) is addressed primarily to national competent authorities and sector regulators, not directly to individual organisations. It sets out methodology for designing and executing sector-wide or cross-sector cyber exercises, including tabletop simulations, hybrid drills and full technical stress tests that probe interconnections between regulated entities.

For essential entities in critical sectors, the Handbook creates indirect but real obligations. Where a national authority runs an exercise under the Handbook’s framework, entities designated as participants are expected to contribute data, staff and system access. Authorities are required to define clear scope, share threat scenarios derived from current intelligence, and produce a consolidated after-action report. ENISA specifies that exercises must be proportionate to the systemic risk profile of the sector being tested, which means entities operating core financial market infrastructure or healthcare systems face more demanding exercise scenarios than smaller operators.

ENISA states: “Cyber stress testing at the systemic level requires coordinated methodology, shared threat intelligence and clear governance between national authorities and regulated entities.”

DORA Article 26 TLPT and the TIBER-EU Framework

DORA Article 26, which became directly applicable across all EU Member States on 17 January 2025, mandates threat-led penetration testing for financial entities identified as significant by their competent authority. The test must use actual threat intelligence, target live production systems or a sufficiently representative replica, and be conducted by an approved external red team, with the blue team operating under realistic conditions (meaning, in most cases, without advance warning of the test start).

The TIBER-EU Framework, developed by the European Central Bank and adopted by numerous national central banks, provides the procedural template that DORA TLPT largely follows. TIBER-EU distinguishes three phases: a preparation phase in which scope and threat intelligence provider are agreed with the authority; a testing phase in which the red team executes attack scenarios drawn from the threat intelligence report; and a closure phase in which findings are validated, remediated and reported to the authority. DORA Article 26 incorporates this logic and adds explicit provisions for mutual recognition of test results across Member States, reducing the need for repeated exercises when a single entity operates across multiple jurisdictions.

The European Banking Authority has noted: “Threat-led penetration testing is one of the most powerful tools available to financial authorities to assess real-world resilience, but it requires a rigorous, controlled framework to avoid unintended harm to live systems.”

Sovereign Infrastructure Versus Public Cloud in TLPT Scope

The choice between sovereign on-premises infrastructure and public cloud hosting has direct consequences for how TLPT scope is defined and executed. When production systems run on infrastructure controlled by a US-headquartered hyperscaler, the threat intelligence report and red team findings may contain information about vulnerabilities in that provider’s shared services, raising questions about disclosure obligations and data handling that sit outside the financial entity’s control. The US CLOUD Act, FISA 702 and related instruments mean that data processed on US-controlled infrastructure, including test artefacts, logs and vulnerability reports, can be subject to compelled disclosure to US authorities without the entity’s knowledge.

Sovereign on-premises infrastructure, by contrast, allows the entity to define a physically bounded test perimeter, retain all artefacts under its own custody and demonstrate to the competent authority that no test data crossed a jurisdictional boundary. This is particularly relevant for the threat intelligence report, which by its nature contains sensitive information about the entity’s attack surface.

Technical and Organisational Conditions for a Valid Sovereign Test Environment

For sovereign infrastructure to serve as a valid TLPT environment, four conditions must be met concurrently. First, the test environment must replicate the production architecture at sufficient fidelity: the same operating systems, network topology, authentication mechanisms and application versions. A stripped-down clone will produce findings that do not translate to production risk, which competent authorities will reject.

Second, network segmentation between the test environment and live production must be documented and verifiable. This means physical separation or, at minimum, hardware-enforced VLAN segmentation with firewall rules that can be demonstrated to the authority’s technical reviewer. Logical separation controlled entirely by software on a shared host is insufficient for TLPT purposes.

Third, all personnel with access to test data, including the threat intelligence report, the red team’s findings and blue team logs, must be identified in the test plan, and their access must be revoked upon closure. Data handling procedures must prohibit transfer to any system outside the agreed perimeter.

Fourth, the entity must be able to demonstrate that no personal data or confidential business information processed during the test was transferred to infrastructure outside EU jurisdiction. This is the point at which sovereign hosting, whether self-operated or provided by a Swiss or EU-domiciled provider operating under the revised Swiss Federal Act on Data Protection (FADP) or the GDPR, creates a compliance advantage that public cloud cannot replicate without contractual workarounds of uncertain enforceability.

Documenting for DORA and NIS-2 Article 21 Simultaneously

NIS-2 Article 21 requires essential and important entities to implement risk-management measures covering, among other things, security testing and audit. The documentation standard expected under NIS-2 is not identical to DORA’s TLPT record-keeping requirements, but the artefacts overlap substantially. A CISO who structures TLPT documentation with both frameworks in mind avoids duplication and creates a single audit-ready evidence package.

The minimum documentation set should include: a board-approved test plan specifying scope, objectives and red team mandate; the threat intelligence report produced by the TLPT-approved intelligence provider; the red team report including attack paths, dwell time and systems compromised; the blue team report covering detection times and response actions; a remediation register with owners, deadlines and status indicators; and board minutes or equivalent senior management sign-off confirming review of findings and approval of the remediation plan. Under DORA, this package must be submitted to the competent authority. Under NIS-2, it must be available on request and integrated into the entity’s broader security policy documentation.

TLPT Versus Continuous Monitoring: Two Different Instruments

TLPT is a periodic, bounded exercise: it produces a point-in-time assessment of whether a specific set of realistic attack scenarios can be detected and contained. Continuous monitoring and adversarial simulation, such as automated red team tooling, breach-and-attack simulation platforms or managed detection and response with active threat hunting, operate on a different logic. They detect drift, misconfigurations and new exposures as they emerge.

Sovereign infrastructure operators should treat the two instruments as complementary rather than substitutable. TLPT satisfies the DORA Article 26 obligation and provides the deep, intelligence-driven narrative that regulators require. Continuous monitoring provides the between-test assurance that the remediation actions from the last TLPT exercise have held and that no new attack surface has opened. IBM’s 2024 Cost of a Data Breach Report found that the average cost of a data breach globally reached USD 4.88 million, the highest ever recorded, underscoring that the gap between TLPT cycles is precisely the period during which undetected compromise becomes financially catastrophic.

ENISA’s 2023 Threat Landscape recorded 2,580 significant incidents across EU Member States, a figure that illustrates that threat volume does not pause between annual exercises. The ESRB has noted that over 50 percent of major ICT-related incidents reported to financial supervisors involved third-party ICT providers, which reinforces why TLPT scope must extend to critical third-party dependencies and why continuous monitoring must cover supply chain signals, not only internal perimeters.

Cross-Border TLPT Coordination Under DORA’s Joint Examination Provisions

DORA provides that where a financial entity operates across multiple Member States, the relevant competent authorities may jointly conduct or recognise a single TLPT exercise, avoiding duplication. In practice, this requires a lead authority, a formal cooperation agreement and a shared understanding of how findings will be treated in each jurisdiction. The critical challenge for sovereign infrastructure operators is ensuring that the shared data room used by the joint examination team, which will contain the threat intelligence report and red team findings, does not itself become a cross-jurisdictional data transfer problem.

The practical solution is to establish a dedicated, EU-hosted secure document exchange environment governed by a written data-sharing agreement that names permitted users, prohibits onward transfer and requires deletion of all artefacts upon exercise closure. All participating authorities and the external red team must access materials through this environment exclusively. Where a Swiss-hosted sovereign environment is used, the revised FADP’s adequacy alignment with GDPR means that Swiss-to-EU transfers for supervision purposes remain lawful, provided the controller documents the legal basis correctly.

Building a Resilience Programme Around These Obligations

The organisations that navigate DORA TLPT and the ENISA 2025 Handbook most successfully are those that treat stress testing not as a compliance checkbox but as an operational input. Findings from TLPT exercises should feed directly into the entity’s ICT risk register, inform the next cycle of infrastructure investment decisions and be referenced explicitly in board-level risk appetite statements. The documentation created for supervisory purposes then becomes a genuine management tool rather than a parallel paper trail maintained only for inspections.

For CISOs operating sovereign infrastructure, the legal clarity of a jurisdiction-controlled test environment, combined with rigorous documentation mapped to both DORA and NIS-2 Article 21, provides a defensible position with regulators in any Member State. It also avoids the structural problem that public cloud TLPT engagements create: the moment sensitive test artefacts touch infrastructure subject to foreign jurisdiction, the compliance argument becomes dependent on contractual protections rather than legal certainty.

FAQ

Which financial entities are subject to TLPT under DORA Article 26?

DORA Article 26 applies to significant financial entities as identified by competent authorities, based on criteria including systemic importance, scale of ICT operations and cross-border exposure. Competent authorities notify entities directly; not all financial entities under DORA’s general scope are automatically required to conduct TLPT.

Can a TLPT exercise be conducted entirely within a sovereign on-premises environment?

Yes. Sovereign on-premises infrastructure can form a valid, isolated test environment provided it replicates production architecture at sufficient fidelity, keeps all test artefacts and intelligence reports within the same jurisdictional boundary, and documents network segmentation and data-handling procedures in the test plan submitted to the competent authority.

How does the ENISA 2025 Handbook for Cyber Stress Testing differ from DORA TLPT?

The ENISA Handbook targets national authorities conducting sector-wide or cross-sector exercises and establishes methodology for systemic resilience assessment. DORA TLPT is an entity-level obligation driven by a competent authority acting on a specific financial entity. The two frameworks are complementary: the Handbook informs national exercise design, while DORA TLPT governs individual firm-level testing.

What documentation must a CISO produce to satisfy both DORA supervisory expectations and NIS-2 Article 21?

The CISO must produce a board-approved test plan, a threat intelligence report from the approved provider, red team and blue team reports, a remediation register with owners and deadlines, and evidence of board-level review. NIS-2 Article 21 additionally requires that risk-management measures, including testing results, are documented as part of the organisation’s overall security policy and available to the national authority on request.

How should multi-Member-State organisations handle cross-border TLPT data without exposing it to foreign jurisdiction?

DORA provides for joint examinations coordinated by a lead authority. Organisations should establish a dedicated secure document exchange environment hosted within the EU or under an adequacy-aligned jurisdiction such as Switzerland, governed by a data-sharing agreement that restricts access to named personnel and prohibits transfer to non-EU infrastructure. All threat intelligence, test artefacts and findings must remain on infrastructure subject exclusively to EU or equivalent law throughout the exercise.