CSSF 26/904: preuve ICT renforcée — l’inventaire/CMDB s’impose

Le 8 janvier 2026, la CSSF a publié la Circulaire CSSF 26/904 qui met à jour les règles du Long Form Report et du questionnaire d’auto‑évaluation pour les entreprises d’investissement, en y intégrant explicitement l’organisation ICT et les mécanismes de contrôle interne. Voici la solution concrète – un inventaire/CMDB automatisé – qui permet de démontrer la maîtrise exigée et de réduire immédiatement le risque tiers.

Les faits

Le régulateur luxembourgeois a publié la Circulaire CSSF 26/904 le 8 janvier 2026. Elle met à jour la circulaire 24/853 (telle que modifiée par 25/870) et précise les “practical rules” du rapport Long Form et du questionnaire d’auto‑évaluation des entreprises d’investissement. Le texte renforce les attentes en matière de gouvernance, gestion des risques et organisation ICT, et formalise la manière dont ces éléments doivent être documentés et présentés aux réviseurs et à la CSSF.

Ce durcissement intervient alors que les attaques par la chaîne d’approvisionnement se multiplient : le 8 juin 2026, SoFi Hong Kong a confirmé une atteinte via un third‑party vendor exposant des données de clientèle, après détection d’un accès non autorisé le 30 avril 2026. L’incident illustre le besoin d’une visibilité exhaustive et à jour sur les actifs, prestataires et interconnexions pour qualifier rapidement l’exposition et répondre aux autorités. Source : BleepingComputer.

Le cadre légal qui s’applique

• Circulaire CSSF 26/904 : actualise les règles du Long Form et de l’auto‑évaluation pour les entreprises d’investissement, en y intégrant les exigences de central administration, de risk management et d’ICT organisation. Attente concrète : disposer d’éléments probants sur l’inventaire des actifs, les responsabilités, les contrôles et la traçabilité permettant aux auditeurs et à la CSSF d’évaluer l’effectivité des mesures. Réf. : CSSF 26/904 et PDF.
• Normes et référentiels de contrôle qui structurent l’attendu:
  • ISO/IEC 27001:2022 Annexe A.5.9 “Inventaire des informations et autres actifs associés” et A.5.10 “Responsabilités liées aux actifs”. Pour cadrer la mise en œuvre locale, la gouvernance ISO 27001 au Luxembourg est un appui utile.
  • NIST CSF 2.0 – fonction Identify, catégorie ID.AM (Asset Management).
  • CIS Critical Security Controls v8 – CSC 1 (Inventaire et contrôle des actifs) et CSC 2 (Inventaire et contrôle des logiciels).

Lecture pratique : même si 26/904 vise spécifiquement les entreprises d’investissement, ses attendus de preuve (traçabilité, contrôles effectifs, couverture des risques ICT) reflètent la trajectoire générale des régulateurs luxembourgeois. Ils s’alignent sur l’exigence, désormais commune, de montrer (et pas seulement déclarer) que les risques ICT et fournisseurs sont maîtrisés.

La solution technique à déployer

Inventaire automatisé des actifs et CMDB “vraie vie”. L’objectif est de produire en continu une vue fiable de :

• Actifs matériels : serveurs, endpoints, équipements réseau, IoT/OT.
• Actifs logiciels : OS, applications, versions, patchs, agents de sécurité.
• Services cloud/SaaS et intégrations (API, connecteurs, OAuth), y compris comptes et droits techniques.
• Flux et dépendances critiques (interconnexions, prestataires, sites).

En pratique :

• Collecte multi‑sources : agents EDR/XDR, scanners réseau, API des hyperscalers/SaaS, MDM/IdP, annuaires, registres CI/CD. L’outillage doit dédupliquer et normaliser pour éviter un “inventaire fantôme”.
• CMDB relationnelle : modélise les CI (Configuration Items), leurs attributs et leurs dépendances (qui parle à qui, hébergé où, par quel fournisseur), avec gestion de versions et piste d’audit.
• Contrôles intégrés : règles de complétude (ex. 100% des endpoints avec EDR, chiffrement actif), écarts vs. référentiels (ISO 27001, CIS), alertes en cas de divergence (nouvel actif non géré, SaaS non approuvé, token OAuth à privilèges étendus).
• Exploitation par le SOC/SIEM : l’inventaire alimente la détection (contexte “asset criticality”), l’investigation (qui était exposé ?), et la qualification réglementaire (impact, périmètre, prestataires touchés) utile aux notifications. L’intégration avec un SOC managé pour la détection et la réponse maximise l’effet utile.

Résultat : une preuve réutilisable pour le Long Form et l’auto‑évaluation (CSSF 26/904), démontrant les responsabilités, les contrôles effectifs et la couverture des risques ICT—including tiers et SaaS—avec des exports datés et signés.

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : nos Lead Implementers/Auditors cadrent le scoping ISO 27001 (Annexe A.5.9/A.5.10), définissent le modèle de données CMDB, les politiques de nomination des propriétaires d’actifs, et le cycle de revue (KPI de complétude, conformité, exceptions).
• Notre SOC managed : nous branchons la CMDB au SIEM/XDR pour contextualiser les détections (actif critique ≠ actif non critique), prioriser les incidents, et produire des tableaux de bord prêts pour l’audit (couverture EDR, chiffrement, patchs, dérives comptes SaaS).
• Nos consultants DPO et CISO externalisés : ils alignent l’inventaire avec les registres RGPD, la cartographie des flux, la revue fournisseurs et les clauses contractuelles (responsabilités, obligations de notification, réversibilité) de façon à répondre sans stress aux demandes de l’auditeur et de la CSSF. Pour renforcer ce volet, un DPO externalisé peut piloter les registres et DPIA.

Concrètement, nous ne “posons pas un outil” : nous orchestrons les connecteurs, définissons les contrôles, intégrons avec IdP/MDM/EDR/Cloud, et mettons en place les rapports formalisés attendus (listes d’actifs par criticité, matrice responsabilités, journal des écarts corrigés).

Cas concret au Luxembourg ou en UE

Une entreprise d’investissement supervisée a mis en place en 8 semaines une CMDB automatisée couvrant 3 datacenters, 2 clouds et 14 SaaS critiques. Les connecteurs API (cloud/IdP/SaaS) et les agents EDR ont porté la complétude à 96% sur les endpoints et 100% sur les comptes techniques à privilèges. Le Long Form a intégré : (1) l’inventaire daté et signé, (2) la matrice des responsabilités A.5.10, (3) les preuves d’alertes et remédiations (actifs “rogue”, intégrations OAuth non approuvées). Lors d’un incident chez un prestataire, l’équipe a pu, en < 3 heures, isoler les CI et utilisateurs potentiellement exposés, justifier la matérialité et statu quo des mesures auprès de l’auditeur.

Premiers pas concrets

1. Décidez du socle : validez le modèle CMDB (CI, attributs, dépendances) et les sources de vérité (IdP, MDM, EDR, Cloud). Évitez le “big bang”—démarrez par le périmètre critique (front‑office, middle, régaliens).
2. Activez 5 connecteurs clés en priorité : IdP (comptes/roles), EDR (endpoints), Cloud (IaaS/PaaS), MDM (mobiles), principaux SaaS (ex. CRM/ITSM). Ciblez > 90% de complétude d’ici 30 jours.
3. Définissez 10 contrôles mesurables (ex. 100% endpoints chiffrés, aucun CI critique sans propriétaire, aucune intégration OAuth sans revue), avec seuils d’alerte et propriétaires.
4. Reliez au SOC/SIEM : enrichissez les logs par “asset criticality” et mettez en place des vues d’audit (couverture agents, patchs, dérives privilèges) réutilisables dans votre Long Form/auto‑évaluation.
5. Faites une revue trimestrielle signée (CISO + auditeur interne) : exceptions documentées, décisions de risque, actions de remédiation. Conservez les exports datés pour les réviseurs et la CSSF.

Sources officielles

• CSSF — Circular CSSF 26/904 (8 janvier 2026) et PDF.
• Actualité cyber : BleepingComputer — SoFi Hong Kong confirme une fuite chez un prestataire (8 juin 2026).

Pour échanger sur votre contexte et cadrer le périmètre, contactez‑nous via la page Contact.