Le piège classique
La tentation est forte de proposer un périmètre TLPT 'safe' : un sous-ensemble bien delimite, des systèmes secondaires, ou pire, une replique de production. La CSSF et la BCL, en tant qu'autorités TIBER-LU, rejettent ces périmètrès edulcores et exigent que les fonctions critiques ou importantes identifiées au titre de DORA art. 8 soient effectivement testées en production réelle. Le second piège concerne les prestataires TIC critiques externalisés : les oublier du périmètre revient a tester une coquille vide, puisque l'attaquant réel pivotera précisément par Azure, AWS, Swift ou votre core banking infogere. La circulaire CSSF 25/882 et le RTS 2025/532 imposent que ces tiers soient cartographies et, lorsque pertinent, inclus dans le scope TLPT.
Ce que la CSSF et la BCL valident réellement dans votre scoping document
- La cohérence entre les fonctions critiques déclarées au registre DORA art. 8 et celles proposées au TLPT (toute omission est un signal rouge).
- La présence des systèmes de production réels, pas des environnements de pre-production ou de UAT, avec preuve technique (CMDB, flux réels, données clients réelles).
- L'inclusion des prestataires TIC critiques conformément à DORA art. 28-30 et leurs clauses contractuelles (droits d'audit et de test, circulaire CSSF 22/806).
- La justification documentée de toute exclusion : un système legacy non testable doit être traite via une mesure compensatoire, pas simplement raye du scope.
- L'articulation avec la circulaire CSSF 20/750 : les findings TLPT doivent remonter dans le dispositif de gestion des risques TIC existant, pas vivre dans un silo.
- La chaîne de pivot réaliste : si votre cloud provider hébergé la fonction critique, le red team doit pouvoir y acceder dans le scénario, même si le test technique s'arrete a la frontière contractuelle.
Comment Luxgap automatise ce risque
Notre Luxgap TLPT Scope Architect transforme la rédaction du scoping document, exercice habituellement manuel et chronophage de 6 a 10 semaines, en un assemblage automatise opposable a la CSSF et a la BCL. L'outil croise votre registre DORA art. 8, votre CMDB (ServiceNow, Lansweeper, Device42), vos contrats fournisseurs Odoo ou SAP Ariba et vos flux réseau Defender for Cloud / Sentinel pour reconstituer la véritable empreinte de production de chaque fonction critique, y compris les dépendances tierces que personne n'a documentées.
- Détecte automatiquement les fonctions critiques sous-déclarées en comparant le registre DORA art. 8 aux flux applicatifs réels observes via Azure Sentinel, CrowdStrike ou Wazuh.
- Cartographie la chaîne complète de prestataires TIC critiques (sous-traitants de rang 2 et 3 inclus) en exploitant la circulaire CSSF 22/806 et le RTS 2025/532.
- Distingue automatiquement les environnements de production réels des environnements de test via empreinte DNS, certificats TLS, volumes transactionnels et données clients réelles.
- Génère le scoping document pre-rempli au format TIBER-LU Implementation Document du 20 juin 2025, prêt a soumettre au TCT (TLPT Cyber Team) de la BCL.
- Produit la justification documentée de chaque inclusion et exclusion, avec mesures compensatoires proposées pour les systèmes legacy non testables.
- Alimente directement la circulaire 20/750 en preparant le canal de remédiation post-TLPT vers votre dispositif de gestion des risques TIC.
Disponible en complément d'un mandat CISO Luxgap ou en brique SaaS dédiée selon votre périmètre. Demandez un devis personnalisé et nos équipes préparent une démonstration sur votre périmètre réel, avec un audit blanc gratuit sous 48h pour mesurer l'écart entre votre registre DORA declare et votre exposition de production effective avant tout engagement.
