Registre de risques : les quatre propriétaires de chaque risque

Votre rendez-vous du dimanche · Série risques

« La TI » n'est pas un propriétaire de risque. Dimanche dernier, nous vous proposions d'écrire dix scénarios qui arrêteraient l'entreprise, puis d'inscrire à côté de chacun le nom de la personne qui en répond aujourd'hui. Si vous avez fait l'exercice, la colonne « propriétaire » a probablement trois défauts : des trous, des noms de services plutôt que des noms de personnes, et le même nom sur presque toutes les lignes.

Ce n'est pas un manque de rigueur. C'est que la question était trop courte. « Qui en répond ? » recouvre en réalité quatre travaux différents, que les organisations confient souvent à la même personne, ou à personne. Cette semaine, on les sépare.

Un mot, quatre travaux

Le vocabulaire des normes parle d'un seul « propriétaire du risque » : la personne qui a la responsabilité et l'autorité de le gérer. ISO/IEC 27001 demande d'en désigner un pour chaque risque identifié, et c'est à lui que revient d'approuver le plan de traitement et d'accepter le risque résiduel. La définition est juste. Mais dans une organisation réelle, la personne qui a l'autorité de dire « on accepte » n'est presque jamais celle qui applique les correctifs, ni celle qui regarde les indicateurs chaque semaine, ni celle qui présente le dossier au conseil.

D'où quatre rôles, que nous vous proposons de nommer séparément pour chaque scénario :

1. Celui qui accepte. Un membre de la direction qui a l'autorité budgétaire sur le processus touché. Il choisit le traitement (réduire, transférer, éviter ou accepter), il signe le niveau de risque résiduel qu'il est prêt à porter, et il décide de l'argent qu'on y met. C'est le propriétaire au sens des normes.
2. Celui qui traite. La personne qui exécute le plan : les correctifs, la segmentation, le contrat révisé, l'exercice de restauration. Elle a des échéances et rend compte de leur avancement à celui qui accepte.
3. Celui qui surveille. La personne qui mesure les indicateurs du scénario et qui donne l'alerte quand ils bougent : l'exposition qui réapparaît, la menace qui vise désormais votre secteur, le fournisseur dont la note se dégrade. Elle n'a pas à corriger ; elle a à voir, et à dire.
4. Celui qui rend compte. La personne qui présente le scénario au comité de direction ou au conseil, avec son niveau, son évolution et les décisions qu'on attend d'eux. C'est souvent le responsable de la sécurité ou du risque, et ce n'est pas un hasard : il traduit le travail des trois autres dans la langue de ceux qui arbitrent.

Les cadres publics décrivent la même séparation sous d'autres noms. Le modèle des trois lignes de l'Institute of Internal Auditors, révisé en juillet 2020, confie la gestion du risque aux rôles de première ligne, l'expertise, la surveillance et la remise en question aux rôles de deuxième ligne, et l'assurance indépendante à l'audit interne, sous la responsabilité ultime de l'organe de gouvernance devant les parties prenantes. Le NIST Cybersecurity Framework 2.0, publié en février 2024, en fait une catégorie de sa fonction Gouverner : la direction est responsable du risque cyber et en rend compte (GV.RR-01), et les rôles, responsabilités et pouvoirs liés à ce risque sont établis, communiqués, compris et appliqués (GV.RR-02). Pour les institutions financières fédérales, la ligne directrice B-13 du BSIF demande à la haute direction de confier la responsabilité du risque technologique et cyber à des cadres supérieurs. Aucun de ces textes ne dit « la TI s'en occupe ».

Un scénario, quatre noms

Reprenons le premier scénario de dimanche dernier : un groupe de rançongiciel chiffre l'ERP et ses sauvegardes ; la facturation et les expéditions s'arrêtent dix jours, et nos deux plus gros clients appliquent leurs pénalités de retard.

• Accepte : la vice-présidente des opérations. C'est son processus qui s'arrête, ses clients qui appliquent les pénalités, son budget qui paiera la reprise. C'est elle qui décide si dix jours d'arrêt possibles sont acceptables, ou s'il faut financer des sauvegardes isolées et un exercice de restauration pour ramener ce chiffre à trois.
• Traite : le directeur des TI. Il déploie les sauvegardes hors ligne, segmente l'ERP, durcit les accès administrateurs et organise le test de restauration, avec une date pour chaque étape.
• Surveille : le responsable de la sécurité. Il suit les expositions de l'ERP et de ses accès distants, les groupes de rançongiciel actifs dans votre secteur et la date du dernier test de restauration réussi. Si l'un de ces indicateurs bouge, il le dit à la vice-présidente avant le prochain comité, pas après.
• Rend compte : le chef de la sécurité de l'information, au comité d'audit, chaque trimestre : le niveau du scénario, ce qui a changé, ce qui reste ouvert et la décision attendue.

Dans une PME, deux de ces noms peuvent être la même personne. Ce n'est pas un problème tant que deux rôles précis restent séparés, ceux du piège suivant.

Les quatre façons de rater la colonne

La TI propriétaire de tout. C'est le défaut le plus répandu, et il est logique : la TI voit les failles, alors on lui confie les risques. Mais elle n'a ni l'autorité de décider qu'un arrêt de dix jours est acceptable, ni le budget pour l'éviter. Résultat : elle accepte par défaut des risques qui ne lui appartiennent pas, ou elle demande un budget sans pouvoir parler de la conséquence d'affaires. La TI est très souvent celle qui traite. Elle est rarement celle qui accepte.

Un service au lieu d'une personne. « Finances », « Opérations », « Sécurité ». Un service ne signe pas, ne se présente pas au comité et ne reçoit pas d'appel à 3 h du matin. Si la case contient un nom de service, elle est vide.

Celui qui traite accepte aussi. Quand la même personne exécute le plan et juge si le risque restant est acceptable, elle évalue son propre travail. Personne ne remet en question le moment où « assez » devient « suffisant ». C'est précisément la séparation que le modèle des trois lignes protège : celui qui gère le risque n'est pas celui qui le remet en question. Dans une petite organisation, ce sont ces deux rôles-là qu'il faut confier à deux personnes différentes, même si l'une d'elles porte aussi la surveillance.

Personne n'accepte. Le scénario est noté « élevé » depuis dix-huit mois, tout le monde le sait, et aucune décision n'a été prise. Ce n'est pas un risque accepté : c'est un risque abandonné. Un risque accepté porte une signature, une date et une échéance de révision. Sans elles, la ligne du registre décrit une inquiétude, pas une décision.

La matrice, sur une page

Ajoutez quatre colonnes à votre liste de scénarios, et une cinquième pour l'échéance de révision de l'acceptation. Trois lignes d'exemple :

• Rançongiciel sur l'ERP. Accepte : la VP Opérations. Traite : le directeur des TI. Surveille : le responsable de la sécurité. Rend compte : le CISO, au comité d'audit. Révision : mars 2027.
• Fraude au paiement. Accepte : la directrice financière. Traite : le contrôleur. Surveille : le responsable de la sécurité. Rend compte : le CISO, au comité d'audit. Révision : janvier 2027.
• Indisponibilité du fournisseur SaaS critique. Accepte : le VP Ventes. Traite : le responsable des achats. Surveille : le responsable des fournisseurs. Rend compte : le CISO, au comité de direction. Révision : décembre 2026.

Les noms de fonction sont des exemples ; dans votre registre, ce sont des noms de personnes. Trois règles suffisent pour la tenir. Un nom de personne par case, jamais un service. La colonne « accepte » contient uniquement des membres de la direction qui ont un budget. Et chaque acceptation a une date de révision : un risque accepté en 2026 n'est pas accepté pour toujours, parce que la menace, l'exposition et l'entreprise changent.

Le test de la semaine : trente minutes, quatre colonnes

Reprenez vos dix scénarios de dimanche dernier. Réunissez les mêmes trois personnes, finances, opérations et TI, et réglez la minuterie sur trente minutes.

1. Pour chaque scénario, remplissez les quatre colonnes avec des noms de personnes. Pas celles qui devraient, celles qui le font aujourd'hui. Laissez vide ce qui est vide.
2. Ajoutez la date de la dernière décision d'acceptation, s'il y en a une.
3. Comptez.

Quatre résultats doivent vous alerter. Une colonne « accepte » vide sur plus de la moitié des lignes : la direction n'a pas encore pris possession de son registre. Le même nom dans la colonne « accepte » et dans la colonne « traite » : personne ne remet en question le niveau de risque restant. Le directeur des TI dans la colonne « accepte » de plus de trois scénarios : la TI porte des décisions d'affaires qui ne sont pas les siennes. Aucune date d'acceptation : vos risques ne sont pas acceptés, ils sont tolérés sans que personne l'ait décidé.

Ce que vous devriez avoir dimanche prochain

Une page. Vos dix scénarios, quatre noms de personnes par ligne, les trous bien visibles, et pour chaque scénario déjà accepté, une date de révision. Les trous ne sont pas un échec : chacun est une conversation à avoir avec un membre de la direction cette semaine, et c'est la conversation qui fait d'un tableau un registre.

Où FortaRisks intervient

Les quatre rôles n'ont pas besoin du même écran. Forta Cockpit est la vue de ceux qui acceptent et qui rendent compte : chaque risque y porte son niveau inhérent et son niveau résiduel, le traitement choisi selon ISO 27005 (accepter, réduire, transférer, éviter), et une acceptation datée qui se rouvre d'elle-même à son échéance. Forta Actions est la vue de ceux qui traitent : une courte file d'actions, chacune avec un responsable, une urgence et une échéance, qui se ferme d'elle-même quand le signal disparaît. Entre les deux, ceux qui surveillent voient les signaux des autres modules remonter sans avoir à les chercher. Pour mettre des noms en face de vos premiers scénarios avec un expert, la session de priorisation part de vos actifs, de vos contrôles et de vos constats.

Dimanche prochain : l'exposition, ce que les attaquants voient d'abord. Avant de lire votre registre, un attaquant lit votre surface d'attaque. Comment la relier à vos scénarios, et à celui qui les surveille.

Sources : ISO, ISO/IEC 27001:2022, systèmes de management de la sécurité de l'information · ISO, ISO/IEC 27005:2022, lignes directrices pour la gestion des risques liés à la sécurité de l'information · The Institute of Internal Auditors, The IIA's Three Lines Model (juillet 2020) · NIST, Cybersecurity Framework 2.0 (CSWP 29), catégorie GV.RR · BSIF, ligne directrice B-13, gestion des risques liés aux technologies et du cyberrisque