NIS2, DORA, CIR 2024/2690 : ce que les textes exigent vraiment — et ce que votre plateforme doit pouvoir prouver
Trois textes européens font des prestataires de SOC managé une classe régulée à part entière, mettent un chronomètre sur la classification des incidents chez les entités financières, et écrivent noir sur blanc des obligations de monitoring et de conservation des logs. Les formulations exactes, les dates, et le tri entre les textes et le discours commercial.
Si vous exploitez un SOC managé en Europe, vous n'êtes plus le fournisseur d'une entité régulée : vous en êtes une. 24 heures pour l'alerte précoce, 72 heures pour la notification, des sanctions indexées sur votre chiffre d'affaires. Voici les formulations exactes, les dates exactes, et le tri entre ce que disent les textes et ce que racontent les plaquettes.
NIS2 vous nomme
La directive (UE) 2022/2555 — NIS2 — élargit considérablement le périmètre des entités régulées et cite explicitement, à son annexe I, la gestion des services TIC (interentreprises). Les prestataires de services de sécurité managés y figurent donc comme entités régulées, et non comme sous-traitants d'entités régulées. L'article 23 fixe le tempo : alerte précoce à 24 heures, notification à 72 heures, rapport final sous un mois. L'article 34 indexe les sanctions sur le chiffre d'affaires, plus lourdement pour les entités essentielles que pour les entités importantes.
Reste la transposition, et c'est là que ça coince. À l'heure où nous écrivons, aucun régime NIS2 n'est opérationnel en France : la loi résilience n'est pas promulguée, et la Commission a ouvert une procédure d'infraction contre plusieurs États membres pour ce retard. En pratique, les entités françaises se préparent aujourd'hui à partir du Référentiel Cyber France de l'ANSSI et du portail MonEspaceNIS2. L'éditeur qui vous affirme que la loi française s'applique déjà se trompe ; celui qui vous conseille d'attendre se trompe tout autant, puisque c'est ce référentiel qui servira de base à l'audit.
Le CIR (UE) 2024/2690 fait du monitoring une obligation légale, et vise les MSSP par leur nom
La meilleure description de ce qu'une plateforme d'opérations de sécurité doit faire ne vient pas d'un cabinet d'analystes. Elle vient du règlement d'exécution (UE) 2024/2690 de la Commission, qui s'applique directement aux prestataires de services de sécurité managés et impose des procédures et des outils « pour surveiller et journaliser les activités sur leurs réseaux et systèmes d'information afin de détecter des événements » — le trafic, le cycle de vie des comptes, l'authentification, l'ensemble des accès privilégiés, la configuration, l'accès aux sauvegardes — et qui exige que les logs soient conservés et « protégés contre tout accès ou toute modification non autorisés ».
Autrement dit, monitorer, détecter et protéger la trace ne relèvent plus des bonnes pratiques : ce sont des obligations, et les MSSP sont la classe visée. Une réserve, tout de même : le texte ne fixe aucune durée de conservation. Les six à douze mois qui circulent dans les présentations d'éditeurs sont des affirmations d'éditeurs, pas la loi.
Collecter les logs, c'est la partie que vous avez déjà réglée. Le reste est nettement plus difficile : que l'activité soit surveillée, que les événements soient détectés, et que la trace résiste à toute modification. Le texte cite six catégories d'activité : un trou dans votre couverture de détection cesse d'être un sujet d'ingénierie pour devenir un constat d'audit.
C'est la couche que Seculogik pose au-dessus de la stack que vous exploitez déjà, sans rien y remplacer et sans rien changer à votre installation. Nous lisons les SIEM et les bases open source — ClickHouse, Elastic / ELK, OpenSearch, Wazuh — ainsi que les plateformes du marché déjà présentes dans votre parc : Splunk, Microsoft Sentinel, CrowdStrike, Microsoft Defender, SentinelOne, Cortex XDR, Fortinet, Okta, Entra ID, AWS et Azure. Si votre source manque à l'appel, nous construisons le connecteur — ou vous poussez vos événements dans le webhook générique et les mappez une bonne fois pour toutes.
Le chronomètre DORA démarre à la classification
Le règlement (UE) 2022/2554 — DORA — s'applique déjà aux entités financières, sans période de transition. Le délai est de quatre heures, à compter du moment où un incident est classé comme majeur.
L'asymétrie avec NIS2 mérite qu'on s'y arrête. Dans NIS2, le chronomètre démarre à la connaissance de l'incident ; dans DORA, à la classification. Il faut donc classer vite et le prouver : les quatre heures partent de l'instant où un verdict dit majeur, et la trace de décision le date.
C'est ici que le vocabulaire doit être exact. Un dossier, c'est ce qui entre dans la file : trié, attribué, et le plus souvent classé sans suite — un faux positif. Un incident, c'est un objet juridique assorti d'une obligation de notification. La plupart des dossiers n'en deviennent jamais un.
Décider lesquels le deviennent démarre le chronomètre — et c'est souvent un analyste N1 qui tranche, à trois heures du matin, avec la file qui monte. Le dossier doit donc lui arriver avec un verdict déjà rendu, l'impact métier qui le fonde, et l'horodatage des deux.
Quand le régulateur demande, la réponse est déjà écrite
DORA vous laisse quatre heures à compter de la classification. Ce n'est tenable que si celle-ci se fait d'elle-même, preuves consignées au fil de l'eau. Déduplication et corrélation réduisent le flot d'alertes à une liste courte de dossiers qualifiés, chacun classé, horodaté et expliqué.
Seculogik produit ensuite les artefacts qu'un régulateur ou un auditeur réclame vraiment : des grilles d'évaluation NIS2 et DORA, aux côtés de NIST CSF, ISO 27001 et RGPD (module SOC Reporting), et des dossiers de preuves qui marquent chaque contrôle comme mis en œuvre, en écart ou insuffisant — et qui précisent dès leur page de garde qu'ils constituent un signal de couverture auto-évalué, non une attestation.
En dessous : une piste d'audit dont toute altération se détecte ; des échéances SLA qui enregistrent prise en charge et résolution, les deux horodatages d'où se calcule le MTTR ; et une trace de décision qui dit quand un dossier a été classé, sur quelles preuves, et ce qui aurait changé l'issue.
C'est ce dernier point qui sépare un rapport d'une défense. Le jour où un régulateur ou un auditeur demande pourquoi cet incident a été qualifié de majeur au bout de quatre heures, la réponse est déjà écrite, horodatée, et personne n'y a touché après coup.
Nous ne déclarons pas à l'autorité à votre place, et nous ne le ferons jamais. L'acte juridique appartient à l'entité qui en porte la responsabilité, et un outil qui laisse croire qu'il a déclaré pour vous est un outil qui vous fera manquer la déclaration. La frontière est donc tracée volontairement : la classification, les preuves et les horodatages sont de notre côté ; la notification reste du vôtre.
Le Cyber Resilience Act engage aussi l'éditeur
Le règlement (UE) 2024/2847 — le CRA — déclenche ses obligations de déclaration pour les fabricants le 11 septembre 2026 : les vulnérabilités activement exploitées et les incidents graves se signalent à l'ENISA et au CSIRT national, avec une alerte précoce à 24 heures. Les exigences essentielles complètes et le marquage CE suivent le 11 décembre 2027.
Cela nous engage en tant que fabricant, et pas seulement les entités auxquelles nous vendons. C'est la raison pour laquelle chaque version est livrée avec une nomenclature logicielle (SBOM), une politique publiée de divulgation coordonnée des vulnérabilités, et des mises à jour signées cryptographiquement, appliquées par votre administrateur et par lui seul, et annulées automatiquement si la plateforme échoue ensuite à son propre contrôle de santé.
Ce que vous pouvez présenter à un auditeur
Nous ne détenons aucune qualification ANSSI, ni CSPN, ni SecNumCloud, et nous ne laisserons rien entendre de tel : une évaluation de préparation figure sur notre feuille de route, une revendication non. Vérifiez vous-même dans le catalogue de l'ANSSI toute qualification revendiquée devant vous, et gardez en tête qu'être hébergé chez un prestataire qualifié n'est pas être qualifié. Appliquez ce test à chaque éditeur de votre liste restreinte, nous compris.
La souveraineté est un ticket d'entrée, pas un produit. C'est ce qui permet à un MSSP européen, qui ne peut pas envoyer la télémétrie de ses clients vers un modèle exploité par un fournisseur américain, de nous garder sur sa liste ; ce n'est pas ce qui l'y fera rester. Ce qui l'y fera rester, c'est que le backlog rétrécit et que chaque dossier arrive avec le raisonnement déjà écrit.
Voilà donc ce que vous pouvez présenter à un auditeur aujourd'hui, avec Seculogik. La télémétrie reste par défaut sur votre propre infrastructure. L'analyste IA — SIROC, le module Advanced AI — tourne on-prem, sauf si un administrateur active une clé cloud.
Ce qui sort est masqué au préalable, puis consigné dans un registre que personne ne peut modifier. Chaque décision porte une trace horodatée. Et l'éditeur derrière la plateforme est une entité européenne, soumise aux mêmes textes que vous.
Ce sont les classifications qui tiennent les échéances, pas la paperasse. La suite, c'est la mécanique qui les produit : voyez comment fonctionne la couche de verdict — alertes → dossier → décisions — et ce qui est déjà écrit au moment où le chronomètre démarre.