EBIOS RM et ISO 27005 : cadrer l’analyse de risques

Choisir EBIOS Risk Manager ou ISO 27005 n’est pas la première décision d’une analyse de risques. Commencez par préciser le service à protéger, les personnes qui peuvent accepter un risque et les décisions que l’étude doit permettre. Une matrice remplie sans responsable ni action ne protège pas une activité.

Ce guide propose une grille de cadrage pour articuler risques de sécurité, obligations RGPD et pilotage des mesures.

EBIOS RM et ISO 27005 : deux ressources à situer

L’ANSSI présente EBIOS Risk Manager comme une démarche combinant socle de sécurité et scénarios de menace intentionnelle. Ses cinq ateliers portent sur le cadrage, les sources de risque, les scénarios stratégiques, les scénarios opérationnels et le traitement du risque. L’écosystème des fournisseurs intervient dans cette analyse ; il ne constitue pas une question extérieure à la méthode.

La fiche officielle d’ISO/IEC 27005:2022 décrit des orientations pour gérer les risques de sécurité de l’information et accompagner ISO 27001. Ce guide ne délivre pas, par lui-même, une certification de l’organisation. Évitez l’opposition simpliste entre une méthode exclusivement « par actifs » et une autre exclusivement « par scénarios ».

Pour choisir, demandez à l’équipe de produire un exemple de décision : quel risque, sur quel service, avec quelle mesure et quel arbitrage ? La réponse est plus utile qu’une préférence abstraite pour un référentiel.

Choisir une démarche compatible avec le travail à produire

Commencez par trois questions pratiques. Disposez-vous déjà d’un SMSI et de critères de risque utilisés par la direction ? Faut-il approfondir les chemins d’attaque d’un service exposé ? Les participants peuvent-ils consacrer le temps nécessaire aux échanges métier et techniques ? Les réponses permettent de cadrer la mission et les compétences nécessaires sans opposer artificiellement les deux ressources.

Si un système de management existe, demandez comment l’étude rejoindra les décisions, responsabilités et revues déjà organisées. Si vous retenez EBIOS RM, précisez les résultats attendus des ateliers et les personnes capables de discuter les dépendances et scénarios. Un prestataire doit pouvoir expliquer cette articulation avant de remettre une liste standard de livrables.

La grille proposée ci-dessous porte sur la commande de l’étude ; elle ne reproduit pas une exigence détaillée d’ISO 27005.

Demandez aussi les limites annoncées. La partie par scénarios d’EBIOS RM se concentre sur des menaces intentionnelles et ciblées, comme le précise l’ANSSI. Le dossier global ne doit pas faire disparaître une panne, une erreur humaine ou une dépendance critique au motif qu’elle ne correspond pas au scénario d’attaque retenu. Précisez où ces sujets sont examinés dans votre démarche de sécurité.

Cadrer l’étude avant les ateliers

Voici une fiche de préparation proposée pour une PME :

Un périmètre réduit peut être pertinent, à condition de ne pas exclure silencieusement sa dépendance principale. Un logiciel de paie hébergé dépend aussi de l’identité, des exports, de l’assistance et des sauvegardes.

La politique de sécurité fixe les règles communes ; l’étude explique comment elles répondent aux risques du service étudié.

Réunir des éléments vérifiables avant de coter

Rassemblez le schéma du service, les accès importants, les principaux échanges de données et les engagements envers les utilisateurs. Pour chaque pièce, notez la date, le périmètre et la personne capable d’expliquer ses limites. Un schéma d’architecture prévu pour le prochain déploiement ne prouve pas l’organisation actuelle ; une procédure écrite ne prouve pas que les équipes disposent des moyens de l’appliquer.

Classez les informations selon leur statut : fait vérifié, hypothèse de travail ou question ouverte. Une hypothèse reste utilisable pour raisonner, à condition de la rendre visible. Si l’équipe suppose qu’une sauvegarde est isolée mais ne dispose pas de confirmation, elle ne doit pas présenter la résistance de cette sauvegarde comme acquise dans le risque résiduel.

Conservez les divergences entre les métiers et la technique. Lorsque le métier annonce une reprise possible en quelques heures, demandez quelles données, personnes et dépendances seraient nécessaires. Lorsque l’équipe technique annonce une forte disponibilité, demandez ce qui resterait accessible pour l’utilisateur final. L’objectif est d’obtenir une description commune de la conséquence, pas de choisir la formulation la plus rassurante.

Ne pas confondre risque de sécurité et AIPD

L’Art. 32(1)–(2) du RGPD exige des mesures appropriées au risque, en tenant compte notamment du contexte et des risques pour les droits et libertés. Il n’impose pas de choisir EBIOS RM ou ISO 27005, ni de produire un document portant obligatoirement ce nom.

L’Art. 35(1) impose une analyse d’impact lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les personnes. Son contenu comprend, selon l’Art. 35(7), la nécessité et la proportionnalité du traitement ainsi que les risques et mesures envisagées. Une étude de disponibilité du système ne suffit donc pas à couvrir une AIPD.

Exemple hypothétique : un outil de contrôle des salariés peut être très bien protégé contre les intrusions tout en collectant trop d’informations ou en produisant des décisions injustifiées. Les deux analyses peuvent partager des preuves ; elles ne posent pas toutes les mêmes questions.

Définir ce que signifient gravité et vraisemblance

Avant de remplir une matrice, écrivez les critères associés à ses niveaux. Une gravité « forte » devrait renvoyer à des conséquences identifiables pour le service, ses engagements et les personnes concernées. La vraisemblance doit être expliquée par les hypothèses retenues sur le scénario, les accès et les protections, sans devenir un pourcentage inventé.

Évitez de fusionner des conséquences très différentes dans une moyenne trompeuse. Une interruption brève avec divulgation de données sensibles peut demander une décision distincte d’une interruption plus longue sans divulgation. Le risque pour les personnes ne se mesure pas uniquement au chiffre d’affaires perdu par l’organisme.

Pour comparer deux versions d’une étude, vérifiez si les critères ont changé. Une case devenue verte après modification de l’échelle ne démontre pas une réduction effective du risque. Conservez la justification du changement et expliquez les conséquences pour les arbitrages antérieurs.

Transformer une cotation en décision vérifiable

Pour chaque risque retenu, utilisez une ligne de suivi comprenant : scénario, hypothèses, mesures déjà effectives, mesure supplémentaire, responsable, échéance, preuve attendue et risque résiduel. Distinguez une mesure achetée d’une mesure déployée, puis d’une mesure dont l’efficacité a été vérifiée.

Un score « faible » sans justification n’est pas une décision. Conservez les désaccords importants : un métier peut accepter une interruption que la direction commerciale considère comme incompatible avec un engagement client.

Le guide de sélection d’un logiciel GRC aide à examiner l’historique des arbitrages et des preuves. L’outil doit permettre de comprendre une ancienne décision, pas seulement afficher sa dernière couleur.

Faire décider sur des options et leurs limites

Une restitution utile présente plusieurs réponses possibles lorsque le contexte le permet : réduire un accès, modifier le service, renforcer une protection ou différer une fonctionnalité. Pour chaque option, exposez le risque traité, les dépendances, l’effort de mise en œuvre et les risques qui subsistent. Le décideur doit comprendre pourquoi une mesure est proposée et ce qu’elle ne résout pas.

Dans l’exemple hypothétique de contrôle des salariés, renforcer l’authentification peut protéger l’accès aux données sans rendre nécessaire leur collecte détaillée. L’analyse peut conduire à revoir les informations collectées ou les usages autorisés, en plus des protections techniques. Ce raisonnement reste un exemple pédagogique, sans outil ni dispositif réel évalué ici.

Enfin, l’acceptation interne d’un risque n’autorise pas à écarter une obligation légale. Lorsque l’AIPD révèle un risque élevé qui ne peut pas être suffisamment atténué, la consultation préalable de l’autorité est requise dans les conditions de l’Art. 36(1). Un compte rendu signé par la direction ne remplace pas cette étape. Source : RGPD, Art. 36.

Réexaminer lorsque les hypothèses changent

Fixez une cadence de revue adaptée au périmètre et aux exigences qui lui sont réellement applicables. Ajoutez des déclencheurs : nouvel hébergeur, accès d’administration modifié, incident, changement d’usage ou résultat d’un audit de sécurité.

Le RGPD prévoit une évaluation régulière de l’efficacité des mesures à l’Art. 32(1)(d) ; il ne fixe pas une périodicité annuelle uniforme pour toutes les analyses de risques. Pour l’AIPD, l’Art. 35(11) vise notamment le changement du risque présenté par le traitement. Les exigences d’un SMSI ISO 27001 et d’un régime sectoriel doivent être examinées séparément.

Ce qu’il faut retenir

• Définissez la décision et le périmètre avant de choisir la méthode.
• Reliez chaque risque à une action, un responsable et une preuve.
• Évaluez les conséquences pour les personnes, au-delà de la perte d’activité.
• Réexaminez les hypothèses après les changements significatifs.

FAQ

EBIOS RM est-elle obligatoire au titre du RGPD ?

Le RGPD n’impose pas cette méthode. L’organisme doit pouvoir expliquer pourquoi ses mesures sont appropriées aux risques de ses traitements.

Une analyse de risques remplace-t-elle l’AIPD ?

Non. Elle peut alimenter sa partie sécurité, mais l’AIPD examine aussi la nécessité, la proportionnalité et les risques pour les personnes.

Faut-il acheter un logiciel pour commencer ?

Vous pouvez commencer avec une fiche structurée et un suivi des décisions. L’achat devient pertinent lorsqu’il répond à des difficultés concrètes de collaboration, de preuve ou de traçabilité.

Recevez nos analyses sur la sécurité et la conformité.

Thiébaut Devergranne, docteur en droit et praticien du droit des technologies depuis plus de vingt ans.