6.1.2 — Appréciation des risques de sécurité

L’exigence qui transforme le « on pense être sécurisés » en une réponse défendable et reproductible à « qu’est-ce qui pourrait mal aller, et à quel point ».

En langage clair

La sous-clause 6.1.2 exige que vous définissiez et appliquiez une méthode cohérente pour identifier vos risques de sécurité, estimer leur gravité et leur probabilité, puis les hiérarchiser. Le mot-clé est reproductible : deux personnes appliquant votre méthode aux mêmes informations doivent arriver à des résultats comparables.

Pourquoi cette exigence existe

On ne peut pas protéger ce qu’on n’a pas identifié. Cette exigence garantit que vos décisions de sécurité reposent sur une évaluation structurée plutôt que sur l’intuition ou la dernière mode technologique. Elle impose aussi la cohérence dans le temps : sans méthode définie, chaque réévaluation donnerait des résultats différents et ininterprétables.

Scénario : une entreprise investit massivement dans un pare-feu haut de gamme parce que « c’est ce qui se fait », mais n’a jamais évalué ses risques. Résultat : son vrai point faible — des sauvegardes jamais testées et des accès partagés — reste ignoré, jusqu’au jour où un rançongiciel frappe. Une appréciation des risques aurait fait remonter ces priorités.

Ce que la norme attend

La norme demande d’établir et de maintenir des critères de risque, puis d’appliquer un processus qui produit des résultats cohérents et reproductibles. Concrètement, elle attend que vous fassiez cinq choses : définir vos critères d’acceptation du risque et vos critères pour réaliser les appréciations ; identifier les risques qui menacent la confidentialité, l’intégrité et la disponibilité de vos informations dans le périmètre du SGSI ; désigner des propriétaires de risque responsables de chacun ; analyser chaque risque en estimant ses conséquences potentielles et sa vraisemblance ; puis évaluer les résultats en les comparant à vos critères pour établir des priorités de traitement. Vous êtes libre de la méthode (par actif, par scénario, qualitative ou quantitative), tant qu’elle est définie et appliquée de façon constante.

En pratique

• Choisir une approche : par scénario (« un employé perd un portable non chiffré ») ou par actif (« base de données clients »). L’approche par scénario est souvent plus parlante pour une PME.
• Définir une échelle simple : par exemple une cotation de 1 à 5 pour l’impact et de 1 à 5 pour la probabilité, dont le produit donne un niveau de risque.
• Fixer le seuil d’acceptation : au-delà de quel niveau un risque doit-il obligatoirement être traité ? Ce seuil est une décision de la direction.
• Tenir un registre des risques : un tableau listant chaque risque, son propriétaire, son impact, sa probabilité, son niveau et le traitement prévu.
• Nommer des propriétaires de risque : une personne responsable par risque — pas « le service TI » en général, mais un rôle identifiable.

Preuves que l’auditeur demandera

• La méthodologie d’appréciation des risques documentée (critères, échelles, seuil d’acceptation).
• Le registre des risques renseigné, avec propriétaires, niveaux et priorités.
• La preuve que la méthode a été réellement appliquée (dates, participants, données source).
• La cohérence entre les risques identifiés et le périmètre du SGSI défini à la clause 4.
• La traçabilité vers le traitement (6.1.3) : chaque risque significatif doit trouver une suite.

Pièges courants

• Une méthode implicite : faire l’exercice « dans sa tête » sans documenter critères ni échelles — impossible à reproduire, donc non conforme.
• Un registre figé : une appréciation faite une fois puis jamais revue, alors que les risques évoluent.
• Des propriétaires fantômes : attribuer les risques à un service entier plutôt qu’à une personne responsable.
• Copier un registre générique : reprendre une liste de risques type sans l’ancrer dans vos actifs et votre contexte réels.
• Confondre appréciation et traitement : lister les risques (6.1.2) et décider des mesures (6.1.3) sont deux étapes distinctes ; les mélanger brouille la logique.

Exigences liées

• 6.1.1 Généralités — le cadre général des actions face aux risques et opportunités.
• 6.1.3 Traitement des risques — l’étape suivante : décider quoi faire des risques appréciés et produire la SoA.
• 4.3 Périmètre du SGSI — l’appréciation ne porte que sur le périmètre défini ici.
• 8.2 Appréciation des risques (opérationnel) — la mise en œuvre récurrente de ce même processus.
• Clause parente : 6.1 Actions face aux risques et opportunités

Correspondance 2013 → 2022