La correspondance CIS NIS2 répond à un problème très concret. Une entreprise européenne de taille moyenne, qui exploite Microsoft 365 ou Google Workspace, fait aujourd’hui face à quatre textes qui se superposent. NIS2 si elle relève d’un secteur concerné, DORA si elle touche au financier, ISO 27001 si un client l’exige, et le RGPD en toutes circonstances. S’y ajoute enfin le référentiel technique sur lequel tout le monde s’appuie sans le nommer, les benchmarks du Center for Internet Security.
Le réflexe consiste à traiter ces textes séparément. Un projet NIS2, un projet ISO, un audit RGPD. Trois prestataires, trois calendriers, et trois séries d’entretiens qui posent les mêmes questions aux mêmes personnes. Au bout, on obtient donc trois documents qui décrivent le même environnement sous trois vocabulaires différents.
Ce que ces textes demandent réellement
Aucun de ces textes ne décrit une configuration. C’est en effet ce qui rend leur application difficile, et c’est aussi ce qui rend la correspondance possible.
NIS2 énumère à son article 21 des mesures de gestion des risques. Elles s’adressent aux entités essentielles et importantes, et elles se formulent en objectifs : politique d’analyse des risques, traitement des incidents, continuité d’activité, sécurité de la chaîne d’approvisionnement, contrôle d’accès, hygiène informatique.
DORA raisonne ensuite en résilience opérationnelle numérique. Le règlement insiste notamment sur la maîtrise des prestataires et sur la capacité à démontrer que les dispositifs fonctionnent.
ISO 27001 raisonne quant à elle en système de management, avec une annexe de mesures et une exigence permanente de preuve d’efficacité.
Le RGPD, enfin, raisonne en protection des données. Il impose des mesures techniques appropriées sans jamais dire lesquelles.
Ainsi, aucun des quatre ne vous dira quel réglage activer dans votre tenant. Le CIS, lui, ne fait que cela.
Le point où les textes se rejoignent
Une exception éclaire toute la mécanique. NIS2 nomme en effet explicitement, à son article 21 paragraphe 2 point j, l’usage de solutions d’authentification à plusieurs facteurs ou d’authentification continue. C’est l’une des très rares mesures techniques que la directive désigne par son nom.
Or l’authentification multifacteur figure également dans les mesures de l’annexe ISO 27001, dans les attentes de DORA en matière de contrôle d’accès, dans la doctrine de la CNIL sur les mesures techniques appropriées, et dans plusieurs recommandations du benchmark CIS applicable à votre plateforme.
Un seul réglage constaté, l’état réel de l’authentification forte sur les comptes à privilèges, alimente donc simultanément quatre exigences issues de quatre textes. Ce n’est pas une astuce de présentation. En réalité, c’est la structure même de ces référentiels : ils décrivent les mêmes risques avec des vocabulaires professionnels distincts.
Ce raisonnement se reproduit ensuite sur la journalisation, sur la gestion des comptes à privilèges, sur le partage externe de documents, sur le chiffrement et sur la protection de la messagerie. À chaque fois, un constat technique unique répond à plusieurs obligations.
Ce que la correspondance CIS NIS2 ne fait pas
Elle ne vous dispense d’aucun texte, et il faut le dire clairement.
La gouvernance ne se mappe pas. NIS2 impose ainsi que l’organe de direction approuve les mesures et se forme. ISO 27001 impose de son côté un système de management vivant, avec revue de direction et amélioration continue. DORA impose par ailleurs une gestion contractuelle des prestataires critiques. Le RGPD impose enfin un registre et une base légale. Aucune configuration technique ne répond à ces exigences.
Elle ne remplace pas non plus une analyse de risque. En effet, deux organisations qui partagent la même configuration ne portent pas le même risque, puisqu’elles ne détiennent pas les mêmes actifs ni la même exposition.
Ce qu’elle fait, et c’est déjà considérable, c’est traiter en une seule fois la couche technique commune aux quatre textes. Elle réduit donc le travail redondant, supprime les entretiens répétés, et donne un socle de preuves unique que chaque référentiel vient lire selon sa propre grille.
La condition qui rend la correspondance recevable
Une correspondance ne vaut que par la qualité du constat qui l’alimente. Un tableau qui relie des exigences à des mesures déclarées reste un exercice documentaire. En revanche, un tableau qui relie des exigences à des réglages effectivement mesurés, à une date donnée, constitue un élément probant.
Trois propriétés font alors la différence devant un auditeur.
La date. Un constat sans horodatage ne prouve rien sur la durée, et c’est justement la durée qui intéresse le régulateur.
La rejouabilité. Si la même mesure relancée six mois plus tard ne rend pas un résultat comparable, l’écart observé ne veut alors rien dire.
L’origine. Un constat produit par lecture directe de la configuration se vérifie. À l’inverse, un constat produit par déclaration se croit ou ne se croit pas.
C’est là que la correspondance cesse d’être un tableau pour devenir un dossier de preuves.
Ce que cela change dans la conduite d’un projet
L’ordre habituel part du texte, le décline en exigences, puis va chercher dans l’environnement ce qui y répond. C’est long, et cela produit beaucoup de discussion pour peu de constats.
L’ordre inverse va plus vite. On mesure d’abord l’état réel de la configuration contre un référentiel technique complet, puis on redistribue chaque constat vers les exigences qu’il alimente. Ainsi, le même relevé sert quatre textes, la discussion porte sur les écarts réels, et le plan de remédiation se hiérarchise sur des faits.
Tenovia produit ce relevé pour Microsoft 365 et Google Workspace, en lecture seule, avec la correspondance réglementaire portée sur chaque constat.