Registre des Risques ISO 27001 : Template Excel Gratuit [2026]

Le registre des risques ISO 27001 est le document pivot de tout Système de Management de la Sécurité de l'Information (SMSI). Exigé par la clause 6.1.2 — Appréciation des risques de sécurité de l'information et la clause 6.1.3 — Traitement des risques, il matérialise la capacité de votre organisation à identifier, évaluer, hiérarchiser et traiter l'ensemble des risques pesant sur la confidentialité, l'intégrité et la disponibilité de l'information. Sans registre des risques structuré, rigoureux et maintenu à jour, il est impossible d'obtenir ou de conserver la certification ISO/IEC 27001:2022 — les auditeurs de certification du BSI, de l'AFNOR ou de Bureau Veritas en font systématiquement leur premier point de contrôle lors du Stage 2. Ce template Excel, conçu par Ayi NEDJIMI, consultant cybersécurité et Lead Implementer ISO 27001 certifié, intègre la méthodologie EBIOS Risk Manager recommandée par l'ANSSI, le calcul automatique de criticité selon la matrice Impact × Vraisemblance, les quatre options de traitement du risque (Réduire, Transférer, Éviter, Accepter), le suivi du risque résiduel après traitement, et la traçabilité complète jusqu'au Plan de Traitement des Risques (RTP). Il s'adresse aux RSSI qui pilotent la démarche de certification, aux consultants en charge de l'implémentation du SMSI, aux auditeurs internes qui conduisent les revues annuelles, et aux directions générales qui doivent valider les niveaux de risque acceptables pour l'organisation. Le registre des risques n'est pas un document que l'on remplit une fois pour satisfaire l'auditeur : c'est un outil vivant qui doit refléter en permanence la réalité du contexte menace, des vulnérabilités détectées, des incidents survenus et des changements organisationnels. Ce template vous donne les bases structurelles pour faire vivre ce registre sur la durée, avec les colonnes de révision périodique et les liens vers les documents de traitement associés. Consulter aussi notre template Plan de Traitement des Risques et notre template Inventaire des Actifs pour constituer un triptyque documentaire solide.

Contexte réglementaire et normatif

La norme ISO/IEC 27001:2022 place la gestion des risques au cœur de son dispositif. La clause 6.1 impose à l'organisation de planifier des actions pour adresser les risques et opportunités, la clause 6.1.2 détaille le processus d'appréciation des risques, et la clause 6.1.3 fixe les exigences relatives au traitement. L'ensemble forme un cycle cohérent : identifier les actifs → analyser les menaces et vulnérabilités → évaluer les risques → choisir une option de traitement → mettre en œuvre les contrôles → surveiller l'efficacité.

Par rapport à la version 2013, ISO 27001:2022 renforce la notion de critères de risque : l'organisation doit définir et appliquer un processus d'appréciation des risques qui produit des résultats cohérents, valides et comparables. Cela implique de formaliser le niveau de risque acceptable (risk appetite), les critères d'impact et de vraisemblance, et la méthode de calcul de la criticité.

Plusieurs référentiels s'articulent avec les exigences ISO 27001 en matière de gestion des risques :

• EBIOS Risk Manager (ANSSI, 2018) : méthode de référence française alignée avec ISO 27005. Structurée en 5 ateliers (cadrage, sources de risque, scénarios stratégiques, scénarios opérationnels, traitement), elle est directement intégrée dans ce template. Voir notre guide EBIOS Risk Manager.
• ISO/IEC 27005:2022 : norme de support dédiée à la gestion des risques de sécurité de l'information, révisée en 2022 pour aligner son approche sur ISO 31000 et renforcer la prise en compte des événements cyber. Elle fournit le cadre méthodologique que ce template implémente.
• Directive NIS 2 (2022/2555) : les entités importantes et essentielles doivent mettre en place des mesures de gestion des risques cybersécurité, dont une analyse formalisée et documentée. Le registre des risques ISO 27001 peut servir de base à la conformité NIS 2. Voir notre article conformité NIS 2.
• RGPD (Article 32 et Article 35) : l'analyse d'impact relative à la protection des données (AIPD/DPIA) repose sur une méthodologie de gestion des risques très proche. Un registre des risques ISO 27001 bien construit facilite la réalisation des DPIA.
• SOC 2 Type II : les critères de services de confiance (TSC) imposent une gestion formalisée des risques dont les exigences se recoupent largement avec ISO 27001 clause 6.1.

Structure détaillée du template

Ce template Excel est organisé en onglets fonctionnels qui couvrent l'intégralité du processus de gestion des risques ISO 27001 :

Onglet 1 — Guide méthodologique

Cet onglet présente la méthode d'évaluation des risques adoptée, les définitions (risque, menace, vulnérabilité, actif, impact), les barèmes d'impact et de vraisemblance sur 4 niveaux (1 = Négligeable, 2 = Modéré, 3 = Significatif, 4 = Critique), et la matrice de criticité 4×4. Il inclut également le niveau d'acceptation du risque défini par la direction (risk appetite), qui constitue le seuil à partir duquel le risque doit être traité.

Onglet 2 — Registre des risques (feuille principale)

C'est le cœur du document. Chaque ligne représente un scénario de risque identifié, avec les colonnes suivantes : identifiant unique, actif concerné (lien vers inventaire), menace principale, vulnérabilité exploitée, impact sur la confidentialité (C), sur l'intégrité (I), sur la disponibilité (D), impact global calculé, vraisemblance, criticité brute (avant traitement), option de traitement sélectionnée, mesures de sécurité associées (référence Annexe A), responsable du traitement, échéance, criticité résiduelle (après traitement), statut de mise en œuvre, et date de dernière révision.

Onglet 3 — Synthèse et tableau de bord

Graphiques automatiques : répartition des risques par niveau de criticité, distribution par catégorie d'actif, évolution de la criticité résiduelle dans le temps, taux de traitement des risques critiques. Ces visuels sont utilisés lors de la revue de direction (clause 9.3) pour démontrer la maîtrise du portefeuille de risques.

Onglet 4 — Catalogue des menaces

Liste de 80+ menaces types classées par catégorie (erreurs humaines, actes malveillants, événements naturels, défaillances techniques, problèmes organisationnels), avec leur probabilité d'occurrence tendancielle basée sur le panorama de la cybermenace ANSSI. Utilisé comme base de brainstorming lors des ateliers d'identification des risques.

Onglet 5 — Lien SoA

Tableau de correspondance entre chaque risque identifié et les contrôles de l'Annexe A ISO 27001:2022 sélectionnés pour le traiter. Permet de justifier le Statement of Applicability (SoA) à partir du registre des risques — un lien causal attendu par les auditeurs.

Guide d'utilisation étape par étape

Étape 1 — Cadrage et définition des critères

Avant de renseigner la première ligne de risque, réunissez la direction générale, le RSSI et les responsables métier pour valider les critères d'évaluation. Définissez collectivement ce que signifie un impact "Critique" pour votre organisation (perte financière seuil, nombre de clients affectés, durée d'indisponibilité maximale tolérable), et fixez le niveau d'acceptation du risque. Ces décisions doivent être documentées et approuvées formellement — elles constituent le socle de toute l'appréciation ultérieure.

Étape 2 — Identification des actifs

Importez ou référencez votre inventaire des actifs (template disponible sur ce site). Pour chaque actif critique, identifiez les menaces plausibles en croisant le catalogue de menaces (onglet 4) avec votre contexte spécifique (secteur d'activité, localisation géographique, profil des utilisateurs, architecture technique). N'hésitez pas à organiser des ateliers avec les équipes IT, RH, juridique et métier — chacun voit des risques que les autres ne voient pas.

Étape 3 — Évaluation des risques bruts

Pour chaque scénario de risque identifié, évaluez l'impact sur la confidentialité, l'intégrité et la disponibilité sur l'échelle 1-4, puis estimez la vraisemblance (probabilité d'occurrence dans les 12 prochains mois). Le template calcule automatiquement la criticité brute selon la formule : Criticité = max(C, I, D) × Vraisemblance, avec un plafonnement à 16. Les risques dont la criticité brute dépasse le seuil d'acceptation défini à l'étape 1 doivent impérativement être traités.

Étape 4 — Sélection des options de traitement

Pour chaque risque inacceptable, choisissez parmi les quatre options : Réduire (mettre en place des contrôles de sécurité pour diminuer la vraisemblance ou l'impact), Transférer (assurance cyber, externalisation, contrats de responsabilité), Éviter (cesser l'activité génératrice du risque), Accepter (assumer le risque résiduel après documentation et validation de la direction). La plupart des risques seront "Réduits" par des contrôles de l'Annexe A — documentez précisément quels contrôles s'appliquent.

Étape 5 — Estimation du risque résiduel

Après avoir défini les mesures de traitement, réévaluez la criticité en tenant compte de l'efficacité attendue des contrôles. La criticité résiduelle doit être inférieure ou égale au seuil d'acceptation du risque. Si ce n'est pas le cas, soit vous renforcez les mesures, soit vous acceptez formellement le risque résiduel avec validation de la direction.

Étape 6 — Transfert vers le Plan de Traitement des Risques

Chaque mesure de traitement identifiée génère une ligne dans le Plan de Traitement des Risques (RTP). Le template contient des liens hypertexte automatiques vers notre template RTP ISO 27001 pour faciliter ce transfert. Le RTP précisera les responsables, les ressources, les échéances et les indicateurs de suivi pour chaque action.

Étape 7 — Validation par la direction

Le registre des risques finalisé et le RTP associé doivent être validés formellement par la direction générale. Cette validation est exigée par la clause 6.1.3 : la direction doit approuver le plan de traitement des risques et accepter les risques résiduels. Conservez la preuve de cette approbation (signature, email, PV de réunion) — c'est une evidence systématiquement demandée en audit.

Étape 8 — Mise à jour et revue périodique

Le registre doit être revu au moins annuellement (clause 9.1) et à chaque changement significatif (nouveau projet SI, réorganisation, incident majeur, nouvelle menace identifiée dans le panorama ANSSI). Chaque révision est horodatée dans la colonne "Date de révision" et l'historique des versions est conservé dans le système de gestion documentaire. Voir notre procédure de gestion documentaire SMSI.

Tableau des contrôles / checklist complète

Voici la checklist des 30 points de contrôle essentiels pour valider la conformité de votre registre des risques lors d'un audit ISO 27001 :

Points de vigilance pour l'audit de certification

Piège 1 — Registre statique préparé juste avant l'audit

L'erreur la plus fréquente : créer ou mettre à jour le registre des risques à la hâte juste avant l'audit. Les auditeurs expérimentés vérifieront les métadonnées des fichiers et demanderont les versions précédentes. Sans historique de révision crédible (révisions trimestrielles ou semestrielles au minimum), l'auditeur considérera que le processus de gestion des risques n'est pas opérationnel. Remédiation : instaurez des revues trimestrielles du registre, même brèves, avec un compte rendu daté.

Piège 2 — Incohérence entre le registre, le SoA et le RTP

Les auditeurs recoupent systématiquement les trois documents : un risque présent dans le registre doit avoir des contrôles associés dans le SoA, et ces contrôles doivent apparaître dans le RTP si leur mise en œuvre est incomplète. Toute incohérence génère une non-conformité mineure au minimum. Remédiation : utilisez l'onglet "Lien SoA" du template pour maintenir la cohérence automatiquement.

Piège 3 — Absence de propriétaire de risque identifié

ISO 27001:2022 exige que chaque risque ait un propriétaire désigné, responsable de son traitement. Un registre avec des cellules vides dans la colonne "Propriétaire" ou avec "RSSI" systématiquement indiqué pour tous les risques sera questionné. Les propriétaires de risques doivent être des responsables métier, pas uniquement des personnes de l'équipe sécurité. Remédiation : désignez des propriétaires métier (DRH pour les risques RH, DSI pour les risques infrastructure, etc.).

Piège 4 — Risques résiduels jamais inférieurs au seuil d'acceptation

Si tous vos risques résiduels restent au-dessus du seuil d'acceptation sans validation formelle de la direction, c'est une non-conformité directe à la clause 6.1.3f. L'auditeur demandera la preuve d'acceptation formelle pour chaque risque résiduel supérieur au seuil. Remédiation : pour chaque risque résiduel élevé, obtenez une validation signée de la direction et consignez-la dans le PV de revue de direction.

Piège 5 — Critères d'évaluation non documentés

Si vous ne pouvez pas montrer à l'auditeur les critères exacts utilisés pour noter l'impact et la vraisemblance, et si deux évaluateurs différents obtiendraient des résultats différents, votre processus n'est pas cohérent au sens de la clause 6.1.2c. Remédiation : utilisez l'onglet "Guide méthodologique" du template qui formalise les barèmes et rendez-le opposable en le faisant valider par la direction.

Piège 6 — Menaces génériques non adaptées au contexte

Un registre contenant uniquement des menaces génériques ("cyberattaque", "panne système") sans lien avec votre contexte spécifique (secteur, profil d'attaquants, dépendances critiques) manque de crédibilité. Remédiation : complétez votre catalogue de menaces avec les rapports ANSSI sectoriels et adaptez chaque scénario à votre réalité opérationnelle.

Piège 7 — Périmètre du registre différent du périmètre SMSI

Si votre document de périmètre SMSI (clause 4.3) couvre 3 sites et 5 activités, votre registre doit couvrir tous les actifs associés à ces sites et activités. Un auditeur qui constate des trous de couverture posera des questions difficiles. Remédiation : croisez systématiquement le registre avec l'inventaire des actifs et le document de périmètre.

Piège 8 — Absence de traçabilité des décisions

Chaque changement important dans le registre (ajout d'un risque, modification d'une cotation, changement d'option de traitement) doit être tracé avec la date, l'auteur et la justification. L'historique des versions du fichier ne suffit pas — il faut une colonne "Motif de révision" ou un journal des modifications. Remédiation : ajoutez une colonne "Motif MAJ" et archivez les versions N-1 et N-2 du registre.

Piège 9 — Risques fournisseurs absents

La sous-traitance et les partenaires sont une source majeure de risques cybersécurité. Un registre qui ignore les risques liés aux prestataires critiques (hébergeur, ESN, éditeur SaaS) sera incomplet au regard de l'Annexe A (A.5.19 à A.5.23). Remédiation : ajoutez une section spécifique aux risques tiers dans le registre et croisez-la avec la liste des fournisseurs critiques.

Piège 10 — Risques de conformité légale non intégrés

Les risques de non-conformité (RGPD, NIS 2, réglementations sectorielles) doivent figurer dans le registre. Beaucoup d'organisations les oublient car elles les gèrent séparément. Remédiation : croisez le registre des risques avec le registre des exigences légales et contractuelles pour identifier les risques de conformité.

Intégration dans le SMSI

Le registre des risques est au centre de l'écosystème documentaire SMSI. Il reçoit ses données de l'inventaire des actifs et du contexte organisationnel, et alimente de nombreux documents en aval :

• En entrée — Inventaire des actifs (A.5.9) : chaque actif est la cible potentielle d'un ou plusieurs risques. La liste des actifs critiques détermine le périmètre d'analyse.
• En entrée — Analyse de contexte (clauses 4.1/4.2) : les enjeux internes et externes, les parties prenantes et leurs exigences fournissent le contexte dans lequel les risques se matérialisent.
• En sortie — Plan de Traitement des Risques (6.1.3) : chaque risque inacceptable génère une ou plusieurs actions dans le RTP, avec responsable, ressources et échéance.
• En sortie — Statement of Applicability (6.1.3) : les contrôles de l'Annexe A sélectionnés pour traiter les risques alimentent le SoA. La justification de chaque contrôle inclus ou exclu passe par le registre des risques.
• En sortie — Revue de direction (9.3) : le tableau de bord des risques est un input obligatoire de la revue de direction annuelle. La direction valide les risques résiduels et les niveaux d'acceptation.
• En boucle — Audit interne (9.2) : l'audit interne évalue l'efficacité des contrôles de traitement et peut identifier de nouveaux risques ou des réévaluations nécessaires.

Bonnes pratiques terrain

Organisez des ateliers pluridisciplinaires : les meilleures analyses de risques se font en équipes mixtes (IT, métier, RH, juridique, finance). Chaque département voit des risques invisibles aux autres. Planifiez des ateliers de 2 à 3 heures par famille d'actifs.

Utilisez les rapports ANSSI comme base documentaire : le panorama annuel de la cybermenace, les bulletins d'alertes et les guides sectoriels de l'ANSSI sont vos meilleurs alliés pour identifier des menaces crédibles et documentées. Un auditeur ne peut pas remettre en cause un risque basé sur un rapport ANSSI officiel.

Calibrez votre niveau de risque acceptable avec soin : un seuil trop bas force à traiter des risques mineurs au détriment des risques critiques. Un seuil trop haut laisse des risques significatifs sans traitement. La plupart des organisations fixent le seuil entre 6 et 9 sur une échelle 1-16.

Distinguez risque brut et risque net : certains outils et auditeurs parlent de "risque net" (prenant en compte les contrôles existants) plutôt que de "risque résiduel" (après traitement planifié). Assurez-vous que votre terminologie est cohérente avec celle de votre auditeur.

Intégrez la gestion des risques dans les projets IT : tout nouveau projet ou changement significatif (migration cloud, nouveau logiciel, réorganisation) doit déclencher une mise à jour du registre. Intégrez cette exigence dans votre processus de gestion de projet (ITIL, PRINCE2, ou votre méthode maison).

Prévoyez une revue post-incident : après tout incident de sécurité significatif, révisez le registre pour vérifier si le risque était identifié, si la cotation était adéquate, et si les mesures de traitement ont été efficaces. Cette boucle d'apprentissage est un signal fort de maturité pour les auditeurs.

FAQ

Quelle est la différence entre l'appréciation des risques (clause 6.1.2) et le traitement des risques (clause 6.1.3) ?

L'appréciation des risques (6.1.2) est le processus d'identification et d'évaluation : vous identifiez les actifs, les menaces, les vulnérabilités, et vous calculez la criticité de chaque risque selon vos critères. C'est un travail analytique qui répond à la question "Quels sont nos risques et quelle est leur gravité ?". Le traitement des risques (6.1.3) est la réponse opérationnelle : pour chaque risque inacceptable, vous choisissez une option de traitement (réduire, transférer, éviter, accepter), vous sélectionnez les contrôles de l'Annexe A appropriés, et vous produisez un plan d'action. C'est la réponse à "Que faisons-nous pour gérer ces risques ?". Les deux processus sont indissociables et constituent ensemble le cœur du SMSI ISO 27001. Le registre des risques documente l'appréciation, le RTP documente le traitement, et le SoA liste les contrôles sélectionnés pour justifier les choix de traitement. Ces trois documents sont vérifiés ensemble lors de tout audit de certification.

Combien de risques doit contenir un registre pour une PME ?

Il n'existe pas de nombre minimum ou maximum imposé par la norme — la qualité prime sur la quantité. Pour une PME de 50 à 200 personnes avec un SMSI couvrant les activités informatiques principales, un registre de 30 à 80 risques identifiés est généralement représentatif d'une analyse sérieuse. En dessous de 20 risques, l'auditeur pourrait questionner l'exhaustivité de l'analyse. Au-delà de 150-200 risques, le registre devient difficile à maintenir et à piloter efficacement — il vaut mieux regrouper certains risques similaires en scénarios génériques. L'important est que le registre couvre toutes les familles de menaces pertinentes (erreurs humaines, cyberattaques, défaillances techniques, événements naturels, problèmes de conformité) et tous les actifs critiques du périmètre SMSI. Une bonne règle pratique : un minimum de 3 à 5 risques par actif critique identifié dans l'inventaire des actifs.

Peut-on utiliser une méthode quantitative plutôt que qualitative pour l'évaluation des risques ?

ISO 27001 n'impose pas de méthode spécifique — qualitative (niveaux 1-4) ou quantitative (en euros ou pourcentages) — tant que la méthode est cohérente, documentée et approuvée. L'approche qualitative (utilisée dans ce template) est la plus répandue car elle est plus facile à mettre en œuvre et à faire comprendre aux parties prenantes non techniques. L'approche quantitative (FAIR — Factor Analysis of Information Risk, par exemple) donne des résultats en termes financiers (coût espéré annuel de l'incident) mais demande des données historiques souvent difficiles à obtenir. La plupart des auditeurs ISO 27001 sont habitués aux deux approches. Si vous optez pour une approche mixte (qualitative pour l'évaluation, quantitative pour la priorisation financière), documentez clairement la méthode de conversion. Quelle que soit la méthode choisie, les critères doivent être définis avant l'analyse et appliqués de manière cohérente sur l'ensemble du périmètre.

Le registre des risques doit-il couvrir les risques RGPD ?

C'est une question fréquente qui mérite une réponse nuancée. ISO 27001 couvre la sécurité de l'information au sens large, ce qui inclut les données personnelles. Les risques liés aux violations de données personnelles (clause 6.1.2 ISO 27001) et les risques identifiés lors d'une AIPD/DPIA (Article 35 RGPD) se recoupent partiellement. Dans la pratique, de nombreuses organisations intègrent dans le registre ISO 27001 les risques de sécurité liés aux traitements de données personnelles (non-conformité RGPD, fuite de données, accès non autorisé à des données sensibles). Cela évite la duplication et facilite la cohérence. Cependant, le registre ISO 27001 ne remplace pas l'AIPD RGPD qui a ses propres exigences méthodologiques (analyse des droits et libertés des personnes, pas uniquement des risques organisationnels). Idéalement, les deux documents se référencent mutuellement et les analyses de risques sont alignées. Consultez le registre des exigences légales et contractuelles pour intégrer les obligations RGPD dans votre SMSI.

Comment gérer les risques liés aux prestataires et sous-traitants ?

Les risques liés à la chaîne d'approvisionnement sont l'un des points les plus scrutés dans les audits ISO 27001:2022, en raison des contrôles A.5.19 à A.5.23 de l'Annexe A dédiés à la sécurité des relations avec les fournisseurs. Dans le registre des risques, créez une catégorie spécifique "Risques tiers" qui couvre : la perte de confidentialité due à un prestataire (données partagées avec un sous-traitant non sécurisé), la défaillance d'un fournisseur critique (SaaS, hébergeur), la compromission via la chaîne logistique (supply chain attack comme SolarWinds). Pour chaque fournisseur critique identifié, évaluez le risque selon les mêmes critères que vos risques internes. Croisez le registre avec votre liste de fournisseurs et les clauses contractuelles de sécurité. Le référentiel ANSSI "SecNumCloud" et les bonnes pratiques de l'ENISA sur la chaîne d'approvisionnement vous fourniront des référentiels de contrôle complémentaires.

Quelle est la fréquence recommandée de révision du registre des risques ?

ISO 27001 exige une révision au moins annuelle du processus d'appréciation des risques (clause 9.1). En pratique, les organisations matures révisent leur registre plus fréquemment : une révision complète annuelle coïncidant avec la revue de direction, des mises à jour ponctuelles déclenchées par des événements significatifs (incident majeur, nouveau projet IT, réorganisation, alerte ANSSI importante, nouveau cadre réglementaire). Pour les organisations en cours de première certification, il est conseillé de faire une révision intermédiaire 6 mois après la première analyse complète, car l'expérience de mise en œuvre révèle souvent des risques sous-estimés ou de nouveaux scénarios. Documentez chaque révision avec la date, les participants, les modifications apportées et les motifs. Cette traçabilité est une preuve de maturité du processus très appréciée des auditeurs. Intégrez les révisions dans votre planning SMSI annuel et nommez un responsable clairement identifié.

Comment justifier les risques exclus de l'analyse ?

La clause 6.1.2 n'exige pas de couvrir tous les risques possibles dans l'univers, mais tous les risques pertinents pour le périmètre SMSI défini. Cependant, les auditeurs peuvent questionner les risques apparemment importants absents du registre. Pour justifier les exclusions, documentez explicitement dans votre méthodologie les critères d'inclusion et d'exclusion des risques (seuil de pertinence minimum, périmètre d'analyse, sources de menaces considérées comme non pertinentes pour votre contexte). Par exemple, une PME en Île-de-France peut justifier l'exclusion des risques sismiques avec des données géographiques, mais pas des risques d'inondation ou de défaillance électrique. Pour les menaces cyber, référencez-vous au panorama de la cybermenace ANSSI pour justifier la pertinence des menaces retenues — c'est une source d'autorité que les auditeurs reconnaissent. Évitez de documenter des exclusions trop larges qui pourraient suggérer une analyse superficielle.

Le registre des risques est-il un document confidentiel ?

Oui, le registre des risques contient des informations hautement sensibles : il décrit précisément les vulnérabilités de votre organisation, les actifs critiques, les menaces jugées les plus probables et les lacunes de contrôle existantes. Ce document doit être classifié "Confidentiel" ou "Interne — Diffusion restreinte" selon votre politique de classification de l'information. L'accès doit être limité au RSSI, à la direction, aux auditeurs internes et aux consultants sous NDA. En audit de certification, l'auditeur y accède sous couvert de confidentialité contractuelle. Ne publiez jamais le registre des risques sur votre intranet ouvert ou dans des espaces de partage non contrôlés. Le template inclut une mention de classification en en-tête de chaque onglet. Lors de la revue de direction, présentez un tableau de bord synthétique (sans détail des vulnérabilités) plutôt que le registre complet aux participants n'ayant pas besoin d'y accéder en intégralité.

Comment intégrer les retours des audits internes dans le registre ?

Les audits internes (clause 9.2) sont une source précieuse d'information pour mettre à jour le registre des risques. Chaque non-conformité ou observation identifiée en audit interne doit être analysée sous l'angle du risque : quel risque cette non-conformité révèle-t-elle ou aggrave-t-elle ? Le registre doit être mis à jour pour refléter cette information. Voici le processus recommandé : après chaque audit interne, le RSSI passe en revue les constats avec le propriétaire du registre des risques. Les constats qui révèlent un risque non encore identifié génèrent un nouveau scénario de risque. Les constats qui montrent qu'un contrôle de traitement est inefficace conduisent à réévaluer la criticité résiduelle du risque associé. Ces mises à jour sont documentées avec la référence du rapport d'audit en motif de révision. Ce cycle (audit → mise à jour registre → ajustement RTP → nouveau cycle d'audit) est la démonstration concrète de l'amélioration continue exigée par la clause 10.2.

Peut-on utiliser un outil GRC au lieu d'un template Excel ?

Absolument. Des outils GRC (Governance, Risk and Compliance) comme Archer, ServiceNow GRC, OneTrust, Qualys VMDR, ou des solutions open-source comme Eramba sont parfaitement adaptés à la gestion du registre des risques ISO 27001. Ils offrent des avantages significatifs : workflows d'approbation, notifications automatiques, reporting en temps réel, intégration avec les outils de sécurité. Cependant, pour les organisations en première certification ou avec des ressources limitées, ce template Excel est une solution robuste et immédiatement opérationnelle. Le choix de l'outil n'affecte pas la conformité à la norme — l'auditeur évalue le processus et les résultats, pas l'outil. Si vous migrez d'un Excel vers un outil GRC, prévoyez une période de transition avec les deux systèmes en parallèle et assurez la continuité de l'historique. Consultez notre article sur les outils GRC pour ISO 27001 pour un comparatif des solutions disponibles.