The classic trap
Recital 60 allows pooled testing but under strict conditions. In practice, Luxembourg financial entities sharing a common critical provider (typically a cloud hyperscaler or a core banking vendor) rush into pooled testing to share costs, without formally designating the lead entity, without calibrating the number of participants, and without documenting why an individual TLPT would have degraded service quality. The CSSF, as Luxembourg TLPT authority under the TIBER-LU framework, then rejects the pooled scope and requires individual reruns, delaying the three-year cycle by several months.
The 4 cumulative conditions to document before requesting pooled testing
- Adverse impact justification: demonstrate in writing that an individual TLPT would reasonably impact the quality, security or confidentiality of services delivered by the ICT provider to its other out-of-scope customers (other sectors, third jurisdictions).
- Lead entity designation: a single financial entity takes operational direction of the test, owns the relationship with the external tester and the CSSF, and centralises coordinated blue team and white team.
- Calibration of the number of participants: justify that the participant count remains compatible with testing rigour (no scenario dilution, no loss of granularity on individual flags).
- TLPT objective coverage per participant: each financial entity must find within the pooled scope its own critical or important functions, its own threat intelligence scenarios, and its own remediation evidence.
The contractual trap with the external tester
Recital 60 allows the ICT provider to contract directly with the external tester. This deviation from the standard scheme (where each financial entity contracts its own tester) creates an audit gap: if the tester-provider contract does not reflect the TLPT RTS requirements (tester qualifications, vulnerability handling, evidence retention), participating financial entities remain accountable to the CSSF without having signed the contract. A tripartite flow-down clause is indispensable.
How Luxgap automates this risk
Our Luxgap Pooled TLPT Orchestrator turns the chaotic coordination of a DORA pooled test into a pre-built eligibility file for the CSSF. The tool aggregates in real time the DORA information registers of participating entities, cross-references their critical function mappings with the common ICT provider scope, and automatically generates the adverse impact justification file required by recital 60.
- Detects concentrations on shared ICT providers across multiple Luxembourg financial entities by cross-referencing article 28(3) information registers and alerts as soon as pooled testing becomes eligible.
- Computes a pooled testing eligibility score based on shared criticality, optimal participant count and risk of impact on the provider's out-of-scope customers.
- Generates the pre-filled, defensible CSSF justification file demonstrating that individual TLPT would reasonably have degraded service delivered to other customers.
- Produces the designated lead entity mandate, the consolidated scoping document and the white team / blue team / red team RACI matrix aligned with TIBER-LU.
- Verifies compliance of the tripartite ICT provider - external tester - financial entities contract against the TLPT RTS and flags missing clauses (tester qualifications, responsible disclosure, 5-year evidence retention).
- Tracks the three-year cycle of each participant and alerts on desynchronisations that would render the next pooled test ineligible.
Available as part of a Luxgap CISO mandate or as a dedicated SaaS brick depending on your perimeter. Request a tailored quote and our teams will prepare a demonstration on your real shared ICT providers, with a free 48-hour white audit to measure your pooled testing eligibility before any engagement.
