Gestion des risques : la démarche, les rôles et le cas informatique

La gestion des risques est la démarche par laquelle une organisation repère ce qui pourrait l'empêcher d'atteindre ses objectifs, décide ce qu'elle accepte, traite le reste et suit le tout dans le temps. Elle concerne tous les risques, financiers, juridiques, opérationnels, d'image, et de plus en plus les risques informatiques, que NIS 2 et DORA obligent désormais à piloter au niveau de la direction. Voici la démarche, l'appétence pour le risque, la répartition des rôles, puis ce qui change quand le risque est informatique.

La norme ISO 31000 définit le risque comme l'effet de l'incertitude sur les objectifs. Deux idées découlent de cette définition très courte. Un risque n'existe que par rapport à un objectif : livrer à temps, rester solvable, protéger les données des clients. Et un effet peut être négatif ou positif : la gestion des risques aide aussi à saisir des opportunités, pas seulement à éviter des pertes.

La gestion des risques, que l'ISO appelle management du risque, désigne les activités coordonnées qui permettent de diriger et de piloter l'organisation vis-à-vis du risque. Elle ne se résume donc pas à une liste de risques : elle comprend des critères fixés par la direction, des décisions, des responsables, un suivi et un compte rendu. À l'échelle de toute l'entreprise, on parle de gestion des risques d'entreprise, ou ERM (enterprise risk management).

Il ne faut pas la confondre avec l'analyse de risques, qui n'en est qu'une étape : identifier et estimer les risques d'un périmètre donné. La gestion des risques décide ensuite quoi en faire et s'assure que les décisions sont tenues. Elle forme, avec la gouvernance et la conformité, le « R » de la GRC.

Deux référentiels généraux dominent, complétés par des méthodes propres à chaque domaine :

• ISO 31000:2018 donne des lignes directrices applicables à toute organisation : des principes, un cadre organisationnel et un processus. Elle n'est pas certifiable.
• Le COSO ERM, publié en 2017 sous le titre « Integrating with Strategy and Performance » par le COSO, l'organisme à l'origine du référentiel de contrôle interne du même nom, insiste sur le lien entre risque, stratégie et performance. Il est très utilisé dans les groupes cotés.
• Les méthodes spécialisées appliquent la même logique à un domaine : ISO 27005 et EBIOS Risk Manager pour la sécurité de l'information, ISO 22301 pour la continuité d'activité.

Le métier de celui qui anime le dispositif, ses missions et sa place dans l'organisation sont décrits dans notre article sur le risk manager.

1. Fixer le contexte et les critères. Quels objectifs, quel périmètre, quelles parties prenantes ? Quelles échelles de gravité et de vraisemblance, et quel niveau de risque la direction accepte-t-elle ? Ces critères doivent être les mêmes pour tous les domaines, sinon les risques ne se comparent pas.
2. Identifier les risques. Ateliers avec les métiers, revue des incidents passés, des audits, des contrats, de la veille réglementaire. Chaque risque se décrit par une cause, un événement et une conséquence sur un objectif.
3. Analyser. Estimer la gravité des conséquences et la vraisemblance de l'événement, en tenant compte des mesures déjà en place. Le produit des deux donne un niveau, que l'on place sur une matrice des risques.
4. Évaluer. Comparer chaque niveau aux critères fixés au départ : le risque est-il acceptable, ou faut-il agir ? C'est ici que l'appétence pour le risque intervient.
5. Traiter. Pour chaque risque à traiter, choisir une option : le réduire par des mesures, le partager (contrat, assurance), l'éviter en renonçant à l'activité, ou le conserver par une décision éclairée. ISO 31000 cite aussi la prise de risque délibérée pour saisir une opportunité.
6. Suivre et rendre compte. Vérifier que les mesures sont mises en œuvre et efficaces, réévaluer quand le contexte change, rendre compte à la direction. Le risque résiduel obtenu doit être accepté formellement par le propriétaire du risque.

Deux activités accompagnent toutes les étapes selon ISO 31000 : la communication et la consultation des parties prenantes, et l'enregistrement des résultats. Le schéma ci-dessous montre le cœur de la démarche sur quatre risques d'une entreprise de services.

L'appétence pour le risque désigne la quantité et le type de risque qu'une organisation est prête à rechercher ou à conserver pour atteindre ses objectifs. Le vocabulaire de l'ISO sur le management du risque la définit ainsi depuis le Guide 73 de 2009, remplacé depuis par ISO 31073, et le COSO en fait un élément central de la stratégie. Ce n'est pas un chiffre unique : une banque peut avoir une forte appétence pour le risque de crédit, qui est son métier, et une appétence quasi nulle pour la fuite de données de ses clients.

En pratique, elle se traduit en trois éléments :

• une déclaration de la direction, en quelques phrases par grande catégorie de risque (« nous n'acceptons aucune interruption de plus de 24 heures de nos services aux clients ») ;
• des seuils sur la matrice des risques, qui séparent ce qui est acceptable, ce qui demande un traitement et ce qui exige une décision de la direction ;
• des indicateurs qui alertent quand on s'en approche : nombre de risques au-dessus du seuil, mesures en retard, incidents.

Sans appétence explicite, chaque équipe fixe sa propre limite, et la direction découvre au moment d'un incident un risque que personne n'avait décidé de garder. Les textes récents vont dans ce sens : DORA demande une stratégie de résilience, approuvée par l'organe de direction, qui fixe le niveau de tolérance au risque lié aux technologies de l'information et de la communication (TIC) en cohérence avec l'appétence pour le risque de l'entité, et NIS 2 lui demande d'approuver les mesures de gestion des risques cyber.

La gestion des risques échoue rarement par manque de méthode ; elle échoue faute de responsables. Le modèle des trois lignes de l'Institute of Internal Auditors (IIA), mis à jour en juillet 2020 et qui a remplacé le modèle des « trois lignes de défense », sert de repère à la plupart des organisations :

Le modèle de 2020 insiste sur la coopération plutôt que sur la défense, et sur l'indépendance de l'audit interne vis-à-vis de la direction. Le secteur financier l'a intégré dans la loi : l'article 6 de DORA demande de séparer les fonctions de gestion du risque lié aux TIC, de contrôle et d'audit interne, selon le modèle des trois lignes ou un modèle interne équivalent, et l'article 5 confie à l'organe de direction la responsabilité ultime de ce risque. Dans une PME, une même personne tient souvent plusieurs rôles ; l'essentiel est que chaque risque ait un propriétaire nommé, et que celui qui gère un risque ne soit pas le seul à juger s'il est bien géré.

La gestion des risques informatiques applique la même démarche aux technologies de l'information. Le périmètre est plus large que la seule cybersécurité :

• les attaques : rançongiciel, hameçonnage, vol de données, compromission d'un compte d'administration ;
• les défaillances : panne d'un centre de données, erreur de manipulation, mise à jour qui bloque la production ;
• les tiers : défaillance ou compromission d'un hébergeur, d'un éditeur ou d'un infogérant (voir la gestion des risques tiers) ;
• l'obsolescence et la dette technique : systèmes plus maintenus, compétences rares ;
• les projets : nouvelles applications, migrations vers le nuage, usage de l'intelligence artificielle.

Des méthodes spécialisées

Pour ces risques, on utilise des méthodes dédiées. ISO 27005 décline le processus d'ISO 31000 pour la sécurité de l'information. EBIOS Risk Manager, la méthode de l'ANSSI, part des valeurs métier et des scénarios d'attaque les plus vraisemblables. Les besoins de sécurité se cotent en disponibilité, intégrité, confidentialité et preuve (DICP). Les tests d'intrusion et les audits viennent ensuite vérifier que les mesures tiennent.

Des obligations nouvelles

La gestion des risques informatiques n'est plus seulement une bonne pratique. L'article 21 de NIS 2 impose aux entités essentielles et importantes des mesures de gestion des risques cyber, fondées sur une approche tous risques, et l'article 20 en rend la direction responsable (voir notre article sur NIS 2). DORA impose au secteur financier un cadre de gestion du risque lié aux TIC complet et documenté, décrit dans notre chapitre du guide DORA.

Un même cadre pour tous les risques

Le piège est de traiter le risque informatique à part, dans un vocabulaire que la direction ne lit pas. Le guide publié en 2019 par l'ANSSI et l'AMRAE, l'association des professionnels du risque et des assurances, le dit clairement : le risque numérique est un risque d'entreprise, à piloter au plus haut niveau. Concrètement, utilisez les mêmes échelles de gravité que les autres risques, exprimez les conséquences en impact sur l'activité (arrêt de la production, perte de clients, sanction), et faites remonter les principaux scénarios dans la cartographie des risques de l'entreprise. La cartographie des processus aide à faire ce lien entre systèmes et activités.

• Le registre des risques : un risque par ligne, avec sa description, son propriétaire, ses cotations brute et résiduelle, ses mesures et leur échéance.
• La matrice et la cartographie : la matrice des risques place chaque risque selon sa gravité et sa vraisemblance ; la cartographie des risques donne la vue d'ensemble pour la direction.
• Le plan de traitement : les mesures décidées, leurs responsables et leurs échéances, suivies jusqu'à leur mise en œuvre.
• Les indicateurs : nombre de risques au-dessus de l'appétence, part des mesures en retard, risques acceptés dont la décision arrive à échéance, incidents rapprochés des risques identifiés. Notre article sur le tableau de bord SSI en donne des exemples pour le volet cyber.

Dans un tableur, ces éléments vivent séparément et se désynchronisent vite : la mesure avance, mais le niveau de risque reste celui de l'an dernier.

• Un inventaire annuel. Une liste refaite chaque année pour le comité d'audit, sans lien avec les décisions prises entre-temps.
• Des échelles différentes selon les équipes. Le « critique » du RSSI ne vaut pas le « critique » du directeur financier, et rien ne se compare.
• Des risques sans propriétaire, ou attribués à la fonction risques plutôt qu'au métier qui les porte.
• Des risques mal formulés : « la cybersécurité » n'est pas un risque ; « un rançongiciel arrête la production pendant une semaine » en est un.
• Des acceptations implicites : un risque élevé que l'on ne traite pas, sans décision écrite ni date de revue.
• Le risque informatique à part, dans un jargon technique, absent de la cartographie de l'entreprise.