Threat-led penetration testing (TLPT) under DORA Article 26 is a mandatory, authority-designated exercise in which a financial entity’s live production environment is attacked by a controlled red team using real threat intelligence, producing documented evidence that supervisors can evaluate. For organisations whose critical or important functions (CIFs) run on sovereign on-premises infrastructure rather than hyperscaler cloud, the mechanics of scoping, tester provisioning, data handling and closure reporting differ materially from the public-cloud default assumed in many generic TLPT guides.
Which entities face mandatory TLPT and how TIBER-EU fits in
Not every financial entity subject to DORA must undergo TLPT. National competent authorities (NCAs), and in the case of significant credit institutions the ECB acting under SSM Regulation 1024/2013, designate specific entities based on systemic importance and operational scale.
The designation criteria are set out in the Regulatory Technical Standards on TLPT published by the Joint Committee of the European Supervisory Authorities as JC 2024-29. Entities that perform CIFs at significant scale, that are deeply interconnected with financial market infrastructure, or that the NCA considers essential to financial stability are the primary candidates. The three ESAs, EBA, EIOPA and ESMA, each apply JC 2024-29 within their respective sectors, meaning the same legal text governs banks, insurers and investment firms alike.
The TIBER-EU framework, maintained and updated in 2025 by the ECB’s TIBER Cyber Team (TCT), is the mechanism through which designated entities fulfil their Article 26 obligations in a cross-border, harmonised way. A TIBER-EU test completed in one member state can be recognised by the NCA of another, avoiding duplicative exercises for entities operating across multiple jurisdictions.
“TIBER-EU provides a harmonised framework that allows financial institutions to conduct threat intelligence-based ethical red-teaming tests in a controlled, safe and standardised manner across jurisdictions.” (ECB, TIBER Cyber Team)
Scoping when CIFs run on sovereign on-premises infrastructure
Scope definition is where sovereign infrastructure creates the sharpest divergence from cloud-centric TIBER-EU practice. The scope must identify every system, process and third-party dependency that supports the designated CIFs.
On public cloud, scoping conversations typically involve listing cloud accounts, regions and managed services. On sovereign on-premises infrastructure, the equivalent exercise maps physical data centres, network segments, hypervisor layers, on-premises identity providers (Active Directory, self-hosted LDAP or a local IAM platform) and any air-gapped or near-air-gapped zones that process the most sensitive data. The White Team, the internal control group that manages the test without informing operational staff, must document these boundaries in the Generic Threat Landscape (GTL) before the Threat Intelligence Provider (TIP) begins targeted research.
“Financial entities shall, when identifying the scope of a threat-led penetration test, take into account the criticality of the functions and the interconnectedness with third-party ICT service providers.” (Joint Committee of the ESAs, RTS on TLPT JC 2024-29)
One practical implication of sovereign scoping: the absence of cloud-API reconnaissance vectors forces the red team to rely on spear-phishing, physical perimeter weaknesses, and insider-threat simulation as primary entry points. The Targeted Threat Intelligence (TTI) report produced by the TIP must reflect this attack surface accurately, because supervisors will compare the TTI assumptions against the actual attack scenarios executed during the test.
Internal versus external red-team testers: the Article 26(8) constraints
DORA Article 26(8) permits a financial entity to use an internal red team, but only under three cumulative conditions: the team must be organisationally independent of the target environment; the NCA must explicitly authorise the arrangement in writing; and the entity must demonstrate the absence of conflicts of interest.
The updated TIBER-EU framework (ECB, 2025) adds a certification requirement: individual testers, whether internal or external, must hold a recognised offensive-security qualification. The framework does not mandate a single certification body but expects entities to document the qualifications of each tester in the test plan submitted to the NCA.
| Tester type | NCA pre-authorisation required? | Sovereign infrastructure provisioning considerations | Key risk |
|---|---|---|---|
| External Red Team Provider (RTP) | No (but must appear on TIBER approved/recognised list) | Physical or VPN access to isolated segments must be time-limited and logged; no standing cloud credentials | Data exfiltration during test if artefact-handling agreement is inadequate |
| Internal red team | Yes, explicit written authorisation | Easier to provision physically; harder to demonstrate independence to supervisors | Perceived or actual conflict of interest invalidating test findings |
For sovereign infrastructure specifically, external tester provisioning is operationally complex. An RTP that normally operates from its own cloud-connected toolkit must be granted temporary, monitored access to isolated network segments. VPN profiles should be issued for the test window only, revoked immediately on closure, and all remote sessions should be recorded and stored within the entity’s sovereign perimeter.
Control team design, documentation and audit-ready closure reporting
The White Team is the nerve centre of a TIBER-EU test. Its members know the test is occurring; no one else in the entity does. For the test to produce evidence that satisfies the ECB, EBA or an NCA, the White Team must maintain a contemporaneous record of every decision: scope changes, pauses, escalation calls and any “assumed breach” starting conditions.
The TIBER-EU framework specifies a set of mandatory documents. These include the test plan, the GTL, the TTI report, the red-team report, the blue-team report and the closure report. Each document has a defined author (White Team, TIP or RTP), a defined reviewer and a defined recipient. The closure report is the document the NCA actually evaluates; it must summarise findings, map them to the original TTI scenarios and include a remediation roadmap with assigned owners and target dates.
For audit readiness, the White Team should maintain a test log with timestamps accurate to at least one minute, because supervisors examining a post-incident timeline will correlate log entries across SIEM, network captures and the White Team record. Gaps or inconsistencies between these sources are a common reason for findings to be challenged or downgraded during supervisory review.
Tooling and threat intelligence procurement: keeping artefacts inside sovereign jurisdiction
A TIBER-EU test generates sensitive artefacts: reconnaissance data describing the entity’s internal network, proof-of-concept exploit code, credentials captured during the exercise and the TTI report describing the real threat actors most likely to target the entity. All of these are regulated information in the sense that their exposure would cause direct harm.
The TIBER-EU framework requires the TIP and RTP to sign data-handling agreements before work begins. For entities committed to sovereign jurisdiction, these agreements must contain explicit prohibitions on storing or processing artefacts on US-controlled platforms subject to the CLOUD Act or on any infrastructure accessible under FISA Section 702. Practically, this means requiring the TIP and RTP to use European-hosted collaboration environments for deliverable exchange, and prohibiting the use of US-based threat-intelligence platforms for the entity-specific TTI work, even if those platforms are widely used in the industry.
Procurement teams should require prospective TIPs and RTPs to complete a data-residency questionnaire as part of the tender process, and to warrant contractually that no subprocessor outside the agreed jurisdictions will handle test data. The White Team should audit compliance before test closure.
Interaction with NIS-2 Article 21 for dual-regime entities
Some financial entities, particularly those operating payment infrastructure or critical market infrastructure, qualify simultaneously as operators of essential services under NIS-2 Directive (EU) 2022/2555. NIS-2 Article 21 requires appropriate technical and organisational security measures including, for significant entities, regular security testing.
DORA is lex specialis relative to NIS-2 for financial entities: where DORA’s TLPT provisions are more specific, they govern. However, the NIS-2 competent authority (often a national cybersecurity agency rather than the financial NCA) has independent supervisory standing and does not automatically accept a TIBER-EU test as satisfying Article 21.
Entities under both regimes should seek written mutual-recognition confirmation from both authorities before the test cycle begins. If mutual recognition is granted, a single well-documented TIBER-EU test can satisfy both obligations. If it is not, the entity may need to conduct a supplementary NIS-2 test with a different scope, typically focused on network and information systems rather than the financial CIF framing used in TIBER-EU. The compliance calendar should reflect this possibility.
Key figures for context
The financial and operational stakes justify the investment in rigorous TLPT. IBM’s Cost of a Data Breach Report 2024 found the average total cost of a breach globally reached USD 4.88 million, the highest figure recorded in the report’s history. Sophos reported in its State of Ransomware in Financial Services 2024 that 64 percent of financial-sector organisations experienced a ransomware attack in 2023. And the EBA noted that more than 400 significant incident reports were submitted to the ESAs in the first quarter of DORA applicability (January through April 2025), indicating that the regulatory spotlight on ICT resilience is intensifying, not receding.
These figures do not make the case for TLPT on their own. They do illustrate why supervisors regard untested assumptions about resilience as an unacceptable supervisory gap, and why the TIBER-EU methodology, with its insistence on real threat intelligence and live-environment testing, exists as a corrective to checkbox security assessments.
FAQ
Which financial entities must undergo mandatory TLPT under DORA Article 26?
NCAs, and for significant credit institutions the ECB under SSM Regulation 1024/2013, designate specific entities based on criteria in RTS JC 2024-29: systemic importance, operational scale and the criticality of ICT functions. Designation is an explicit act; entities should not assume inclusion or exclusion without written confirmation from their competent authority.
Can a financial entity use its own internal security team as the red team?
DORA Article 26(8) permits it under three cumulative conditions: organisational independence from the target environment, explicit written NCA authorisation, and demonstrated absence of conflict of interest. The updated TIBER-EU framework (ECB, 2025) additionally requires individual tester certification. Sovereign infrastructure does not relax these conditions.
How does sovereign on-premises infrastructure change TIBER-EU scoping?
Scoping must map physical data centres, network segments, hypervisor layers and on-premises identity systems explicitly. Cloud-API reconnaissance techniques are unavailable, so the TTI report must reflect attack surfaces such as spear-phishing, physical perimeter weaknesses and insider-threat simulation. The White Team documents these boundaries in the GTL before the TIP begins work.
How do DORA TLPT obligations interact with NIS-2 Article 21 for dual-regime entities?
DORA is lex specialis and governs where its provisions are more specific. However, the NIS-2 competent authority has independent standing. Entities should seek written mutual-recognition confirmation from both authorities before the test cycle. Without it, a supplementary NIS-2 test may be required alongside the TIBER-EU exercise.
How must test artefacts be handled to keep them within sovereign jurisdiction?
Data-handling agreements with the TIP and RTP must explicitly prohibit storage on US-controlled platforms subject to the CLOUD Act or FISA Section 702. Artefacts should be stored on infrastructure within the entity’s sovereign perimeter or a certified European provider that contractually excludes third-country access. The White Team verifies compliance before the closure report is submitted to the NCA.
Hoe Qsentinel dit oplost
Qsentinel is the managed Nextcloud Enterprise workspace, enhanced by Qsentinel with post-quantum encryption and sovereign private AI, hosted in Switzerland or on-premise, out of reach of the CLOUD Act.