Évaluation des risques ISO 27001 : processus, méthodologie et exemples

L’évaluation des risques est le moteur qui anime l’ensemble de votre Système de Management de la Sécurité de l’Information. Sans elle, votre ISMS n’est qu’un ensemble de politiques et de contrôles choisis par instinct plutôt que sur la base de preuves. ISO 27001 ne laisse rien à l’interprétation — la Clause 6.1.2 impose un processus formel et reproductible d’évaluation des risques qui identifie les menaces, évalue leur gravité et produit un plan de traitement des risques reliant chaque risque significatif à une réponse concrète.

Pour les entreprises SaaS, l’évaluation des risques détermine quels contrôles de l’Annexe A vous mettez en œuvre, lesquels vous excluez (documentés dans votre Déclaration d’applicabilité), et comment vous allouez des ressources de sécurité limitées. Une évaluation des risques qui reflète votre paysage réel de menaces — erreurs de configuration de l’infrastructure cloud, attaques de la chaîne d’approvisionnement via des dépendances open source, défaillances d’isolation des données multi-locataires — produit un ISMS qui protège véritablement votre entreprise. Une évaluation générique copiée à partir d’un modèle produit des constats d’audit et, pire encore, des vulnérabilités non traitées.

Ce guide parcourt l’ensemble du processus d’évaluation des risques ISO 27001 : ce que la norme exige, comment choisir et appliquer une méthodologie, comment noter et traiter les risques, et les considérations spécifiques qui s’appliquent aux organisations SaaS.

Que requiert ISO 27001 pour l’évaluation des risques ?

La Clause 6.1.2 d’ISO 27001 établit six exigences explicites pour le processus d’évaluation des risques liés à la sécurité de l’information. Comprendre chaque exigence est essentiel avant de commencer à construire votre méthodologie.

Exigence 1 : Établir et maintenir les critères d’évaluation des risques

Vous devez définir et documenter les critères que vous utiliserez pour évaluer les risques. Cela inclut vos critères d’acceptation des risques (quel niveau de risque résiduel est tolérable) et les critères de réalisation de l’évaluation des risques elle-même (comment vous mesurerez la probabilité et l’impact). Ces critères doivent être établis avant le début de l’évaluation — et non ajustés rétroactivement pour justifier des décisions déjà prises.

En pratique : Définissez vos échelles de notation des risques, vos seuils d’appétit pour le risque et les règles déterminant quand un risque doit être traité plutôt qu’accepté. Documentez-les dans votre politique de gestion des risques afin qu’ils soient cohérents entre les évaluations et vérifiables.

Exigence 2 : Assurer des résultats reproductibles et cohérents

Le processus d’évaluation des risques doit produire des résultats cohérents, valides et comparables lorsqu’il est répété. Cela signifie que votre méthodologie ne peut pas dépendre du jugement d’une seule personne sans structure. Deux équipes différentes menant la même évaluation sur le même périmètre devraient arriver à des conclusions raisonnablement similaires.

En pratique : Utilisez des échelles de notation définies, des critères documentés pour chaque niveau de notation et des ateliers structurés plutôt que des brainstormings ad hoc. Une matrice probabilité-impact 5x5 avec des descriptions écrites pour chaque niveau produit des résultats plus cohérents que « discuter et s’accorder sur une note ».

Exigence 3 : Identifier les risques liés à la sécurité de l’information

Vous devez identifier les risques associés à la perte de confidentialité, d’intégrité et de disponibilité de l’information dans le périmètre de l’ISMS. Cela nécessite une identification systématique — pas simplement une liste des menaces évidentes.

En pratique : Cela signifie identifier les actifs informationnels dans le périmètre, les menaces pesant sur ces actifs, les vulnérabilités que les menaces pourraient exploiter et les conséquences potentielles. Pour les entreprises SaaS, le périmètre couvre généralement l’infrastructure de production, les données clients, les systèmes internes qui soutiennent le service, ainsi que les personnes et processus qui les exploitent.

Exigence 4 : Analyser les risques identifiés

Chaque risque identifié doit être analysé pour déterminer sa probabilité d’occurrence et l’impact potentiel s’il se matérialise. Cette analyse produit le niveau de risque qui guide les décisions de traitement.

En pratique : Appliquez vos critères de notation de manière cohérente. Pour chaque risque, évaluez à la fois la probabilité que la menace exploite la vulnérabilité et l’impact sur l’activité si cela se produit. Documentez le raisonnement — pas seulement les chiffres.

Exigence 5 : Évaluer les risques identifiés

Vous devez comparer les résultats de l’analyse des risques avec vos critères d’acceptation des risques et prioriser les risques pour le traitement. L’évaluation détermine quels risques nécessitent une action et dans quel ordre.

En pratique : Les risques au-dessus de votre seuil d’acceptation nécessitent un traitement. Les risques en dessous peuvent être acceptés — mais l’acceptation doit être une décision documentée, pas un choix par défaut. La priorisation garantit que vous traitez les risques les plus critiques en premier, ce qui est important lorsque les ressources sont limitées (comme c’est toujours le cas dans les entreprises SaaS en croissance).

Exigence 6 : Documenter les résultats

Les résultats de l’évaluation des risques doivent être conservés en tant qu’informations documentées. Ceci n’est pas négociable. Votre registre des risques, la documentation de la méthodologie, la justification de la notation et les décisions de traitement sont tous des artefacts vérifiables.

En pratique : Maintenez un registre des risques qui capture chaque risque identifié, son analyse, son évaluation et la décision de traitement. Ce registre est un document vivant — il est revu et mis à jour tout au long du cycle de vie de l’ISMS, pas seulement lors des évaluations annuelles.

Choisir votre méthodologie d’évaluation des risques

ISO 27001 ne prescrit pas de méthodologie spécifique. La norme exige que l’approche choisie réponde aux six exigences ci-dessus, mais le cadre spécifique relève de votre décision. Cette flexibilité est intentionnelle — différentes organisations ont des profils de risque, des ressources et des niveaux de maturité différents.

Évaluation qualitative des risques

L’évaluation qualitative utilise des catégories descriptives (Élevé, Moyen, Faible ou des échelles numériques comme 1-5) plutôt que des valeurs financières précises. C’est l’approche la plus courante pour les entreprises SaaS qui poursuivent ISO 27001 pour la première fois.

Comment ça fonctionne : Les risques sont notés sur deux dimensions — probabilité et impact — en utilisant des échelles prédéfinies. Les scores sont multipliés ou combinés pour produire une note de risque globale qui détermine la priorité de traitement.

Avantages :

• Plus rapide à mettre en œuvre et plus facile à maintenir
• Ne nécessite pas de données actuarielles ou de chiffres de pertes historiques
• Accessible aux parties prenantes non spécialistes de la sécurité qui participent aux ateliers d’évaluation des risques
• Suffisante pour la certification — les auditeurs acceptent les approches qualitatives

Inconvénients :

• Subjective — différents évaluateurs peuvent attribuer des scores différents au même risque
• Ne produit pas d’estimations en valeur monétaire utiles pour les calculs de retour sur investissement des investissements en sécurité
• Peut conduire à un regroupement (tout est noté « Moyen ») si les échelles ne sont pas bien définies

Idéale pour : Les entreprises SaaS de moins de 500 employés, les organisations poursuivant une certification initiale, les équipes sans analystes de risques dédiés.

Évaluation quantitative des risques

L’évaluation quantitative attribue des valeurs monétaires à la fois à la probabilité d’occurrence et à l’impact potentiel. Elle utilise des formules comme la Perte Annuelle Prévisible (ALE) = Perte Unique Prévisible (SLE) x Taux d’Occurrence Annuel (ARO) pour produire des estimations de risque en valeur monétaire.

Comment ça fonctionne : Pour chaque risque, vous estimez le coût financier si l’événement se produit (SLE) et la fréquence à laquelle il est attendu par an (ARO). Le produit est la perte annuelle prévisible, qui peut être directement comparée au coût de l’atténuation pour déterminer si un investissement dans un contrôle est justifié.

Avantages :

• Produit des chiffres financiers qui parlent à la direction et aux conseils d’administration
• Permet une analyse coût-bénéfice directe des investissements en contrôles
• Réduit la subjectivité lorsque des données fiables sont disponibles

Inconvénients :

• Nécessite des données historiques et des estimations actuarielles que de nombreuses entreprises SaaS ne possèdent pas
• Chronophage à développer et à maintenir
• Fausse précision — les chiffres peuvent créer une illusion d’exactitude alors que les hypothèses sous-jacentes sont des estimations approximatives

Idéale pour : Les organisations matures disposant de fonctions de gestion des risques dédiées, les entreprises avec un historique d’incidents étendu, les grandes entreprises où les rapports au conseil d’administration exigent une quantification financière des risques.

Approche hybride

De nombreuses organisations utilisent l’évaluation qualitative comme méthodologie principale et la complètent par une analyse quantitative pour les risques les plus prioritaires ou pour des décisions d’investissement spécifiques. C’est une approche pragmatique qui satisfait la norme tout en fournissant un contexte financier là où il est le plus pertinent.

Exemple : Une entreprise SaaS utilise une matrice qualitative 5x5 pour son évaluation annuelle des risques mais effectue une analyse quantitative lorsqu’elle évalue s’il faut investir 200 000 $ dans une nouvelle solution WAF plutôt que d’accepter le risque d’attaques au niveau applicatif.

Évaluation basée sur les actifs vs. basée sur les scénarios

Au-delà de la distinction qualitative/quantitative, vous devez également décider de votre approche d’identification.

L’évaluation basée sur les actifs commence par un inventaire des actifs informationnels (bases de données, serveurs, applications, stockages de données) et identifie les menaces et vulnérabilités pour chaque actif. C’est une approche rigoureuse mais qui peut être laborieuse pour les organisations ayant des inventaires d’actifs étendus.

L’évaluation basée sur les scénarios part de scénarios de menaces (par exemple, « un rançongiciel chiffre les bases de données de production », « un ordinateur portable de développeur est volé avec des identifiants en cache ») et trace l’impact sur les actifs concernés. C’est souvent plus efficace pour les entreprises SaaS car elle se concentre sur des chemins d’attaque réalistes plutôt que de cataloguer exhaustivement chaque actif.

La norme autorise les deux. La plupart des entreprises SaaS bénéficient d’une approche basée sur les scénarios ancrée dans un inventaire d’actifs de haut niveau. Vous devez savoir quels actifs existent, mais votre identification des risques est organisée autour de scénarios de menaces plutôt que d’une énumération actif par actif.

Identification et classification des actifs

Quelle que soit votre méthodologie, vous devez savoir ce que vous protégez. ISO 27001 exige que les actifs informationnels dans le périmètre de l’ISMS soient identifiés et classifiés.

Catégories d’actifs informationnels

Actifs de données : Données clients (données personnelles, données métier, analyses d’utilisation), données des employés, documents financiers, propriété intellectuelle (code source, algorithmes, données d’entraînement), identifiants d’authentification, clés de chiffrement, données de configuration, journaux.

Actifs technologiques : Serveurs de production, bases de données, dépôts de code applicatif, pipelines CI/CD, systèmes de surveillance, stockage de sauvegarde, environnements de développement et de pré-production, outils SaaS utilisés en interne (fournisseurs d’identité, gestion de projet, plateformes de communication).

Actifs humains : Employés ayant accès aux systèmes sensibles, prestataires, personnel de support tiers. Les personnes sont des actifs car leurs connaissances, leur accès et leurs actions affectent directement la sécurité de l’information.

Actifs de processus : Procédures de réponse aux incidents, flux de gestion des changements, processus de sauvegarde, procédures d’intégration/départ. Ce sont des actifs car leur défaillance ou leur absence crée des risques.

Propriété des actifs

Chaque actif doit avoir un propriétaire désigné — une personne responsable de la protection de l’actif. Les propriétaires d’actifs sont chargés de s’assurer que les risques pesant sur leurs actifs sont identifiés, évalués et traités. Dans les entreprises SaaS, la propriété des actifs suit généralement la structure de l’organisation d’ingénierie : l’équipe qui construit et exploite un système possède les actifs associés.

Classification

Classifiez les actifs en fonction de la sensibilité et de la criticité de l’information qu’ils contiennent ou traitent. Un schéma simple à trois niveaux fonctionne pour la plupart des entreprises SaaS :

• Confidentiel — Données clients, identifiants, clés de chiffrement, code source. Une divulgation non autorisée causerait un préjudice significatif.
• Interne — Documents métier internes, informations non sensibles des employés, plans de projets. Une divulgation causerait un impact modéré.
• Public — Supports marketing, documentation publiée, spécifications d’API publiques. Aucun impact en cas de divulgation.

La classification détermine le niveau de protection requis et influence la notation des risques — une menace sur un actif Confidentiel a un impact plus élevé que la même menace sur un actif Public.

Analyse des menaces et des vulnérabilités

Une fois vos actifs identifiés, vous pouvez identifier systématiquement ce qui pourrait mal tourner et pourquoi.

Identification des menaces

Les menaces sont des événements ou actions potentiels qui pourraient nuire à vos actifs informationnels. Pour les entreprises SaaS, les menaces couvrent plusieurs catégories :

Cybermenaces :

• Rançongiciels et logiciels malveillants ciblant l’infrastructure de production
• Attaques par bourrage d’identifiants contre l’authentification des clients
• Compromission de la chaîne d’approvisionnement via des bibliothèques tierces ou des outils de compilation
• Attaques DDoS perturbant la disponibilité du service
• Abus d’API — extraction de données, injection, contournement de limites de débit
• Exploitation de vulnérabilités zero-day des frameworks ou du système d’exploitation
• Hameçonnage ciblant les employés ayant accès aux systèmes de production

Menaces internes :

• Exfiltration malveillante de données par des employés ou prestataires
• Erreur de configuration de ressources cloud par négligence (buckets S3 publics, groupes de sécurité ouverts)
• Shadow IT — employés utilisant des outils non autorisés qui traitent des données de l’entreprise ou des clients
• Abus de privilèges — employés accédant à des données au-delà des besoins de leur poste

Menaces environnementales et opérationnelles :

• Pannes du fournisseur cloud affectant la disponibilité
• Défaillances de centres de données (même dans le cloud, des pannes régionales surviennent)
• Épuisement de la capacité lors de pics de trafic
• Échecs de déploiement introduisant des bogues ou des régressions de sécurité

Menaces tierces :

• Violations de sécurité chez les fournisseurs SaaS traitant vos données
• Arrêt de service d’un fournisseur forçant une migration d’urgence
• Non-conformité d’un sous-traitant affectant vos obligations réglementaires

Identification des vulnérabilités

Les vulnérabilités sont des faiblesses que les menaces peuvent exploiter. Elles existent dans la technologie, les processus et les personnes :

Vulnérabilités techniques :

• Logiciels et systèmes d’exploitation non corrigés
• Configurations par défaut non sécurisées
• Absence de chiffrement des données au repos ou en transit
• Journalisation et surveillance insuffisantes
• Mécanismes d’authentification faibles (facteur unique, identifiants partagés)
• Segmentation réseau insuffisante entre locataires ou environnements

Vulnérabilités de processus :

• Absence de processus formel de gestion des changements
• Absence d’exigences de revue de code pour les déploiements en production
• Procédures de restauration de sauvegarde manquantes ou non testées
• Processus inadéquats d’évaluation de la sécurité des fournisseurs
• Absence de manuels de réponse aux incidents

Vulnérabilités humaines :

• Formation insuffisante à la sensibilisation à la sécurité
• Dépendance à des personnes clés (un seul ingénieur qui sait comment le système fonctionne)
• Vérifications d’antécédents inadéquates pour les employés ayant un accès sensible
• Mauvaise hygiène des mots de passe malgré les exigences de la politique

Association des menaces aux vulnérabilités

Le risque existe à l’intersection d’une menace et d’une vulnérabilité. Une menace sans vulnérabilité correspondante est théorique. Une vulnérabilité sans menace correspondante est une faiblesse mais pas un risque actif. Votre registre des risques doit documenter les combinaisons spécifiques menace-vulnérabilité qui produisent des risques pour vos actifs.

Exemple :

• Actif : Base de données PostgreSQL de production contenant des données clients
• Menace : Attaque par injection SQL via l’API publique
• Vulnérabilité : Validation des entrées non systématiquement mise en œuvre sur tous les points de terminaison de l’API
• Risque : Accès non autorisé aux données clients par injection SQL, entraînant une violation de données, une notification réglementaire et des dommages réputationnels

Notation de la probabilité et de l’impact

C’est là que votre évaluation des risques passe d’une liste de préoccupations à un outil de prise de décision priorisé.

Définition de votre échelle de probabilité

Utilisez des définitions descriptives que votre équipe peut appliquer de manière cohérente. Des labels vagues comme « Faible » et « Moyen » sans définitions conduisent à une notation incohérente.

Note	Label	Définition
1	Rare	Ne pourrait survenir que dans des circonstances exceptionnelles. Aucun incident connu dans des organisations similaires.
2	Improbable	Pourrait survenir mais n’est pas attendu. Des incidents isolés sont connus dans le secteur.
3	Possible	Pourrait survenir à un moment donné. Des incidents surviennent périodiquement dans des organisations similaires.
4	Probable	Se produira probablement dans la plupart des circonstances. Incidents réguliers dans le secteur.
5	Quasi certain	Devrait se produire fréquemment. Occurrence continue ou quasi continue dans le secteur.

Définition de votre échelle d’impact

L’impact doit prendre en compte plusieurs dimensions pertinentes pour votre activité SaaS :

Note	Label	Financier	Opérationnel	Réputationnel	Réglementaire
1	Négligeable	< 10 K$	Aucune interruption de service	Aucune prise de conscience externe	Aucun intérêt réglementaire
2	Mineur	10 K$ - 50 K$	Brève interruption, < 1 heure	Plaintes limitées de clients	Enquête réglementaire informelle
3	Modéré	50 K$ - 250 K$	Interruption 1-8 heures	Couverture médiatique sectorielle	Enquête formelle
4	Significatif	250 K$ - 1 M$	Panne prolongée 8-48 heures	Couverture médiatique grand public	Action coercitive, amendes
5	Sévère	> 1 M$	Panne prolongée > 48 heures	Couverture négative soutenue	Amendes majeures, remédiation obligatoire

La matrice des risques

Multipliez la probabilité par l’impact pour produire un score de risque. Une matrice 5x5 produit des scores de 1 à 25 :

	Négligeable (1)	Mineur (2)	Modéré (3)	Significatif (4)	Sévère (5)
Quasi certain (5)	5	10	15	20	25
Probable (4)	4	8	12	16	20
Possible (3)	3	6	9	12	15
Improbable (2)	2	4	6	8	10
Rare (1)	1	2	3	4	5

Tranches de notation des risques

Définissez ce que les scores signifient pour les décisions de traitement :

• Critique (20-25) : Action immédiate requise. Le risque doit être traité avant la prochaine revue de direction.
• Élevé (12-19) : Plan de traitement requis sous 30 jours. Le propriétaire du risque doit présenter des options à la direction.
• Moyen (6-11) : Plan de traitement requis sous 90 jours. Suivi dans les revues régulières des risques.
• Faible (1-5) : Accepter ou traiter sur la base d’une analyse coût-bénéfice. Revu lors de l’évaluation annuelle.

Appétit pour le risque et critères d’acceptation

L’appétit pour le risque est le volume et le type de risque que votre organisation est prête à prendre dans la poursuite de ses objectifs. Il est défini par la direction et documenté dans votre politique de gestion des risques.

Définir l’appétit pour le risque

Votre déclaration d’appétit pour le risque doit être suffisamment précise pour guider les décisions de traitement. « Nous avons un faible appétit pour le risque » est trop vague. À la place :

• « Nous n’acceptons aucun risque résiduel noté Critique ou Élevé pour les risques affectant la confidentialité des données clients. »
• « Nous acceptons un risque résiduel Moyen pour les risques de disponibilité opérationnelle lorsque le coût d’une atténuation supplémentaire dépasse trois fois la perte annuelle prévisible. »
• « Nous n’acceptons aucun risque qui entraînerait une non-conformité réglementaire avec le RGPD ou d’autres réglementations de protection des données applicables à notre base de clients. »

Acceptation formelle des risques

Lorsqu’un risque entre dans vos critères d’acceptation — ou lorsque la direction prend une décision délibérée d’accepter un risque au-dessus du seuil normal — cette décision doit être documentée :

• Description du risque et score actuel
• Justification de l’acceptation (analyse coût-bénéfice, faible risque résiduel après les contrôles existants, décision stratégique)
• Approbateur — une personne nommée avec l’autorité d’accepter le risque (généralement le RSSI, le CTO ou le président du comité des risques)
• Date de révision — quand l’acceptation sera réévaluée
• Conditions — toute condition qui invaliderait l’acceptation (par exemple, « accepté jusqu’à ce que la base de clients dépasse 1 000 locataires »)

Les auditeurs vérifieront que les décisions d’acceptation des risques sont prises par des personnes autorisées, documentées avec justification et révisées périodiquement. L’acceptation non documentée des risques est un constat de non-conformité courant.

Planification du traitement des risques

Une fois les risques évalués et comparés à vos critères d’acceptation, chaque risque au-dessus du seuil nécessite un plan de traitement. ISO 27001 définit quatre options de traitement.

Option 1 : Atténuer (Réduire)

Mettre en œuvre des contrôles pour réduire soit la probabilité, soit l’impact du risque. C’est le traitement le plus courant et crée le lien direct entre votre évaluation des risques et vos contrôles de l’Annexe A.

Exemple : Risque d’accès non autorisé aux bases de données de production (score : 16, Élevé).

• Contrôles : Mettre en œuvre l’authentification multi-facteurs pour tout accès à la production (A.8.5), appliquer le contrôle d’accès basé sur les rôles avec le principe du moindre privilège (A.5.15), activer la journalisation de l’activité de la base de données avec alertes (A.8.15), mener des revues trimestrielles des accès (A.5.18).
• Risque résiduel attendu : 6 (Moyen) — la probabilité est réduite de Probable à Improbable grâce aux contrôles d’accès ; l’impact reste inchangé.

Option 2 : Transférer (Partager)

Transférer une partie du risque à un tiers. Les mécanismes courants incluent l’assurance cyber responsabilité et les arrangements contractuels avec les fournisseurs.

Exemple : Risque de perte financière suite à une violation de données (score : 15, Élevé).

• Traitement : Souscrire une assurance cyber responsabilité couvrant les coûts de réponse à la violation, les amendes réglementaires (lorsqu’elles sont assurables) et l’interruption d’activité. Négocier des contrats fournisseurs incluant des dispositions de responsabilité pour les violations causées par la négligence du fournisseur.
• Note : Le transfert réduit l’exposition financière mais n’élimine pas le risque. Vous avez toujours besoin de contrôles de détection et de réponse.

Option 3 : Éviter (Supprimer)

Éliminer le risque en supprimant l’activité, le processus ou le système qui le crée.

Exemple : Risque d’exposition des données via une API héritée utilisant l’authentification basique (score : 12, Élevé).

• Traitement : Décommissionner l’API héritée et migrer tous les consommateurs vers l’API actuelle qui supporte OAuth 2.0 et la limitation de débit. Le risque est éliminé car le composant vulnérable n’existe plus.

Option 4 : Accepter (Conserver)

Reconnaître le risque et choisir de ne pas prendre de mesure supplémentaire. Valable lorsque le risque est dans votre appétit pour le risque ou lorsque le coût du traitement dépasse significativement l’impact potentiel.

Exemple : Risque de brève interruption de service lors des fenêtres de maintenance du fournisseur cloud (score : 4, Faible).

• Traitement : Accepter. La maintenance programmée du fournisseur cloud survient pendant les fenêtres de faible trafic et cause généralement moins de 5 minutes de performances dégradées. Le coût de la mise en œuvre d’une architecture active-active multi-régions pour éliminer ce risque est disproportionné par rapport à l’impact.

Le document de plan de traitement des risques

Votre plan de traitement des risques doit documenter pour chaque risque traité :

• Référence du risque — lien vers le registre des risques
• Option de traitement sélectionnée — atténuer, transférer, éviter ou accepter
• Actions spécifiques — ce qui sera fait
• Références aux contrôles de l’Annexe A — quels contrôles mettent en œuvre le traitement (pour l’atténuation)
• Propriétaire — qui est responsable de la mise en œuvre du traitement
• Date cible — quand le traitement sera pleinement mis en œuvre
• Ressources nécessaires — budget, personnel, outils
• Risque résiduel attendu — le niveau de risque anticipé après traitement

Ce document est un élément d’entrée obligatoire pour votre Déclaration d’applicabilité, qui associe chaque contrôle de l’Annexe A aux risques qu’il traite.

Relier les risques aux contrôles de l’Annexe A

La connexion entre l’évaluation des risques et les contrôles de l’Annexe A est ce qui donne sa cohérence à votre ISMS. Chaque contrôle que vous mettez en œuvre doit remonter à un ou plusieurs risques identifiés. Chaque risque significatif doit être traité par un ou plusieurs contrôles (ou formellement accepté).

Comment fonctionne l’association

1. Partez du plan de traitement des risques. Pour chaque risque que vous atténuez, identifiez les actions de contrôle spécifiques que vous entreprendrez.
2. Associez les actions aux contrôles de l’Annexe A. Chaque action de contrôle correspond à un ou plusieurs des 93 contrôles de l’Annexe A. Par exemple, « mettre en œuvre l’authentification multi-facteurs » correspond à A.8.5 (Authentification sécurisée).
3. Documentez l’association dans votre Déclaration d’applicabilité. Le SoA montre chaque contrôle de l’Annexe A, s’il est inclus ou exclu, et la justification par le risque de cette décision.
4. Incluez les contrôles non déterminés par l’évaluation des risques. Certains contrôles de l’Annexe A répondent à des exigences légales, réglementaires ou contractuelles plutôt qu’à des risques spécifiques. Ceux-ci sont néanmoins inclus dans le SoA avec la justification appropriée.

Associations courantes pour les entreprises SaaS

Risque	Contrôles de l’Annexe A
Accès non autorisé aux données clients	A.5.15 (Contrôle d’accès), A.5.16 (Gestion des identités), A.8.5 (Authentification sécurisée), A.8.3 (Restriction d’accès à l’information)
Attaque de la chaîne d’approvisionnement via du code tiers	A.5.19-A.5.22 (Contrôles des relations fournisseurs), A.8.25 (Cycle de développement sécurisé), A.8.28 (Codage sécurisé)
Violation de données par mauvaise configuration des ressources cloud	A.8.9 (Gestion de la configuration), A.8.8 (Gestion des vulnérabilités techniques), A.8.15 (Journalisation)
Rançongiciel perturbant les opérations	A.8.7 (Protection contre les logiciels malveillants), A.8.13 (Sauvegarde de l’information), A.5.24 (Planification de la gestion des incidents)
Départ d’une personne clé	A.5.2 (Rôles de sécurité de l’information), A.5.4 (Responsabilités de la direction), A.6.5 (Responsabilités après la cessation d’emploi)
Non-conformité au RGPD	A.5.34 (Protection de la vie privée et des données personnelles), A.5.31 (Exigences légales, statutaires et réglementaires)

Maintenance du registre des risques

Votre registre des risques n’est pas un livrable ponctuel. C’est un document vivant qui reflète votre paysage actuel de menaces, votre environnement de contrôle et votre contexte métier.

Champs obligatoires

Chaque entrée de risque doit capturer :

• Identifiant du risque — Identifiant unique (par exemple, RISK-2026-001)
• Titre du risque — Nom concis pour référence
• Description du risque — Description détaillée de la menace, de la vulnérabilité et de l’impact potentiel
• Actif(s) affecté(s) — Quels actifs informationnels sont à risque
• Source de la menace — Attaquant externe, interne, environnemental, fournisseur
• Vulnérabilité — La faiblesse que la menace exploite
• Probabilité inhérente — Score avant contrôles
• Impact inhérent — Score avant contrôles
• Score de risque inhérent — Probabilité x Impact
• Contrôles existants — Contrôles actuellement en place
• Probabilité résiduelle — Score après contrôles
• Impact résiduel — Score après contrôles
• Score de risque résiduel — Probabilité x Impact après contrôles
• Décision de traitement — Atténuer, transférer, éviter, accepter
• Référence du plan de traitement — Lien vers le plan de traitement
• Propriétaire du risque — Personne nommée responsable
• Date de révision — Dernière révision du risque
• Statut — Ouvert, en traitement, accepté, clôturé

Cadence de révision

• Continue — Mettre à jour le registre lorsque des événements significatifs surviennent (incidents de sécurité, nouvelles vulnérabilités, violations de fournisseurs, changements architecturaux, intégration de fournisseurs)
• Trimestrielle — Revue formelle des principaux risques, de l’avancement des traitements et des menaces émergentes
• Annuelle — Réévaluation complète de tous les risques dans le cadre de la revue de direction de l’ISMS
• Déclenchée — Réévaluation lors de changements significatifs (lancement de nouveau produit, fusion-acquisition, migration d’infrastructure, nouvelles réglementations)

Connexion avec l’audit interne

Votre programme d’audit interne doit vérifier que le processus d’évaluation des risques fonctionne comme documenté. Les auditeurs vérifieront :

• La méthodologie a-t-elle été suivie de manière cohérente ?
• Les nouveaux risques identifiés pendant la période ont-ils été capturés dans le registre ?
• Les plans de traitement ont-ils été mis en œuvre dans les délais ?
• Les décisions d’acceptation des risques ont-elles été dûment autorisées ?
• Le registre reflète-t-il les changements survenus pendant la période ?

Exemples de risques spécifiques au SaaS

Ces exemples illustrent comment des risques réels du SaaS sont documentés dans un registre des risques. Ce ne sont pas des modèles à copier — vos risques doivent refléter votre architecture, vos données et votre contexte métier spécifiques.

Exemple 1 : Défaillance de l’isolation des données multi-locataires

Identifiant du risque : RISK-2026-012 Description : Un défaut logiciel dans la couche d’isolation des locataires permet à un client d’accéder aux données d’un autre client. Cela pourrait résulter d’un filtre d’identifiant locataire manquant dans une requête de base de données, d’une erreur de cache servant les données d’un autre locataire, ou d’une condition de concurrence dans la gestion des sessions. Actif : Données clients, application de production Probabilité inhérente : 3 (Possible) — l’isolation des locataires est complexe ; des incidents similaires se sont produits chez des fournisseurs SaaS majeurs Impact inhérent : 5 (Sévère) — violation de données affectant plusieurs clients, notification obligatoire, dommages réputationnels sévères Score de risque inhérent : 15 (Élevé) Contrôles existants : Application de l’identifiant locataire au niveau de l’ORM, tests d’intégration pour l’isolation des locataires, exigences de revue de code pour le code d’accès aux données Probabilité résiduelle : 2 (Improbable) Impact résiduel : 5 (Sévère) — l’impact ne change pas ; seule la probabilité est réduite Score de risque résiduel : 10 (Moyen) Traitement : Atténuer — mettre en œuvre la sécurité au niveau des lignes au niveau de la base de données comme mécanisme d’isolation secondaire, ajouter des tests automatisés d’isolation des locataires au pipeline CI/CD, déployer une surveillance en temps réel des schémas d’accès inter-locataires Contrôles : A.8.25 (Cycle de développement sécurisé), A.8.28 (Codage sécurisé), A.8.29 (Tests de sécurité), A.8.16 (Activités de surveillance)

Exemple 2 : Pipeline CI/CD compromis

Identifiant du risque : RISK-2026-018 Description : Un attaquant accède au pipeline CI/CD (GitHub Actions, Jenkins ou similaire) et injecte du code malveillant dans un déploiement en production. Les vecteurs d’attaque incluent des jetons GitHub compromis, des pull requests malveillantes depuis des dépôts forkés, ou des attaques de la chaîne d’approvisionnement via des GitHub Actions compromises utilisées dans les workflows. Actif : Code source, infrastructure de production, données clients Probabilité inhérente : 3 (Possible) — les attaques de la chaîne d’approvisionnement sont en augmentation Impact inhérent : 5 (Sévère) — l’attaquant obtient l’exécution de code en production avec accès à toutes les données clients Score de risque inhérent : 15 (Élevé) Contrôles existants : Revue de code obligatoire pour toutes les PR, protection de branche sur la branche principale, analyse des secrets dans le CI Probabilité résiduelle : 2 (Improbable) Impact résiduel : 5 (Sévère) Score de risque résiduel : 10 (Moyen) Traitement : Atténuer — mettre en œuvre les commits signés, fixer toutes les GitHub Actions à des hachages SHA spécifiques, déployer la provenance de construction SLSA Niveau 2, restreindre l’accès aux runners auto-hébergés, mettre en œuvre la vérification d’intégrité des artefacts de construction Contrôles : A.8.25 (Cycle de développement sécurisé), A.8.9 (Gestion de la configuration), A.5.19 (Sécurité de l’information dans les relations fournisseurs), A.8.15 (Journalisation)

Exemple 3 : Violation d’un fournisseur SaaS tiers

Identifiant du risque : RISK-2026-024 Description : Un fournisseur SaaS qui traite ou stocke des données de l’entreprise ou des clients subit une violation de sécurité, exposant les données qui lui ont été confiées. Les fournisseurs concernés pourraient inclure des fournisseurs d’identité, des plateformes d’analyse, des outils de support client ou des processeurs de paiement. Actif : Données clients, données des employés, données métier Probabilité inhérente : 4 (Probable) — les violations de fournisseurs sont fréquentes dans le secteur Impact inhérent : 4 (Significatif) — selon le fournisseur, pourrait exposer des données personnelles de clients, nécessiter une notification de violation et causer des dommages réputationnels Score de risque inhérent : 16 (Élevé) Contrôles existants : Évaluation de la sécurité des fournisseurs lors de l’intégration, clauses contractuelles de protection des données, revue annuelle des fournisseurs Probabilité résiduelle : 3 (Possible) — impossible de contrôler entièrement la posture de sécurité du fournisseur Impact résiduel : 3 (Modéré) — impact réduit par la minimisation des données et le chiffrement Score de risque résiduel : 9 (Moyen) Traitement : Atténuer — mettre en œuvre une surveillance continue des fournisseurs, exiger une certification SOC 2 Type II ou ISO 27001 des fournisseurs critiques, minimiser les données partagées avec les fournisseurs au strict nécessaire opérationnel, chiffrer les données sensibles avant transmission aux fournisseurs, maintenir des manuels de réponse aux incidents fournisseurs Contrôles : A.5.19-A.5.22 (Contrôles de gestion des fournisseurs), A.5.31 (Exigences légales), A.8.11 (Masquage des données)

Exemple 4 : Mauvaise configuration de l’infrastructure cloud

Identifiant du risque : RISK-2026-031 Description : Une mauvaise configuration de l’infrastructure cloud (AWS, GCP, Azure) expose des ressources à l’internet public. Les exemples incluent des buckets S3 accessibles publiquement, des groupes de sécurité autorisant un accès entrant sans restriction, des instances de base de données non chiffrées avec des points de terminaison publics, ou des rôles IAM trop permissifs. Actif : Infrastructure de production, données clients, données applicatives Probabilité inhérente : 4 (Probable) — les mauvaises configurations sont la cause la plus courante d’incidents de sécurité cloud Impact inhérent : 4 (Significatif) — pourrait exposer les données clients, permettre un mouvement latéral pour les attaquants, ou permettre l’abus de ressources Score de risque inhérent : 16 (Élevé) Contrôles existants : Infrastructure-as-code avec revue par PR, règles AWS Config pour les mauvaises configurations courantes Probabilité résiduelle : 2 (Improbable) — l’IaC et les vérifications automatisées réduisent significativement la probabilité Impact résiduel : 4 (Significatif) — impact inchangé si la mauvaise configuration survient Score de risque résiduel : 8 (Moyen) Traitement : Atténuer — mettre en œuvre un outil de Cloud Security Posture Management (CSPM), imposer l’infrastructure-as-code pour tous les changements de ressources cloud (aucun changement manuel via la console), déployer des SCP AWS pour empêcher la création de ressources publiques, mener des audits trimestriels de configuration cloud Contrôles : A.8.9 (Gestion de la configuration), A.8.8 (Gestion des vulnérabilités techniques), A.8.15 (Journalisation), A.8.23 (Filtrage web)

Exemple 5 : Exfiltration de données par un interne

Identifiant du risque : RISK-2026-037 Description : Un employé ou prestataire disposant d’un accès privilégié aux systèmes de production exfiltre intentionnellement des données clients pour un gain personnel, un avantage concurrentiel ou une intention malveillante. Cela inclut les exports de base de données, l’extraction de données via API, ou la copie de données vers un stockage personnel. Actif : Données clients, propriété intellectuelle Probabilité inhérente : 2 (Improbable) — les attaques internes sont moins fréquentes que les attaques externes mais se produisent Impact inhérent : 5 (Sévère) — violation de données, obligations de notification réglementaire, responsabilité juridique, dommages réputationnels sévères Score de risque inhérent : 10 (Moyen) Contrôles existants : Contrôle d’accès basé sur les rôles, vérifications d’antécédents pour les employés ayant accès à la production, accords de confidentialité Probabilité résiduelle : 1 (Rare) — les contrôles réduisent mais ne peuvent pas éliminer le risque interne Impact résiduel : 5 (Sévère) Score de risque résiduel : 5 (Faible) Traitement : Atténuer — mettre en œuvre la surveillance de l’activité de la base de données avec alertes pour les exports massifs de données, déployer des contrôles DLP sur les postes et la messagerie, imposer l’accès juste-à-temps pour les bases de données de production, mener des revues trimestrielles des accès pour assurer le moindre privilège, journaliser et surveiller tous les accès à la production Contrôles : A.5.15 (Contrôle d’accès), A.6.1 (Vérification des antécédents), A.6.2 (Conditions d’emploi), A.8.15 (Journalisation), A.8.16 (Activités de surveillance), A.8.12 (Prévention des fuites de données)

Intégrer l’évaluation des risques au cycle de vie de l’ISMS

L’évaluation des risques n’est pas un exercice isolé. Elle est connectée à chaque autre composant de votre ISMS.

Connexion avec la Déclaration d’applicabilité

Votre plan de traitement des risques est l’entrée principale de la Déclaration d’applicabilité. Le SoA liste les 93 contrôles de l’Annexe A et indique si chacun est inclus ou exclu, avec justification. Pour les contrôles inclus, la justification remonte au(x) risque(s) que le contrôle traite. Pour les contrôles exclus, la justification explique pourquoi le risque ne s’applique pas.

Connexion avec les politiques et procédures

Vos politiques ISMS doivent référencer l’évaluation des risques comme base des exigences de contrôle. Par exemple, votre politique de contrôle d’accès n’indique pas simplement « l’authentification multi-facteurs est requise » — elle indique que le MFA est requis parce que l’évaluation des risques a identifié l’accès non autorisé comme un risque Élevé pour la confidentialité des données clients.

Connexion avec le processus de certification

Lors de votre audit de certification ISO 27001, l’auditeur examinera votre méthodologie d’évaluation des risques, votre registre des risques, votre plan de traitement et la connexion entre les risques et les contrôles. Les constats d’audit courants liés à l’évaluation des risques incluent :

• Méthodologie d’évaluation des risques non documentée ou non suivie
• Registre des risques non mis à jour pour refléter les changements pendant la période d’audit
• Plans de traitement sans preuves de mise en œuvre
• Contrôles de l’Annexe A inclus dans le SoA sans justification par le risque correspondante
• Décisions d’acceptation des risques sans approbation de la direction
• Aucune preuve de revue périodique des risques

Connexion avec le RGPD et la protection des données

Si votre entreprise SaaS traite des données personnelles soumises au RGPD, votre évaluation des risques ISO 27001 soutient — mais ne remplace pas — les Analyses d’impact relatives à la protection des données (AIPD). Les deux processus sont complémentaires : votre évaluation des risques ISMS couvre les risques de sécurité de l’information de manière large, tandis que les AIPD se concentrent spécifiquement sur les risques pour les droits et libertés des personnes concernées résultant d’activités de traitement spécifiques.

Erreurs courantes dans l’évaluation des risques ISO 27001

Traiter cela comme un exercice ponctuel. Une évaluation des risques réalisée une fois lors de la certification et oubliée jusqu’à l’audit de surveillance est un exercice de conformité, pas une pratique de sécurité. Votre paysage de menaces change en permanence. De nouvelles vulnérabilités sont découvertes, de nouveaux fournisseurs sont intégrés, l’infrastructure évolue et les techniques des attaquants progressent. Votre évaluation des risques doit suivre le rythme.

Utiliser des modèles génériques sans personnalisation. Un registre des risques qui liste « incendie dans le centre de données » pour une entreprise SaaS 100 % cloud-native ne reflète pas la réalité. Vos risques doivent être spécifiques à votre architecture, votre pile technologique, votre base de clients et votre modèle commercial. Les modèles génériques sont un point de départ pour la structure, pas pour le contenu.

Ne pas impliquer les bonnes personnes. Les ingénieurs savent où se trouve la dette technique. Les chefs de produit savent quelles fonctionnalités traitent les données les plus sensibles. Les équipes de réussite client savent quels engagements de disponibilité ont été pris. Les équipes de sécurité seules ne peuvent pas identifier tous les risques pertinents. Les ateliers transversaux produisent des registres de risques plus complets.

Tout noter en Moyen. Si chaque risque de votre registre obtient un score entre 6 et 12, vos critères de notation ne permettent pas une différenciation efficace. Revoyez vos définitions de probabilité et d’impact pour vous assurer qu’elles produisent une différenciation significative. Un registre des risques bien calibré devrait avoir des risques distribués sur l’ensemble de la plage de notation.

Déconnecter l’évaluation des risques des décisions de contrôle. Si votre registre des risques et la mise en œuvre de vos contrôles vivent dans des documents séparés sans références croisées, les auditeurs identifieront immédiatement l’écart. Chaque contrôle doit remonter à un risque. Chaque risque significatif doit remonter à un contrôle ou à une décision d’acceptation.

Ne pas documenter la méthodologie. « Nous avons fait un brainstorming sur les risques et les avons notés » n’est pas une méthodologie. Documentez vos critères de notation, votre processus d’évaluation, votre cadence de révision et les rôles impliqués. Le document de méthodologie est lui-même un artefact vérifiable.

Comment GRCTrail vous aide

GRCTrail fournit aux entreprises SaaS les outils et la structure nécessaires pour mener un processus d’évaluation des risques ISO 27001 qui satisfait les auditeurs et produit de véritables informations de sécurité.

• Flux de travail guidé d’évaluation des risques qui accompagne votre équipe à travers les exigences de la Clause 6.1.2 — de la définition de la méthodologie jusqu’à l’achèvement du registre des risques — garantissant que chaque étape répond à la norme sans nécessiter de consultant externe pour interpréter les clauses
• Bibliothèque de risques SaaS pré-remplie avec des scénarios de menaces spécifiques aux entreprises SaaS cloud-native, couvrant l’isolation multi-locataires, la sécurité du pipeline CI/CD, la mauvaise configuration cloud, les risques de la chaîne d’approvisionnement et les dépendances aux fournisseurs, afin que vous partiez de menaces pertinentes plutôt que de modèles vierges
• Association automatique des contrôles de l’Annexe A qui relie les risques identifiés aux 93 contrôles de l’Annexe A et alimente directement votre Déclaration d’applicabilité, maintenant la traçabilité de la menace au traitement jusqu’au contrôle

Démarrer avec GRCTrail →

Guides connexes

• Qu’est-ce qu’ISO 27001 ? Un guide pour les entreprises SaaS
• Exigences ISO 27001 : Comprendre les Clauses 4-10
• Contrôles de l’Annexe A ISO 27001 : Guide complet des 93 contrôles
• Déclaration d’applicabilité ISO 27001 : Comment la créer
• Guide de gestion des fournisseurs ISO 27001
• Checklist de certification ISO 27001
• Guide d’évaluation des risques SOC 2
• Guide AIPD RGPD