Le registre des risques qui résiste à un audit, et celui qui n'y résiste pas

L'ENISA énumère sept éléments qu'une entrée de traitement du risque doit porter. La plupart des registres de PME en portent trois. L'écart n'est pas administratif : c'est la première chose que lit un auditeur.

Daniel Grigorovich
Daniel Grigorovich
Fondateur · 14 Sept 2026 · 7 min de lecture
GRCRiskAudit
Le registre des risques qui résiste à un audit, et celui qui n'y résiste pas

Qui devrait lire ceci : toute personne, dans une entreprise de moins de trois cents salariés, qui tient un tableur intitulé Registre des risques et à qui l’on a annoncé qu’il devrait tenir devant un auditeur ou une autorité compétente.

Presque toutes les entreprises que nous évaluons ont un registre des risques. Presque aucune n’en a un qui remplisse sa fonction. Le fichier existe, il a des lignes, quelqu’un l’a mis à jour avant le dernier audit. Ce qui manque en général, c’est la partie qui en fait un relevé de décisions plutôt qu’une liste d’inquiétudes, et c’est précisément celle qu’un examinateur lit en premier.

Ce que les textes exigent réellement

Deux textes comptent ici, et ils disent à peu près la même chose.

L’article 6.1.2 d’ISO 27001 impose un processus d’appréciation des risques de sécurité de l’information produisant des résultats cohérents, valides et comparables, et l’article 6.1.3 impose un processus de traitement aboutissant à un plan documenté approuvé par les propriétaires de risque.

Côté NIS2, le règlement d’exécution (UE) 2024/2690 de la Commission du 17 octobre 2024 fixe le détail pour les infrastructures numériques, la gestion des services TIC et les fournisseurs numériques, et l’ENISA a publié le 26 juin 2025 ses orientations techniques de mise en œuvre précisant quelles preuves le satisfont. La section 2.1.1 exige un cadre documenté de gestion des risques. La section 2.1.2 exige que le processus documente les mesures de traitement retenues dans un plan, et consigne les raisons d’accepter le risque résiduel de manière compréhensible.

Cette dernière formule est l’endroit où la plupart des registres échouent, et nous y reviendrons.

Les sept champs, et les trois que vous avez

L’ENISA précise ce qu’une entrée de traitement doit porter. En clair :

  1. Une description du risque, et l’objectif de sécurité menacé.
  2. L’option retenue : éviter, réduire, transférer ou accepter.
  3. Les actifs auxquels le risque se rattache.
  4. Les mesures d’atténuation.
  5. Comment leur efficacité sera évaluée.
  6. Les délais de mise en œuvre.
  7. Le rôle responsable.

Ouvrez maintenant votre propre registre. Dans la plupart des fichiers de PME, les champs un, deux et quatre sont présents. Parfois le six. Les champs trois, cinq et sept manquent en général, et le cinq manque presque toujours.

La conséquence n’est pas une remarque de forme. Un registre sans actifs ne peut être rapproché de votre déclaration d’applicabilité, donc l’auditeur ne peut vérifier que les mesures déclarées applicables sont bien celles qui traitent vos risques. Un registre sans rôle nommé signifie qu’aucun risque n’a de propriétaire, ce qui contredit l’exigence d’approbation de l’article 6.1.3. Un registre sans test d’efficacité consigne une intention, pas une mesure.

Le théâtre de la cotation

Le registre le plus fréquent est un tableau d’une quarantaine de lignes, chacune avec une vraisemblance de un à cinq, un impact de un à cinq, un produit, et une couleur. Les couleurs sont majoritairement orange.

Une matrice cinq par cinq n’a rien de fautif. Ce qui l’est, c’est que neuf fois sur dix aucun énoncé n’accompagne les chiffres. Qu’est-ce qui sépare une vraisemblance de deux d’une vraisemblance de trois ? Quel est le seuil d’impact, en euros, en heures d’indisponibilité, en enregistrements exposés ? Sans cela, deux personnes cotant le même risque produisent des chiffres différents, donc le processus ne produit pas les résultats cohérents et comparables exigés.

Le correctif tient en une page, écrite une fois, qui définit chaque niveau d’échelle et les critères d’acceptation. Cela prend un après-midi. Cela transforme un tableau subjectif en méthode reproductible, et c’est la première chose qu’un auditeur compétent demande après le registre lui-même.

Le risque résiduel, de manière compréhensible

Voici l’exigence qui échoue le plus souvent : les raisons justifiant l’acceptation des risques résiduels doivent être consignées de façon qu’un lecteur puisse les comprendre.

En pratique, les registres traitent le risque résiduel de trois manières. Certains l’ignorent et s’arrêtent au traitement. Certains inscrivent une note plus basse après traitement, sans expliquer pourquoi elle est plus basse. Certains écrivent « risque accepté par la direction », sans nom et sans raisonnement.

Aucune ne tient à l’examen. Ce qui tient se lit comme une décision : ce risque demeure à ce niveau après ces mesures, nous l’acceptons parce que le coût d’une atténuation supplémentaire dépasse l’exposition, telle personne nommée l’a accepté à telle date, et nous le réexaminerons à telle échéance. Quatre phrases de plus par risque accepté, et la partie la plus faible du registre devient celle qui démontre que la gouvernance existe.

C’est aussi le lien naturel avec la revue de direction, où les risques acceptés doivent être réexaminés plutôt qu’hérités en silence.

Le registre qui est en réalité une liste de mesures

Deuxième mode de défaillance, plus subtil. Le registre décrit des mesures au lieu de risques. Les lignes disent « pas d’authentification multifacteur », « sauvegardes non testées », « pas d’inventaire des actifs ».

Ce sont des écarts, pas des risques. Une liste d’écarts est utile, et toute évaluation honnête en produit une, mais c’est un autre objet. Un risque est un scénario avec une cause et une conséquence : un attaquant réutilise un identifiant exposé dans la fuite d’un tiers et atteint la boîte de la comptabilité, parce que cet accès n’exige pas de second facteur, et la conséquence est un détournement de paiement. Le facteur manquant est la cause. Le scénario est le risque.

Cela compte parce que les décisions de traitement diffèrent. Vous ne pouvez pas accepter « pas de MFA » comme risque, la phrase n’a pas de sens. Vous pouvez accepter un scénario à une vraisemblance et un impact énoncés, et expliquer pourquoi. Cela compte aussi pour la couverture : dix mesures peuvent traiter un scénario, et une mesure peut en traiter six. Les 93 mesures de l’annexe A regroupées pour le travail réel sont le vocabulaire du traitement, pas celui du risque.

Les dates trahissent tout

Un auditeur juge un registre en quatre-vingt-dix secondes, et le champ qu’il utilise n’est pas la cotation. Ce sont les dates.

Un registre dont toutes les lignes ont été modifiées la même semaine, trois semaines avant l’audit, raconte à lui seul une histoire complète. De même un registre où la date de revue est identique sur quarante lignes. De même un registre où aucun risque n’a jamais bougé, été clos ou ajouté depuis la création du fichier.

Un registre qui a servi est désordonné d’une manière précise : des risques ajoutés à des moments différents, certains clos avec un motif, des échéances de traitement décalées puis replanifiées, quelques lignes révisées après un incident ou l’arrivée d’un fournisseur. Cette texture ne se fabrique pas la semaine précédente, ce qui est exactement pourquoi on lui fait confiance. La même logique traverse les preuves qui s’assemblent toutes seules : la chronologie est la partie qu’on ne peut pas reconstituer après coup.

Combien de lignes

Moins que vous ne pensez. Nous voyons régulièrement des registres de cent vingt lignes dans des entreprises de quarante personnes, et ce sont toujours ceux que personne ne lit.

Une entreprise de cette taille compte peut-être quinze à vingt-cinq scénarios réels. Compromission d’identifiants, rançongiciel sur un stockage partagé, fournisseur avec accès à la production, perte d’une personne clé, stockage cloud mal configuré, service exposé non corrigé, fraude au paiement par usurpation, perte d’appareil, exposition de données par un environnement de test. La liste est courte parce que l’entreprise n’est pas compliquée.

Un registre court revu chaque trimestre bat un registre long revu chaque année, à chaque fois. Tout l’intérêt des dix mesures de l’article 21 de NIS2 est qu’elles sont proportionnées à votre exposition, et le registre est l’instrument qui montre quelle est réellement cette exposition. La carte d’ensemble se trouve dans le guide de conformité NIS2.

Ce qu’il faut faire ce mois-ci

Ne réécrivez pas le registre. Faites quatre choses à celui que vous avez.

Rédigez la page d’échelle et de critères d’acceptation. Ajoutez un rôle propriétaire à chaque ligne. Ajoutez un test d’efficacité à chaque traitement, même si le test est « la revue trimestrielle des accès ne montre aucun compte orphelin ». Écrivez quatre vraies phrases pour chaque risque accepté.

C’est une journée de travail, et cela traite les trois champs les plus souvent absents ainsi que l’exigence la plus souvent manquée.

La réalité technique : un registre consigne des décisions, il ne détecte rien

Voici la partie facile à perdre de vue. Tout ce qui précède rend le registre défendable. Rien de tout cela ne rend l’entreprise plus sûre.

Un registre des risques est un relevé de décisions prises à un instant donné sur des conditions supposées vraies. Il dit que vous avez décidé de corriger les services exposés sous trente jours. Il ne vous dit pas que l’un d’eux accuse actuellement quatre-vingt-dix jours de retard, que l’accès d’un fournisseur n’a jamais été révoqué à la fin du contrat, ou que la sauvegarde que le registre déclare testée chaque trimestre a restauré avec succès pour la dernière fois en mars.

C’est l’écart entre un registre et une posture de sécurité, et c’est là qu’un exercice de conformité bien mené vous laisse malgré tout exposé. Le combler suppose que les conditions supposées par le registre soient vérifiées en continu plutôt qu’affirmées une fois l’an : inventaire alimenté par ce qui tourne réellement, état des correctifs et de l’exposition mesuré plutôt que déclaré, accès fournisseurs rapprochés des contrats, restaurations vérifiées plutôt que planifiées. Quand cela tourne, le registre cesse d’être un document à défendre pour devenir la description d’un état visible, moment à partir duquel la certification cesse d’être synonyme de sécurité.

Si vous voulez le mesurer plutôt que l’estimer, un audit de sécurité indépendant produit la liste des scénarios et l’état réel ensemble, et la plateforme CloudSoul maintient les deux à jour ensuite plutôt que le mois précédant l’audit.

Daniel Grigorovich

Daniel Grigorovich · Fondateur

Je pense qu'aucune entreprise ne devrait avoir à subir les « listes de contrôle de conformité » ni à se débattre avec des textes réglementaires obscurs. Bien que je reste attaché au principe selon lequel tous les logiciels doivent être fiables et sécurisés, je souhaite offrir aux entreprises un moyen de surmonter les difficultés rencontrées lors de la mise en œuvre de ces exigences.