Votre tableur NIS2 est un bon début, mais pas encore une preuve

Il arrive un moment que tout responsable informatique d'une entreprise soumise à NIS2 reconnaît. Le tableur reprenant le référentiel est rempli, la politique de sécurité de l'information est publiée sur l'intranet, et l'intuition dit que tout est en ordre. Ce sentiment tient bon jusqu'à ce qu'un grand client envoie une évaluation fournisseur, qu'un auditeur demande des justificatifs ou que l'autorité de contrôle se manifeste. À ce moment-là apparaît l'écart entre posséder quelque chose et pouvoir le démontrer.

Pourquoi le tableur a bel et bien de la valeur

Commençons par lui rendre justice : ce tableur mérite plus de considération qu'on ne lui en accorde d'ordinaire. Qui a rempli un référentiel de mesures NIS2 a réfléchi aux dix mesures de gestion des risques de l'article 21, de l'analyse des risques et du traitement des incidents à la sécurité de la chaîne d'approvisionnement et à la cyberhygiène. Ce travail de réflexion représente la moitié du chemin, et c'est précisément pourquoi le tableur est un point de départ idéal.

Le problème ne réside donc pas dans le contenu, mais dans les limites de l'outil.

Ce qu'un tableur ne peut pas faire

Un jugement dans une cellule, par exemple « conforme », laisse trois questions sans réponse, et ce sont exactement les questions que pose un auditeur ou un client. La première est pourquoi l'exigence est satisfaite, car la justification manque ou reste dans la tête de la personne qui a rempli la cellule. La deuxième est où se trouve la preuve. Le document de politique, la capture d'écran de la configuration ou le rapport de test se trouve quelque part dans un dossier ou une boîte mail, mais pas auprès du jugement. La troisième est de savoir si l'image est encore à jour, car un tableur vieillit dès le jour où on l'enregistre, et personne n'est prévenu lorsque la date de révision de la politique est dépassée ou qu'une mesure n'est jamais testée.

Il existe en outre une quatrième limite, qui n'apparaît que plus tard. Un tableur ignore la cohérence d'ensemble. Le risque ne sait pas quelles mesures le couvrent, l'incident du mois dernier n'a pas ajusté l'évaluation du risque, et le fournisseur qui a fait la une en fin d'année dernière n'est relié nulle part aux processus qui dépendent de lui.

En trois étapes, du remplissage à la démonstration

Le passage d'un aperçu statique à un registre démontrable est plus petit qu'il n'y paraît, justement parce que le travail de réflexion est déjà fait.

La première étape consiste à importer ce qui existe déjà. Prenez le tableur existant comme point de départ et transformez chaque exigence en une ligne de statut dotée d'un propriétaire. Ce qui était « conforme » le reste ; s'ajoutent seulement un champ de justification et un emplacement fixe pour la preuve.

La deuxième étape consiste à rattacher la preuve au jugement. Chaque « conforme » sans justificatif reste une opinion. Reliez donc à chaque exigence le document, la capture d'écran ou le renvoi vers l'emplacement. Dès lors, la question d'un auditeur n'est plus une recherche de plusieurs semaines, mais l'affaire d'un clic.

La troisième étape consiste à activer la surveillance : dates de révision pour les politiques, dates de test pour les mesures et dates de fin pour les dérogations. Vous ne le faites pas parce que la norme l'impose, mais parce que c'est la seule façon de garder le registre à jour sans que quelqu'un doive y penser chaque semaine.

Est-ce suffisant ?

Non, et ce n'est pas grave. Être démontrablement maître de sa sécurité n'est pas une ligne d'arrivée mais un rythme : vous détectez ce qui change, vous évaluez ce que cela signifie, vous résolvez ce qui manque et vous démontrez ce qui est en place. Les organisations qui ont trouvé ce rythme se reconnaissent à une chose. Lorsqu'un client ou une autorité de contrôle demande le dossier à l'improviste, il n'y a rien à chercher : on exporte.

Le tableur était un bon début. L'objectif est de pouvoir aussi le montrer.