Registre des risques ISO 27001 prêt pour l'audit pour les équipes SMSI, un modèle téléchargeable

Un registre des risques ISO 27001 est le document de travail qui recense chaque scénario de risque identifié, sa vraisemblance et son impact, le responsable, la décision de traitement et le risque résiduel subsistant après application des contrôles, directement rattaché à la Clause 6.1.3 et à la Déclaration d'Applicabilité. Si vous n'en avez pas encore commencé un, la solution la plus rapide consiste à ouvrir un modèle avec ces champs déjà intégrés et à commencer à alimenter votre inventaire des actifs dès aujourd'hui.

En résumé :

• Un registre des risques est indispensable pour apporter la preuve lors d'un audit, en reliant chaque scénario de risque, chaque décision de contrôle et chaque justification dans un format structuré et traçable.
• Constituer un inventaire des actifs propre, avec des classifications et des responsabilités clairement définies, est un prérequis pour obtenir des scénarios de risque crédibles et une notation cohérente.
• Des scénarios de risque efficaces identifient des actifs, des menaces, des vulnérabilités et des impacts spécifiques en s'appuyant sur des données sources issues des journaux, des CVE et de l'historique des incidents, sans s'en remettre aux suppositions.
• Un schéma de registre bien conçu doit comporter des identifiants de risque uniques, des actions de traitement avec responsables et échéances, le risque résiduel et des liens vers les preuves techniques.
• La revue régulière, l'attribution des responsabilités et la tenue d'un historique des versions sont essentielles pour maintenir le registre précis, exploitable et prêt pour l'audit dans la durée.

Table des matières

• Pourquoi le registre des risques est essentiel à la préparation de l'audit
• Constituer un registre des actifs avant toute évaluation
• Rédiger des scénarios de risque qui résistent à l'examen
• Choisir le schéma de votre registre : colonnes, outils et contrôle des versions
• Notation, priorisation et correspondance du traitement avec la DdA
• Un exemple concret et un modèle pour démarrer dès aujourd'hui
• Maintenir le registre vivant : cadence, responsabilité et reporting
• Aligner votre registre sur le modèle de reporting de risques d'entreprise du NIST
• Ce que les auditeurs relèvent réellement lors de l'examen d'un registre
• ISMS Calculator : valider les hypothèses d'effort et de calendrier de votre registre
• Sources primaires et modèles
• Sources
• FAQ

Pourquoi le registre des risques est essentiel à la préparation de l'audit

Les auditeurs ne prennent pas votre parole sur le fait qu'une évaluation des risques a bien eu lieu. Ils souhaitent la consulter, ligne par ligne, et tracer un fil conducteur allant d'un risque identifié à une décision de contrôle, puis à une justification documentée dans la Déclaration d'Applicabilité. Le registre constitue cette piste de preuves. Sans lui, la Clause 6.1.3 d'ISO/IEC 27001:2022 n'a rien sur quoi s'appuyer, et la DdA devient une liste d'affirmations plutôt qu'un ensemble de décisions défendables.

Le registre remplit également une fonction opérationnelle concrète, au-delà du seul exercice d'audit. C'est le mécanisme qui transforme une évaluation des risques en sélection de contrôles. Lorsqu'un scénario de risque dépasse votre seuil d'appétence, le registre doit indiquer quel contrôle a été choisi, pourquoi, et quel risque subsiste ensuite. Cette chaîne de raisonnement est précisément ce qu'attend le référentiel ISO/IEC 27001 lorsqu'il stipule que les contrôles nécessaires doivent être identifiés avant que quiconque ne consulte l'Annex A pour y trouver une correspondance.

Une erreur fréquente consiste à entasser tous les détails techniques dans le registre lui-même : extraits de journaux bruts, résultats de scans de vulnérabilités, historiques de tickets. Cela produit un document illisible lors d'une revue de direction. Le meilleur modèle, emprunté à la pratique de gestion des risques d'entreprise, consiste à séparer le registre en lignes de synthèse concises et un enregistrement de détail lié à chacune d'elles :

• La ligne du registre énonce le scénario, le score, le responsable et la décision dans un langage qu'un dirigeant peut parcourir en quelques secondes.
• Un Enregistrement de Détail du Risque (Risk Detail Record) lié contient les preuves : résultats de scans, horodatages de journaux, tickets de remédiation et résultats de tests.
• Les auditeurs échantillonnent le registre, puis consultent l'enregistrement de détail lié pour toute ligne qu'ils souhaitent vérifier.
• Les revues de direction restent courtes, car personne n'a à faire défiler du bruit technique pour trouver la décision.

Cette séparation maintient le registre utilisable par ses deux audiences simultanément : les personnes devant agir sur un risque et celles devant prouver qu'il a été géré.

Constituer un registre des actifs avant toute évaluation

Il est impossible de rédiger un scénario de risque crédible sans savoir quel actif est exposé. C'est là que la plupart des constructeurs d'un SMSI pour la première fois se heurtent à un obstacle : ils tentent de rédiger des lignes de risque avant d'avoir un inventaire des actifs propre, et le registre finit par contenir des entrées vagues comme « le réseau » ou « les données clients » sans responsable ni périmètre définis.

Commencez par définir la classification et la criticité avant de recenser le moindre actif. Décidez, par écrit, de ce qui rend un actif « critique », « moyen » ou « faible » pour votre organisation. Les critères habituels incluent le fait que l'actif contienne des données personnelles réglementées, que sa perte interromprait un processus générateur de revenus, et la durée pendant laquelle l'entreprise pourrait tolérer son indisponibilité. Fixer ces définitions en premier garantit que chaque actif est évalué de la même manière, quel que soit l'auteur de la saisie.

Une fois les critères établis, travaillez selon une séquence reproductible :

1. Exploitez d'abord les inventaires existants : les exports CMDB, les listes de ressources de comptes cloud et les tags d'actifs issus des outils de gestion des postes de travail vous fournissent une base de référence rapide.
2. Interrogez les responsables de processus dans la finance, les RH et les opérations pour identifier le shadow IT et les processus manuels qui n'apparaissent jamais dans un CMDB.
3. Attribuez à chaque actif un responsable redevable des décisions de risque le concernant, et non simplement un gestionnaire qui l'administre.
4. Étiquetez le niveau de confidentialité, l'emplacement physique ou logique, et le processus métier que chaque actif supporte.
5. Réconciliez les doublons et retirez les entrées relatives aux systèmes décommissionnés avant qu'ils ne viennent polluer vos scénarios de risque.

Les catégories d'actifs courantes couvrent généralement les actifs informationnels (bases de données, référentiels documentaires), les logiciels, le matériel et l'infrastructure, les personnes et les rôles disposant d'accès privilégiés, les emplacements physiques et les services tiers. Pour chacun, capturez suffisamment de métadonnées pour rédiger un scénario de risque ultérieurement : responsable, emplacement, niveau de confidentialité et processus métier associé. Omettre l'un de ces champs est la principale raison pour laquelle les lignes de risque finissent trop vagues pour être notées de manière cohérente.

Conseil pratique : Menez votre découverte des actifs et votre atelier sur les risques la même semaine. Les actifs découverts de manière isolée ont tendance à rester inutilisés pendant des mois, faute d'être reliés à une conversation vivante sur les risques.

Les écueils liés à la qualité des données sont prévisibles. Les équipes comptent deux fois le même actif sous deux noms différents, oublient d'attribuer un responsable en laissant le champ vide, ou importent un export CMDB sans filtrer les environnements de test et de pré-production qui n'ont aucun impact métier réel. Nettoyez ces problèmes avant de commencer la notation, car chaque ligne de risque en aval hérite de la qualité des données des actifs.

Rédiger des scénarios de risque qui résistent à l'examen

Une ligne de registre des risques n'est utile que dans la mesure où la phrase décrivant le risque l'est. « Risque de ransomware » ne dit rien à un auditeur. Un scénario structuré fait le travail : nommez l'actif, l'agent de menace, la vulnérabilité qu'il exploite et l'impact métier spécifique, exprimé en termes de confidentialité, d'intégrité ou de disponibilité.

Un modèle opérationnel ressemble à ceci : [actif] est exposé à [agent de menace] exploitant [vulnérabilité], entraînant [une perte de confidentialité/intégrité/disponibilité] et [conséquence métier]. Par exemple : la base de données de facturation clients est exposée à un attaquant externe exploitant un serveur de base de données non corrigé, entraînant une perte de confidentialité des données de paiement et des obligations de notification réglementaire. Cette phrase vous fournit tout ce dont vous avez besoin pour attribuer une vraisemblance, un impact et, à terme, un responsable de traitement.

Des scénarios crédibles nécessitent des sources crédibles, et non des suppositions issues d'un tableau blanc en atelier. Tirez les données sur les menaces et les vulnérabilités à partir de :

• Les journaux internes et les alertes SIEM qui indiquent ce qui a réellement été tenté contre votre environnement.
• Les avis de sécurité des fournisseurs et prestataires, notamment pour les logiciels tiers avec des délais de CVE connus.
• Les bases de données CVE publiées, croisées avec votre propre inventaire des actifs, pour identifier les expositions non corrigées.
• L'historique des incidents de votre propre organisation ou de votre secteur, lorsqu'il est disponible, plutôt que des affirmations sectorielles génériques.

Notre guide de méthodologie d'évaluation des risques détaille ce processus de construction de scénarios plus en profondeur si vous souhaitez une séquence développée.

L'attribution de la vraisemblance et de l'impact est là où la criticité des actifs prouve sa valeur. Une vulnérabilité sur un serveur de test à faible criticité et la vulnérabilité identique sur une passerelle de paiement en production ne devraient jamais obtenir le même score de risque, même si la faille technique est identique. L'impact doit être évalué par rapport au niveau de criticité de l'actif que vous avez défini au préalable, et non par rapport à une échelle de gravité générique empruntée à un scanner de vulnérabilités. La vraisemblance doit refléter ce que vous savez de l'exposition : l'actif est-il exposé sur Internet, est-il protégé par une segmentation réseau, cette classe de vulnérabilité a-t-elle déjà été exploitée contre vous. Les évaluations de vraisemblance vagues (« moyen, probablement ») constituent la principale faiblesse que les auditeurs relèvent lors de l'examen d'un registre.

Choisir le schéma de votre registre : colonnes, outils et contrôle des versions

Les colonnes que vous choisissez déterminent si le registre sera utilisable dans six mois ou s'il s'effondrera en un tableur impossible à maintenir. Un schéma recommandé, construit autour de ce que les auditeurs s'attendent réellement à voir, comprend :

• Identifiant du risque : un identifiant stable et unique qui n'est jamais réutilisé, afin que les références historiques et les liens vers les RDR restent valides.
• Description du risque : la phrase structurant le scénario, et non une étiquette en un mot.
• Référence de l'actif : un lien vers l'entrée du registre des actifs, évitant la duplication des données d'actif.
• Impact CIA : laquelle de la confidentialité, de l'intégrité ou de la disponibilité est affectée, et de quelle manière.
• Notes de vraisemblance et d'impact : évaluées selon vos critères définis, et non selon une intuition fluctuante.
• Score de risque : le résultat calculé de la vraisemblance multipliée par l'impact, ou votre pondération choisie.
• Contrôles existants et efficacité des contrôles : ce qui est déjà en place et son niveau d'efficacité.
• Action de traitement, responsable et date cible : la décision, la personne redevable et l'échéance.
• Risque résiduel : le score subsistant après traitement, qui est ce que la direction a réellement besoin de voir.
• Lien vers l'Enregistrement de Détail du Risque : l'emplacement des preuves techniques.
• Date de dernière revue : la preuve que la ligne est maintenue, et pas simplement créée une fois puis oubliée.

Un tableur est véritablement suffisant pour les petites organisations avec un nombre d'actifs modeste et un seul responsable SMSI maintenant le fichier à jour. Il est rapide à construire, facile à échantillonner pour les auditeurs et peu coûteux à maintenir. Il cesse d'être suffisant lorsque plusieurs entités métier contribuent aux risques, que vous avez besoin d'une automatisation des workflows pour les échéances de traitement, ou que vous exigez un contrôle d'accès basé sur les rôles pour que tout le monde ne puisse pas modifier chaque ligne. À ce stade, une plateforme GRC justifie son coût, principalement grâce aux rappels automatisés, aux pistes d'audit et à la capacité d'agréger les risques entre départements sans consolidation manuelle.

Conseil pratique : Si vous migrez ultérieurement d'un tableur vers un outil GRC, conservez votre format d'identifiant de risque stable dès le premier jour. Renuméroter les lignes lors de la migration rompt chaque référence d'audit historique et chaque lien vers un RDR que vous avez construits.

Quel que soit le format choisi, le contrôle des versions n'est pas optionnel. Limitez les droits de modification du registre principal, consignez chaque modification avec un horodatage et le nom de l'auteur, et conservez les versions antérieures accessibles plutôt qu'écrasées. Les auditeurs demandent fréquemment à voir comment un score de risque spécifique a évolué dans le temps, et un tableur sans historique des modifications ne peut pas répondre à cette question.

Notation, priorisation et correspondance du traitement avec la DdA

Trois approches de notation couvrent la plupart des organisations. Un modèle qualitatif simple à trois niveaux (faible, moyen, élevé) convient aux petits programmes SMSI où la rapidité prime sur la granularité. Une matrice numérique 5×5, multipliant la vraisemblance par l'impact sur une échelle de un à cinq, offre une priorisation plus fine et constitue le modèle que la plupart des auditeurs ont l'habitude de voir. Un modèle hybride, ajoutant un facteur de pondération pour l'exposition réglementaire ou l'impact réputationnel au-dessus du score de base 5×5, convient aux organisations soumises à des obligations de conformité complexes superposées au risque standard de sécurité de l'information. Notre modèle de matrice des risques explique en détail comment construire la version 5×5 avec des exemples de notation concrets.

La règle empirique : commencez avec le modèle 5×5, sauf si votre organisation est suffisamment petite pour qu'une échelle à trois niveaux permette de prendre les mêmes décisions plus rapidement. Ne construisez pas un modèle hybride pondéré tant que la version plus simple ne s'est pas avérée trop grossière en pratique.

Les seuils d'appétence au risque transforment les scores en actions. Définissez à l'avance le score au-delà duquel un risque doit être escaladé à la direction plutôt que clôturé au niveau opérationnel. Un schéma courant fixe un plafond numérique sur les scores de risque déclenchant une escalade automatique vers un comité des risques ou un sponsor exécutif, indépendamment de l'identité de la personne qui l'a identifié. Sans seuil écrit, l'escalade devient un jugement qui varie selon les personnes présentes dans la salle.

Une fois la décision de traitement prise, la mise en correspondance avec l'Annex A est l'étape finale, et c'est là que la pensée par liste de contrôle cause le plus de dégâts. ISO/IEC 27001 exige que vous identifiiez d'abord les contrôles nécessaires à partir de l'évaluation des risques, puis que vous consultiez l'Annex A pour trouver une correspondance, en documentant la justification de tout élément exclu dans la Déclaration d'Applicabilité. Les notes de pratique issues des ressources du comité de l'ISO soulignent que l'Annex A est un ensemble de référence, et non une liste de contrôle exhaustive, et que les contrôles nécessaires peuvent provenir d'autres normes. Notre guide des contrôles de l'Annex A explique comment éviter de traiter l'annexe comme un exercice de cochage de cases. Pour des orientations plus approfondies sur la documentation de la décision de traitement elle-même, des responsabilités et des échéances, consultez notre guide de traitement des risques.

Un exemple concret et un modèle pour démarrer dès aujourd'hui

Les conseils abstraits sur le schéma n'ont qu'une portée limitée. Voici une ligne complète, développée de l'identification au risque résiduel, pour une entreprise logicielle de taille moyenne.

Le scénario : la plateforme de gestion des tickets du support client, hébergée par un éditeur SaaS tiers, est exposée à une attaque par bourrage d'identifiants exploitant des politiques de mots de passe faibles sur les comptes des agents de support, entraînant une perte de confidentialité des tickets de support client contenant des données personnelles. L'actif a été signalé lors d'entretiens avec les parties prenantes car les agents de support disposent d'un accès en lecture étendu à l'ensemble des dossiers clients. La vraisemblance a été évaluée comme élevée, l'authentification multifacteur n'étant pas imposée au moment de la revue ; l'impact a été évalué comme élevé car l'actif contient des données personnelles réglementées. La décision de traitement a été d'imposer l'authentification multifacteur pour tous les comptes d'agents dans un délai de 30 jours, sous la responsabilité du responsable de la sécurité informatique. Après traitement, le risque résiduel est tombé à un niveau faible, les attaques par bourrage d'identifiants étant nettement plus difficiles à exécuter sur des comptes protégés par un second facteur.

Pour les lecteurs qui construisent à partir de zéro, un modèle de tableur de démarrage avec ces colonnes pré-intégrées est la façon la plus rapide de commencer, et une version prête pour l'audit ajoute la colonne de lien vers le RDR et un onglet d'historique des versions. Les équipes qui envisagent d'alimenter ultérieurement une plateforme GRC doivent aligner les en-têtes de colonnes sur le schéma ci-dessus, car la correspondance des noms de champs est ce qui rend une importation ultérieure aisée plutôt qu'un exercice fastidieux de remappage manuel. Les petites équipes peuvent gérer l'ensemble du registre dans une seule feuille ; les grandes organisations qui agrègent des données entre entités métier voudront finalement que le registre de chaque entité se consolide dans un résumé de niveau entreprise, ce que la section sur l'alignement NIST ci-dessous aborde plus en détail.

Maintenir le registre vivant : cadence, responsabilité et reporting

Un registre constitué une fois et jamais révisé est pire qu'aucun registre, car il donne une fausse assurance. La cadence de revue doit combiner une vérification programmée, généralement trimestrielle pour la plupart des organisations, avec des revues déclenchées par des changements chaque fois qu'un nouveau système est mis en production, qu'un fournisseur majeur évolue, ou qu'un incident révèle une lacune que le registre avait manquée.

1. Attribuez à chaque ligne de risque un responsable nommément désigné, redevable de sa mise à jour, et non un département ou une équipe.
2. Liez chaque ligne du registre à son Enregistrement de Détail du Risque, ainsi qu'aux tickets ouverts ou aux tâches de remédiation suivant le traitement.
3. Limitez la vue destinée aux dirigeants à un instantané court : les risques dépassant le seuil d'appétence, leurs responsables et les dates cibles, plutôt que le registre technique complet.
4. Suivez un petit ensemble d'indicateurs : délai moyen de traitement pour les risques à score élevé, pourcentage de risques élevés avec un responsable désigné et une échéance active, et tendance des scores de risque résiduel sur les trimestres successifs.
5. Réévaluez tout risque dont le contrôle sous-jacent a changé, plutôt que d'attendre le prochain cycle de revue programmé.

Ces indicateurs sont importants car un registre comportant des dizaines de risques élevés ouverts et aucune évolution sur trois trimestres raconte une histoire très différente à un auditeur de celui qui montre une diminution régulière du risque résiduel. La tendance est souvent plus convaincante qu'une ligne isolée.

Aligner votre registre sur le modèle de reporting de risques d'entreprise du NIST

ISO 27001 n'impose pas de format spécifique pour le registre, ce qui explique précisément pourquoi s'aligner sur un schéma établi est bénéfique. La révision de décembre 2025 du NIST de ses publications sur la cybersécurité et la gestion des risques d'entreprise recommande que les registres des risques de cybersécurité capturent, au minimum, le scénario de risque, la cartographie des menaces et vulnérabilités, la vraisemblance, l'impact, la décision de traitement, le propriétaire du risque et le risque résiduel, ce qui correspond presque champ par champ au schéma recommandé précédemment dans cet article.

La véritable contribution du modèle NIST est la séparation entre le Cybersecurity Risk Register (CSRR) et le Risk Detail Record (RDR). NIST IR 8286A fournit un modèle CSRR notionnel accompagné d'un schéma RDR, explicitement conçu pour maintenir le CSRR succinct pour la revue de direction tout en préservant la profondeur technique dont les auditeurs ont besoin dans un enregistrement lié. NIST IR 8286B étend cela avec des exemples de schémas JSON pour le reporting des risques lisible par machine, ce qui importe dès lors que vous agrégez des données de risque entre plusieurs entités métier ou alimentez une plateforme GRC.

Trois avantages pratiques découlent de l'adoption de cette structure :

• Un CSRR concis est ce que les dirigeants et les auditeurs lisent réellement, tandis que le RDR préserve les preuves sans encombrer la vue synthétique.
• Des noms de champs standardisés, correspondant aux schémas du NIST, rendent la migration ultérieure vers un pipeline d'agrégation d'entreprise nettement moins douloureuse.
• L'attribution d'un identifiant de risque canonique unique par scénario, jamais dupliqué entre les entités métier, est ce qui rend possible une consolidation au niveau entreprise sans réconciliation manuelle.

Il n'est pas nécessaire d'adopter le schéma JSON complet du NIST pour bénéficier de cette approche. Même un tableur qui sépare les lignes de synthèse d'un onglet de détail lié capture l'essentiel de la valeur.

Ce que les auditeurs relèvent réellement lors de l'examen d'un registre

Trois défaillances reviennent sans cesse lorsqu'un registre est examiné lors d'un audit. La première est les descriptions de risques vagues, des entrées du type « risque cyber pour les systèmes informatiques » qui ne permettent à un auditeur de remonter vers aucun actif spécifique ni aucune décision de contrôle. La deuxième est l'absence ou l'obsolescence des responsables, des lignes attribuées à un rôle qui n'existe plus ou à une personne qui a quitté l'entreprise il y a huit mois. La troisième est les actions de traitement sans date cible, ce qui se lit comme un risque que tout le monde reconnaît mais dont personne ne s'est engagé à s'occuper.

Le remède à ces trois problèmes repose sur la même discipline : rédiger les scénarios en phrases complètes, revoir les responsabilités chaque trimestre indépendamment de tout autre changement, et ne jamais laisser une action de traitement figurer dans le registre sans date associée. Un registre qu'un ingénieur sécurité et un directeur financier peuvent lire sans traduction remplit son rôle. Conservez le détail technique dans l'enregistrement lié, et la ligne de synthèse dans un langage qu'un dirigeant non technique peut comprendre et sur lequel il peut agir en une seule lecture.

Les auditeurs que j'ai vus progresser le plus rapidement dans un registre sont ceux où chaque ligne est directement liée à une preuve : un ticket, un résultat de scan, une dérogation validée. Cette seule habitude fait gagner plus de temps lors d'un audit que n'importe quel choix de mise en forme.

— Martin

ISMS Calculator : valider les hypothèses d'effort et de calendrier de votre registre

Construire le registre répond à la question de ce qui doit être traité. Cela ne vous dit pas combien ce traitement coûtera ni combien de temps un programme ISO 27001 prend réellement à déployer, ce qui constitue le manque que ISMS Calculator comble. Le diagnostic gratuit en 2 minutes donne une lecture instantanée de l'état de préparation avant que vous ne vous engagiez dans une évaluation complète, et le calculateur de coût ISO 27001 produit une estimation en temps réel spécifique à votre organisation, basée sur la taille de votre entreprise, votre secteur et votre maturité actuelle en matière de sécurité, avec des hypothèses modifiables que vous pouvez ajuster au fur et à mesure que votre registre se complète.

Si votre registre liste déjà une douzaine d'actions de traitement prioritaires avec des dates cibles, le calculateur permet de vérifier la cohérence de ces calendriers par rapport à des comparaisons de références modèles, plutôt que d'estimer l'effort de manière isolée. Il produit également une évaluation de maturité sur les quatre thèmes de contrôle de l'Annex A, vous permettant de voir où la couverture de votre registre est insuffisante avant qu'un auditeur ne le fasse, et exporte les résultats sous forme de rapport PDF partageable pour la revue de direction. Pour un diagnostic plus approfondi une fois votre registre en ordre, l'évaluation de préparation ISO 27001 va plus loin que la vérification initiale. Commencez par le diagnostic gratuit et voyez où se situe votre estimation d'effort actuelle.

Sources primaires et modèles

La série NIST IR 8286, comprenant IR 8286A et IR 8286B, publie les schémas CSRR et RDR référencés tout au long de ce guide, ainsi que l'avis du NIST de décembre 2025 sur l'intégration de la cybersécurité et de la gestion des risques d'entreprise. La page officielle de la norme ISO/IEC 27001:2022 couvre les exigences de la Clause 6.1.3 et de l'Annex A sur lesquelles cet article s'appuie. Les organisations souhaitant relier les lignes du registre aux preuves de réponse aux incidents peuvent également consulter le guide de réponse aux incidents de Netverge pour des exemples pratiques de liaison avec des RDR.

Sources

• Le NIST révise ses publications intégrant la cybersécurité et les risques d'entreprise
• Priorisation des risques de cybersécurité pour la gestion des risques d'entreprise (mise à jour NIST IR 8286B)
• IR 8286A : Identification et estimation des risques de cybersécurité pour la gestion des risques d'entreprise (NIST)
• ISO/IEC 27001:2022 - Systèmes de management de la sécurité de l'information

FAQ

Un registre des risques est-il une obligation légale ?

ISO/IEC 27001 n'emploie pas le terme « obligation légale » pour un registre des risques, mais la Clause 6.1.3 exige un processus documenté d'évaluation et de traitement des risques, et un registre est la manière standard dont les organisations produisent cette preuve. Sans lui, la certification ISO 27001 n'est pas réalisable, les auditeurs ayant besoin d'un enregistrement traçable reliant les risques aux décisions de contrôle.

Comment réaliser une évaluation des risques ISO 27001 ?

Une évaluation des risques ISO 27001 commence par un inventaire des actifs renseigné, puis identifie les menaces et les vulnérabilités pesant sur chaque actif pour construire des scénarios de risque structurés, et évalue chacun d'eux en termes de vraisemblance et d'impact selon des critères définis. Notre guide de méthodologie d'évaluation des risques couvre la séquence complète, de la classification des actifs à la décision de traitement, de manière plus approfondie.

Existe-t-il une liste de contrôle ISO 27001 gratuite ?

Des listes de contrôle gratuites et des modèles de démarrage pour les registres des risques ISO 27001 sont largement disponibles, bien que leur qualité varie considérablement quant à l'inclusion des champs que les auditeurs attendent réellement, tels que le responsable, la date cible et le risque résiduel. ISMS Calculator propose un diagnostic de préparation gratuit en 2 minutes qui donne une lecture instantanée des écarts sans nécessiter d'inscription.

Comment construire un registre des risques à partir de zéro ?

Commencez par un inventaire des actifs propre incluant le responsable, la classification et la cartographie des processus métier pour chaque entrée, car les scénarios de risque ne peuvent être rédigés sans cela. À partir de là, rédigez des scénarios de risque structurés nommant l'actif, la menace, la vulnérabilité et l'impact métier, évaluez chacun en termes de vraisemblance et d'impact, et attribuez un responsable de traitement et une date cible à chaque ligne dont le score dépasse votre seuil d'appétence au risque défini.

Quelle est la différence entre un CSRR et un Enregistrement de Détail du Risque ?

Un Cybersecurity Risk Register (CSRR) contient des lignes de synthèse concises destinées à la revue de direction et à l'audit, tandis qu'un Risk Detail Record (RDR) contient les preuves techniques sous-jacentes, telles que les résultats de scans et les tickets de remédiation, liées à chaque ligne du CSRR. Cette séparation, décrite dans NIST IR 8286A, maintient le registre lisible tout en préservant ailleurs le niveau de détail requis pour l'audit.

Recommandé

• Matrice des risques ISO 27001 : modèle 5×5 pour une sécurité de l'information prête pour l'audit
• Traitement des risques ISO 27001 : guide prêt pour l'auditeur
• Guide de documentation SMSI prêt pour l'audit pour ISO 27001