ISO 27001 n’impose pas de registre des risques, mais les clauses 6.1.2, 6.1.3 et 8.2 exigent des enregistrements qui en tiennent lieu : chaque risque, son propriétaire, ses conséquences et sa vraisemblance, son niveau au regard de vos critères, le traitement retenu, ainsi que l’approbation du plan par le propriétaire et son acceptation du risque résiduel. Les auditeurs le confrontent à votre propre méthode et à ses dates.
Ce guide couvre ce qu’exige la norme, les colonnes dont un registre a besoin, un modèle à copier, la cotation, le risque résiduel, ce que vérifient les auditeurs, pourquoi les registres échouent, la place de NIS2 et une liste de vérification.
| Exigence | Clause | Où elle apparaît dans le registre |
|---|---|---|
| Critères de risque, dont les critères d’acceptation ; résultats cohérents et comparables | 6.1.2 a), b) | Une méthode d’une page, avec des échelles définies et un seuil d’acceptation |
| Risques pour la confidentialité, l’intégrité et la disponibilité, et leurs propriétaires | 6.1.2 c) | Colonnes scénario, DIC et propriétaire |
| Conséquences, vraisemblance, niveau, priorité | 6.1.2 d), e) | Cotations comparées au seuil d’acceptation |
| Traitement, mesures comparées à l’annexe A, déclaration d’applicabilité | 6.1.3 a) à d) | Références de mesures conformes à la DdA |
| Plan de traitement des risques | 6.1.3 e) | Actions, porteurs, échéances |
| Approbation du plan et du risque résiduel par le propriétaire | 6.1.3 f) | Niveau résiduel, nom, date, justification |
| Réappréciation à intervalles planifiés ou en cas de changement significatif | 8.2 | Dates de revue et historique des modifications |
| Mise en œuvre du plan | 8.3 | Statut et preuves |
Qu’exige ISO 27001 pour un registre des risques ?
Les exigences se trouvent dans deux clauses de planification et deux clauses opérationnelles. En substance :
- Clause 6.1.2, appréciation des risques. Définir des critères de risque, dont les critères d’acceptation des risques et les critères de réalisation des appréciations. Veiller à ce que des appréciations répétées produisent des résultats cohérents, valides et comparables. Identifier les risques pesant sur la confidentialité, l’intégrité et la disponibilité des informations du périmètre, ainsi que leurs propriétaires. Apprécier les conséquences potentielles et la vraisemblance réaliste, et déterminer les niveaux de risque. Les comparer à vos critères et établir des priorités.
- Clause 6.1.3, traitement des risques. Choisir les options de traitement. Déterminer les mesures nécessaires, les comparer à l’annexe A pour ne rien omettre d’indispensable, et produire la déclaration d’applicabilité (DdA). Rédiger un plan de traitement des risques. Obtenir des propriétaires des risques l’approbation du plan et leur acceptation des risques résiduels.
- Clause 8.2. Apprécier les risques à intervalles planifiés ou lorsque des changements significatifs sont envisagés ou surviennent, selon les critères de la clause 6.1.2. Conserver les résultats.
- Clause 8.3. Mettre en œuvre le plan de traitement. Conserver les résultats.
Les quatre clauses exigent aussi des informations documentées : des enregistrements, pas un format. Un tableur convient, un outil GRC aussi. La norme n’impose pas de méthode fondée sur les actifs ; l’ISO/IEC 27005:2022, la norme de lignes directrices, oppose les approches fondées sur les événements et celles fondées sur les actifs. Et le registre ne se suffit pas à lui-même. Ses mesures doivent concorder avec votre périmètre et votre déclaration d’applicabilité, et la clause 9.3.2 fait des résultats de l’appréciation des risques et de l’état du traitement un élément d’entrée de la revue de direction.
Que doit contenir un registre des risques ISO 27001 ?
Les clauses fixent le minimum. La pratique ajoute des champs qui rendent le registre utilisable ; la présentation indique ce qui relève de l’un ou de l’autre.
Modèle de registre des risques ISO 27001
REGISTRE DES RISQUES ISO 27001 : UNE LIGNE PAR RISQUE
Colonne Contenu Base
------------------ ----------------------------------------------- -------------
ID R-01, R-02, etc., jamais réutilisé pratique
Scénario de risque Cause, événement et conséquence, une phrase 6.1.2 c)
DIC concerné Confidentialité, intégrité, disponibilité 6.1.2 c)
Actifs, services Systèmes, données ou processus concernés pratique
Propriétaire Rôle habilité à accepter le risque 6.1.2 c)
Mesures existantes Ce qui réduit déjà le risque pratique
Vraisemblance 1 à 5, selon la page de méthode 6.1.2 d)
Conséquence 1 à 5, selon la page de méthode 6.1.2 d)
Niveau de risque Vraisemblance x conséquence 6.1.2 d)
Priorité Niveau comparé au seuil d'acceptation 6.1.2 e)
Traitement Réduire, éviter, transférer ou accepter 6.1.3 a)
Mesures Références annexe A, telles que dans la DdA 6.1.3 b) à d)
Actions Ce qui sera fait 6.1.3 e)
Porteur, échéance Qui, et pour quand 6.1.3 e)
Test d'efficacité Comment savoir que la mesure fonctionne pratique
Niveau résiduel Vraisemblance x conséquence après traitement 6.1.3 f)
Acceptation Nom du propriétaire, date et justification 6.1.3 f)
Statut, preuves Ouvert, fait ou replanifié, lien vers la preuve 8.3
Dernière revue Date de la dernière vraie revue ou modification 8.2
PAGE DE MÉTHODE (EXEMPLE, ADAPTEZ LES CHIFFRES)
Note Vraisemblance Conséquence
----- -------------------------- -------------------------------------------
1 Moins d'une fois en 10 ans Moins de 10 k€, aucun client ne le remarque
2 Une fois en 3 à 10 ans 10 k€ à 50 k€, des heures de perturbation
3 Une fois en 1 à 3 ans 50 k€ à 250 k€, ou un jour d'arrêt
4 Environ une fois par an 250 k€ à 1 M€, clients touchés
5 Plusieurs fois par an Plus de 1 M€, ou un régulateur impliqué
Seuil d'acceptation : un niveau de 8 ou moins peut être accepté par le
propriétaire du risque. Au-dessus de 8 : traiter le risque, ou ne l'accepter
qu'avec l'approbation de la direction et une justification écrite.
EXEMPLE DE LIGNE
ID R-07
Scénario de risque Un mot de passe divulgué ailleurs est réutilisé sur la
boîte mail de la comptabilité, qui n'a pas de second
facteur, et un paiement fournisseur est détourné.
DIC concerné Confidentialité, intégrité
Propriétaire DAF
Mesures existantes Contre-appel du fournisseur avant tout changement de
coordonnées bancaires
Niveau Vraisemblance 3 x conséquence 4 = 12, au-dessus du seuil
Traitement Réduire
Mesures A.5.17, A.8.5
Actions MFA sur chaque boîte mail, blocage de l'authentification
héritée
Porteur, échéance Responsable informatique, 30 juin 2026
Test d'efficacité Rapport mensuel : boîtes mail sans MFA = 0
Niveau résiduel 2 x 4 = 8
Acceptation DAF, 14 juillet 2026. Reste l'hameçonnage qui contourne
la MFA, et le contre-appel s'applique toujours. D'autres
mesures coûteraient plus que l'exposition.
Revue au T1 2027 ou en cas de changement de banque.
Statut, preuves Fait, rapport MFA joint
Dernière revue 14 juillet 2026Copiez les colonnes dans un tableur et conservez la page de méthode à part. Les échelles et le seuil d’acceptation sont des exemples : fixez les vôtres, mais mettez-les par écrit.
Comment coter la vraisemblance et les conséquences ?
N’importe quelle échelle convient, à condition d’être définie. Le registre que nous voyons le plus souvent compte une quarantaine de lignes, chacune avec une vraisemblance de un à cinq, un impact de un à cinq, un produit et une couleur. Les couleurs sont surtout orange.
Une matrice cinq par cinq convient très bien. Ce qui pèche, c’est que neuf fois sur dix, rien ne dit ce que signifient les chiffres. Qu’est-ce qui distingue une vraisemblance de deux d’une vraisemblance de trois ? Quel est le seuil d’impact en euros, en heures d’arrêt ou en enregistrements exposés ? Sans cela, deux personnes cotent le même risque différemment, et le processus ne produit pas les résultats cohérents et comparables que demande la clause 6.1.2.
Le remède est la page de méthode : rédigée une fois, elle définit chaque point des échelles et les critères d’acceptation des risques. Elle prend un après-midi, et c’est la première chose qu’un auditeur compétent demande à voir après le registre lui-même.
Comment consigner le risque résiduel et son acceptation ?
La clause 6.1.3 exige que les propriétaires des risques acceptent les risques résiduels. D’après notre expérience, c’est l’exigence la plus souvent non satisfaite.
Les registres la traitent généralement de l’une de trois façons. Certains s’arrêtent au traitement. D’autres consignent une cotation plus basse après traitement, sans explication. D’autres encore écrivent « risque accepté par la direction », sans nom ni raisonnement.
Aucune de ces façons ne résiste à un examen attentif. Ce qui résiste se lit comme une décision. Ce risque subsiste à ce niveau après ces mesures. Nous l’acceptons parce qu’une réduction supplémentaire coûte plus que l’exposition. Cette personne, nommément désignée, l’a accepté à cette date. Nous le réexaminerons à telle échéance. Quatre phrases par risque accepté transforment la partie la plus faible du registre en celle qui montre que la gouvernance est réelle. Les risques acceptés doivent revenir en revue de direction, et non être reconduits en silence.
Que vérifient les auditeurs dans un registre des risques ISO 27001 ?
À l’étape 1, l’auditeur lit la méthode, le registre, la DdA et le plan de traitement. À l’étape 2, il vérifie que le processus fonctionne, comme expliqué dans audits d’étape 1 et d’étape 2. En pratique, attendez-vous à ceci :
- La méthode : échelles, critères d’acceptation, qui peut accepter quel niveau.
- La cohérence : quelques risques recotés selon vos propres définitions.
- La propriété : chaque risque a un propriétaire capable de l’expliquer en entretien.
- La traçabilité : un risque échantillonné, suivi jusqu’à ses mesures, la DdA et les preuves que les mesures fonctionnent.
- L’approbation : approbation du plan et acceptation du risque résiduel par les propriétaires, avec noms et dates.
- Le changement : réappréciation après des changements significatifs, comme un nouveau système ou un nouveau fournisseur, ainsi que l’exige la clause 8.2, et en pratique après des incidents.
- L’avancement : actions réalisées, ou replanifiées avec une justification, ainsi que l’exige la clause 8.3.
Les dates vous trahissent
Un auditeur peut juger un registre en quatre-vingt-dix secondes environ, et ce n’est pas sur les cotations qu’il s’appuie. C’est sur les dates.
Un registre dont chaque ligne a été modifiée la même semaine, trois semaines avant l’audit, raconte une histoire complète. Tout comme un registre où quarante lignes partagent la même date de revue, ou dans lequel aucun risque n’a évolué, n’a été clos ni ajouté depuis la création du fichier.
Un registre qui a servi paraît désordonné d’une manière bien particulière : des risques ajoutés à des moments différents, certains clos avec une justification, des dates de traitement qui ont glissé puis ont été replanifiées, des lignes révisées après un incident ou l’arrivée d’un nouveau fournisseur. Cette texture ne se fabrique pas la semaine précédente, et c’est précisément pour cela qu’on s’y fie.
Pourquoi les registres des risques échouent-ils à l’audit ?
Presque toutes les entreprises que nous évaluons ont un registre des risques. Presque aucune n’en a un qui remplit son rôle. Il lui manque la partie qui en fait un registre de décisions plutôt qu’une liste d’inquiétudes.
Il liste des écarts, pas des risques
Les lignes indiquent « pas d’authentification multifacteur », « sauvegardes non testées », « pas d’inventaire des actifs ». Ce sont des écarts. Une liste d’écarts est utile, mais c’est un autre document.
Un risque est un scénario. L’ISO/IEC 27005 définit un scénario de risque comme une séquence ou une combinaison d’événements menant de la cause initiale à la conséquence non souhaitée. Dans la ligne d’exemple, l’absence de second facteur est la cause et le paiement détourné la conséquence. Le scénario est le risque.
Vous ne pouvez pas accepter « pas de MFA » : la phrase n’a pas de sens. Vous pouvez accepter un scénario à un niveau donné et expliquer pourquoi. La couverture en dépend aussi : dix mesures peuvent traiter un seul scénario, et une seule mesure peut en traiter six. Les mesures de l’annexe A, regroupées pour le travail réel, sont le vocabulaire du traitement, pas celui du risque.
Il manque trois colonnes
D’après notre expérience, la plupart des registres de PME comportent le risque, le traitement et les mesures. Il leur manque ce que le risque touche, qui en est propriétaire et comment savoir si le traitement fonctionne. Sans le premier élément, l’auditeur ne peut pas vérifier si les mesures de votre DdA couvrent les systèmes exposés. Sans propriétaire, personne ne peut approuver le traitement ni accepter le risque résiduel. Sans test d’efficacité, vous avez consigné une intention, pas une mesure.
Il a trop de lignes
Nous voyons régulièrement des registres de 120 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 le stockage partagé, fournisseur ayant accès à la production, perte d’une personne clé, fraude au paiement par usurpation d’identité. Un registre court, revu chaque trimestre, vaut mieux qu’un registre long revu une fois par an.
NIS2 impose-t-elle un registre des risques ?
Pas sous ce nom. L’article 21, paragraphe 2, point a), de NIS2 exige au moins « les politiques relatives à l’analyse des risques et à la sécurité des systèmes d’information ».
Pour les fournisseurs numériques couverts par le règlement d’exécution (UE) 2024/2690, le point 2.1 de l’annexe est précis. Ils doivent réaliser et documenter des appréciations des risques, et établir, mettre en œuvre et surveiller un plan de traitement des risques. Ils doivent déterminer qui met en œuvre chaque mesure et dans quel délai, et consigner « de manière compréhensible » les raisons justifiant l’acceptation des risques résiduels. Les résultats et le plan doivent être réexaminés à intervalles planifiés, au moins une fois par an, ainsi qu’après des changements importants ou des incidents importants.
Les orientations techniques de mise en œuvre publiées par l’ENISA en juin 2025 ont une valeur indicative. Elles énumèrent sept éléments qu’un plan de traitement devrait au moins comporter : le risque et son impact, l’option de traitement, les actifs, les mesures, la manière d’évaluer l’efficacité, les délais et les rôles responsables. Le modèle les reprend tous les sept, si bien qu’un seul registre peut servir aux deux. Pour en savoir plus : les dix mesures NIS2 de l’article 21.
La réalité technique : un registre consigne des décisions, il ne détecte rien
Tout ce qui précède rend le registre défendable. Rien de tout cela ne rend l’entreprise plus sûre.
Un registre consigne des décisions sur des conditions supposées vraies. Il affirme que les services exposés à Internet sont corrigés sous trente jours. Il ne vous dit pas que l’un d’eux a quatre-vingt-dix jours de retard, qu’un fournisseur a conservé ses accès après la fin du contrat, ni que la sauvegarde « testée » a été restaurée pour la dernière fois en mars.
La norme laisse ce point ouvert. La clause 8.3 vous demande de mettre en œuvre le plan et d’en conserver les résultats ; elle ne dit pas comment savoir que les mesures fonctionnent toujours quand l’auditeur n’est pas là. Combler cet écart suppose de vérifier en continu les hypothèses du registre : une liste d’actifs tirée de ce qui tourne réellement, un état des correctifs mesuré plutôt que déclaré, des accès fournisseurs rapprochés des contrats, des restaurations vérifiées plutôt que planifiées. La colonne d’efficacité se remplit alors d’elle-même.
C’est ainsi que fonctionne la plateforme CloudSoul : des contrôles automatisés sur vos systèmes, avec une personne qui examine les exceptions. Un audit de sécurité indépendant produit à la fois la liste des scénarios et l’état actuel, et le programme complet est présenté sur la page ISO 27001.
Liste de vérification du registre des risques ISO 27001
Ne réécrivez pas le registre. Reprenez celui que vous avez, point par point.
- Rédigez une page qui définit les échelles et les critères d’acceptation des risques.
- Réécrivez les lignes d’écarts sous forme de scénarios, avec une cause et une conséquence.
- Attribuez à chaque risque un propriétaire habilité à l’accepter.
- Référencez les mesures de l’annexe A pour chaque traitement et vérifiez qu’elles concordent avec la DdA.
- Ajoutez un test d’efficacité à chaque traitement, même « la revue trimestrielle des accès ne montre aucun compte orphelin ».
- Consignez chaque acceptation de risque résiduel avec un nom, une date et une justification.
- Réappréciez les risques à intervalles planifiés et après des changements significatifs.
- Présentez les résultats et l’état du traitement en revue de direction.
Sources
- ISO/IEC 27001:2022, Systèmes de management de la sécurité de l’information : Exigences, clauses 6.1.2, 6.1.3, 8.2, 8.3 et 9.3.2, ISO.
- ISO/IEC 27005:2022, Préconisations pour la gestion des risques liés à la sécurité de l’information, clause 3.1.4, ISO.
- Directive (UE) 2022/2555 (NIS2), article 21, paragraphe 2, point a), EUR-Lex.
- Règlement d’exécution (UE) 2024/2690 de la Commission, annexe, points 2.1.1 à 2.1.4, EUR-Lex.
- ENISA, NIS2 Technical Implementation Guidance, version 1.0, juin 2025, ENISA.
Questions fréquentes
Que doit contenir un registre des risques ISO 27001 ?
Chaque risque, son propriétaire, ses conséquences probables et sa vraisemblance, son niveau comparé à vos critères de risque, le traitement retenu, ainsi que l'approbation du plan de traitement et l'acceptation du risque résiduel par le propriétaire du risque. En pratique, ajoutez les mesures de l'annexe A utilisées, les dates des actions, un test d'efficacité et une date de revue.
Le registre des risques est-il obligatoire pour ISO 27001 ?
ISO 27001 n'impose pas de document appelé registre des risques. La norme exige des informations documentées sur les processus d'appréciation et de traitement des risques et sur leurs résultats, et un registre est la manière habituelle de les tenir.
Qui accepte le risque résiduel selon ISO 27001 ?
Le propriétaire du risque. La clause 6.1.3 exige que l'organisation obtienne des propriétaires des risques l'approbation du plan de traitement des risques et leur acceptation des risques résiduels de sécurité de l'information.
À quelle fréquence faut-il mettre à jour l'appréciation des risques ISO 27001 ?
La clause 8.2 exige des appréciations des risques à intervalles planifiés ou lorsque des changements significatifs sont envisagés ou surviennent. Une approche raisonnable consiste à revoir le registre chaque trimestre et à mener une réappréciation complète au moins une fois par an.
Que vérifient les auditeurs dans un registre des risques ?
En pratique : si les cotations suivent vos critères écrits, si chaque risque a un propriétaire qui a approuvé son traitement et accepté le risque résiduel, si les mesures correspondent à la déclaration d'applicabilité, et si les dates montrent que le registre sert réellement.
