Blog

Voici les contrôles non applicables

Quand votre entreprise ne fait aucun développement logiciel, ces cinq contrôles ne s’appliquent pas :

A8.4 — Accès au code source, clairement si nous n’avons pas de développement, il n’y a pas de code source à gérer!

A.8.25 — Cycle de vie de développement sécurisé Si vous n’avez pas d’équipe de développement, vous n’avez pas de cycle de développement.

A.8.26 — Exigences de sécurité applicatives Ce contrôle concerne les spécifications de sécurité pour vos propres applications. Pas celles que vous achetez ou louez. Si vous ne développez rien, ce contrôle ne vous concerne pas.

A.8.27 — Architecture sécurisée et principes d’ingénierie Porte sur la conception sécurisée des systèmes que vous développez. Encore une fois, sans développement, pas d’architecture à concevoir.

A.8.28 — Codage sécurisé Le plus évident. Pas de code, pas de codage sécurisé. Certaines entreprises pensent que configurer un logiciel c’est du “codage”. Non, c’est de la configuration.

A.8.29 — Tests de sécurité dans le développement Tests de sécurité sur le code en développement. Sans développement, ce contrôle tombe à l’eau.

Les zones grises qui créent la confusion

Trois contrôles créent souvent de la confusion :

A.8.30 — Développement externalisé Celui-là, c’est plus subtil. Si vous engagez des programmeurs externes pour développer quelque chose spécifiquement pour vous, ce contrôle s’applique. Mais si vous achetez un logiciel sur une étagère, même personnalisé, ça ne compte pas comme du développement externalisé.

A.8.31 — Séparation des environnements Pas besoin d’environnement de développement si vous ne développez pas. Par contre, si vous avez un environnement de test pour vos logiciels achetés, ce contrôle pourrait s’appliquer partiellement.

A.8.33 — Informations de test Si vous ne testez jamais rien, ce contrôle ne s’applique pas. Mais attention : la plupart des entreprises font au moins des tests d’acceptation sur leurs nouveaux logiciels.

Ce qui reste applicable

Le contrôle 8.32 — Gestion des changements reste presque toujours applicable, même sans développement. Parce que vous changez des configurations, mettez à jour des logiciels, modifiez des paramètres. Ça, c’est de la gestion des changements.

Pour les autres contrôles, tel que sécurité réseau, de gestion des accès, de sauvegarde, de formation ? Ils restent applicables puisqu’avec ou sans développement, ces mesures protègent votre environnement informatique, peu importe d’où viennent vos logiciels.

Comment bien évaluer l’applicabilité

Posez-vous ces questions simples :

• Est-ce que quelqu’un dans mon entreprise écrit du code ?
• Est-ce que nous avons des programmeurs à l’interne ?
• Est-ce que nous engageons des firmes pour développer des applications spécifiquement pour nous ?
• Est-ce que nous modifions le code source de nos logiciels ?

Si toutes les réponses sont “non”, alors les contrôles A8.4, 8.25 à 8.29 ne s’appliquent pas à vous.

La justification, c’est obligatoire

Quand vous déclarez un contrôle non applicable, vous devez le justifier par écrit dans votre Déclaration d’Applicabilité. Ce n’est pas optionnel, c’est une exigence de la norme.

Une bonne justification ressemble à ça :

“L’entreprise ne développe aucun logiciel à l’interne et ne fait appel à aucun fournisseur qui fait du développement. Tous les logiciels utilisés sont des solutions commerciales acquises sur le marché.”

Attention aux changements

Votre déclaration d’applicabilité n’est pas gravée dans le béton. Si votre entreprise évolue et commence à faire du développement, vous devrez réviser cette déclaration.

J’ai vu des entreprises qui ont commencé par acheter des logiciels, puis qui ont engagé des programmeurs pour les personnaliser. Du jour au lendemain, certains contrôles sont redevenus applicables.

Ce qu’est le OWASP Top 10

Le OWASP Top 10 est une liste des dix vulnérabilités de sécurité web les plus courantes, destiné à sensibiliser les développeurs et les organisations aux risques les plus prioritaires à corriger ou surveiller.

Voici les 10 plus grands risques associés à une application web pour la version 2021. (une nouvelle version devrait être publiée en 2025.)

• A01 — Contrôles d’accès défaillants
• A02 — Cryptographie et protection des données inadéquates
• A03 — Injection
• A04 — Conception non sécurisée
• A05 — Vulnérabilités de sécurité liées aux composants
• A06 — Mauvaises configurations de sécurité
• A07 — Identification et authentification faibles
• A08 — Gestion des erreurs et journalisations insuffisantes
• A09 — Contrôle d’intégrité des données
• A10 — Sécurité côté client

Son but est sensibilisé et aider la formation des gens sur les risques des applications Web.

Ce qu’est l’OWASP ASVS

L’Application Security Verification Standard (ASVS) fournit une liste détaillée d’exigences techniques pour concevoir, développer et vérifier la sécurité des applications et services web.

Vous pouvez libre mon billet d’introduction ici: https://medium.com/@btk667/owasp-asvs-cest-quoi-9ffd3cb06ad9

C’est un cadre structuré, pensé pour des tests et une intégration dans le SDLC. La version stable actuelle est ASVS 5.0.0.

Chaque exigence est identifiable et formulée de façon vérifiable — pratique pour l’acceptation lors des revues de code, les tests ou un audit externe.

ASVS est organisé par chapitres couvrant tous les aspects de développement web. Autant l’architecture, la conception, authentification et gestion des identifiants, sessions, contrôle d’accès, validation/encodage, cryptographie, journalisation et gestion des erreurs, protection des données, communications, intégrité du code, logique d’affaires, fichiers/ressources, API et configuration.

L’organisation OWASP offre même des Cheat Sheet pour mieux comprendre et gérer les contrôles dans les opérations courantes.

Cheat Sheet OWASP

Quand utiliser l’un ou l’autre

Le Top 10 c’est pour démarrer ou débuter dans la construction d’une culture sécurité en formant les équipes de développeurs, créer des listes de vérification et obtenir des victoires rapides à court terme.

Mais si on veut construire plus sérieusement et surtout valider notre travail de manière méthodique, il faut intégrer l’ASVS au SDLC, on commence par le premier niveau, puis on progresse à mesure que notre maturité augmente. Notre maturité augmente en même temps que la qualité de nos outils, de nos procédures et que ceux-ci sont répétable rapidement.

Effort et coûts

Top 10
Faible coût pour formation, liste, corrections ciblées.

Impact rapide sur l’hygiène de base, mais attention : couverture partielle des risques et peu de traçabilité fine.

ASVS
Investissement plus important avec des sélection d’exigences, adaptation au SDLC, ajout de tests (automatisés et manuels), collecte de preuves.

Impact réduction du risque résiduel et meilleure démonstration de conformité pour vos clients et fournisseurs.

Pourquoi OWASP ASVS

OWASP ASVS donne un langage commun et une liste claire pour sécuriser les applications. Pour une PME, c’est un moyen simple d’éviter les angles morts, d’aligner l’équipe et de prouver que la sécurité est prise au sérieux.

Standardiser ce qui compte.
ASVS propose un ensemble cohérent d’exigences applicables à tous tes projets.

Couvrir l’ensemble des contrôles.
De l’authentification à la gestion des sessions, de la validation des données à la cryptographie, ASVS incluent tout. En le suivant, on réduit les risques classiques (injection SQL, XSS contrôle d’accès défaillant) qui causent la majorité des incidents.

Faciliter les tests de sécurité.
ASVS fournit des critères de vérification concrets pour les tests manuels et automatisés. Ces critères peuvent être intégrés aux processus d’assurance qualité ou dans l’intégration continue.

Hausser la maturité des développeurs.
Les directives rendent la sécurité plus tangible pour l’équipe. On comprend pourquoi un contrôle est exigé et comment l’implanter correctement.

Améliorer la posture de sécurité.
Avec le standard ASVS, les écarts sont identifiés plus rapidement et traités avant qu’ils deviennent des vulnérabilités critiques.

Soutenir la conformité réglementaire.
ASVS aide à démontrer que des contrôles adaptés sont en place, ce qui facilite la conformité. Montrer aux clients et aux auditeurs que la sécurité applicative est gérée de façon structurée.

Réduire les coûts.
Corriger pendant le développement coûte beaucoup moins cher qu’en urgence après un incident. En prévenant les brèches, on évite aussi les amendes, frais légaux et pertes d’affaires.

Gagner la confiance des utilisateurs.
Des applications plus sûres, c’est moins de failles de sécurité. Dans un marché compétitif, cette confiance devient un avantage clair.

Comment fonctionnent les niveaux : L1, L2, L3

L’ASVS propose trois niveaux de priorité croissante pour les 345 items.

• L1 (Niveau 1) : 70 contrôles (sécurité de base, couvrant les risques connus et facilement testable, destinée aux applications à faible risque).
• L2 (Niveau 2) : 183 contrôles (protection avancée dédiée aux applications manipulant des données sensibles).
• L3 (Niveau 3) : 92 contrôles (sécurité maximale requise pour les applications critiques, comme celles de santé ou financières).

L’ASVS n’impose pas un niveau particulier. C’est votre analyse de risque, la sensibilité de l’application et les attentes de vos utilisateurs qui doivent guider le choix.

Les « décisions de sécurité documentées », c’est quoi ?

Les « décisions de sécurité documentées », c’est tout ce que l’organisation choisie en termes de sécurité et fonctions doit être écrit.

L’ASVS 5.0 demande que les choix soient rédigés, partagés et traçables.

Lors de l’audit, on vérifie que ces décisions existent et sont réalisables, puis que le code, les configurations et les processus appliquent exactement ce qui a été décidé.

Exemple: Le champ prénom doit être de moins de 50 lettres. Lorsqu’on valide en intégration, les chiffres doivent être refusés et plus de 50 lettres également.

Ce que contient l’ASVS

Le standard, c’est 345 exigences réparties dans 17 chapitres, chacun découpé en sections thématiques:

Cette structure permet de choisir ce qui est pertinent selon le contexte ; par exemple, une API machine à-machine ignorera les exigences de “V3-frontend web”.

L’ASVS emploie volontairement le mot « exigence » : il énonce ce qui doit être vrai (« must »), pas des « should » facultatifs. L’idée est de viser des objectifs de sécurité clairs, simples à comprendre et non liés à une technologie précise et cela rend indépendant le mode de vérification.

Autres informations

• Selon ISO, plus d’un million d’entreprises dans le monde sont certifiées ISO 9001. C’est la norme la plus utilisée pour démontrer un cadre structuré de gestion.
• J’ai trouvé une étude de la Harvard Business School (2015) qui a démontré que les organisations certifiées ISO 9001 ont un taux de survie plus élevé et une performance financière supérieure de 9 % en moyenne.
• Pour nous au Québec, Il y a Innovation Québec et certains appels d’offres publics exigent une certification qualité, comme ISO 9001.

Nouvelle version de la norme à venir (Oct. 2025)

Une nouvelle version d’ISO 9001 est en cours d’élaboration et apportera des changements :

• Technologies émergentes : Ajout d’enjeux sur l’intégration de l’intelligence artificielle et de l’automatisation dans les processus qualité.
• Éthique et intégrité : une place dans la section leadership, avec des attentes explicites en matière de transparence et d’intégrité organisationnelle.
• Risques vs opportunités : distinction plus claire dans la gestion documentaire et opérationnelle, afin d’éviter les confusions et de renforcer la maîtrise des deux volets.
• Durabilité et ESG : introduction d’objectifs de durabilité, avec une emphase pour l’impact environnemental et social, ainsi que la satisfaction client et la prise en compte des parties prenantes.
• Évolution du titre : la norme mettra en avant des « lignes directrices pour l’utilisation », avec une volonté explicite de fournir un accompagnement pratique plutôt que seulement des exigences.

Bref, la norme ISO 9001 n’est pas un luxe. C’est un levier pour augmenter la crédibilité et assurer la survie pour toute PME qui veut croître et conserver la confiance de ses clients.

Deming l’exprimait : « Sans données, vous n’êtes qu’une autre personne avec une opinion. »

Autrement dit, documenter les processus et apprendre de nos erreurs, c’est bâtir la confiance. À l’inverse, sans données ni rigueur, c’est répéter les mêmes problèmes encore et encore.

La question est la même, allez-vous prendre en main la qualité de vos produits?

Historique

• 2014 (1re édition) : première publication du « code de bonnes pratiques » pour les processeurs de RP infonuagique.
• 2019 (2e édition) : révision mineure pour corriger et clarifier la 1re édition.
• 2025 (3e édition) : Mise à niveau pour s’aligner sur la nouvelle norme ISO/IEC 27002:2022 avec nouvelles familles de contrôles, attributs, etc.

Les nouveautés de 2025

La nouvelle norme s’aligne sur la version ISO27002:2022 : les contrôles sont réorganisés par thèmes (organisation, personnes, physique, technologique). Exemples:

• Veille de menaces (5.7) et préparation à la continuité des TIC (5.30);
• Gestion de la configuration (8.9), suppression de l’information (8.10), masquage des données (8.11), prévention des fuites (8.12);
• Surveillance des activités (8.16), filtrage web (8.23), codage sécurisé (8.28).

Nouveaux controles “infonuagique public et RP” : ISO/IEC 27018 ajoute, pour plusieurs contrôles, un guide de mise en œuvre spécifique aux service infonuagique public et rajoute de l’information à l’annexe A lorsque des attentes spécifiques aux RP s’appliquent. Par exemple :

• Gestion des identités (5.16) : offrir au client les moyens de créer et retirer les accès de ses utilisateurs;
• Journalisation (8.15) : définir qui peut voir quoi, limiter l’accès aux journaux contenant des RP, prévoir des périodes de rétention et une suppression automatique;
• Cryptographie (8.24) : décrire les services de gestion des clés (KMS), les modules matériels de sécurité (HSM) et l’option « apportez votre propre clé » (BYOK) disponibles, ainsi que les choix de gestion des clés;
• Sauvegardes (8.13) : clarifier qui (vous ou votre client) est responsable des copies, de la restauration, des tests et où se trouvent les répliques.

Une nouvelle annexe B, c’est un tableau de correspondance 2019 → 2025 pour mettre en correspondance l’ancienne norme avec la nouvelle.

Intégration des exigences liées aux RP dès la création des services et répartition claire des responsabilités dans les contrats (client, fournisseur, sous‑traitants).

Mise à jour du contenu et des références (dont ISO/IEC 29100:2024) afin de mieux refléter les usages actuels infonuagique et les attentes en matière de confidentialité. La norme n’est pas une loi, mais elle s’aligne mieux avec le RGPD et la Loi 25.

Plus de mesure pour soutenir le client dans la collecte, la modification et le retrait du consentement, avec conservation de la preuve et prise d’effet opérationnelle (ex. arrêt immédiat d’un envoi courriel après retrait).

Augmentation des besoins de journalisation des accès, suppressions et modifications de RP, sur la justification des actions et sur la disponibilité de traces électroniques utiles aux audits et aux demandes des personnes.

Contrôles cohérents avec une approche de “confiance nulle” (Zero Trust): mise en œuvre du moindre privilège, séparation des environnements, visibilité sur les transferts et maîtrise des sous‑traitants, y compris pour les transferts transfrontaliers.

Clarification et distinction entre contrôleur (client) et processeur (fournisseur), mieux documentée et contractualisée dans toute la chaîne de sous‑traitance, avec des pistes d’audit pour démontrer les responsabilités.

Changer le vocabulaire, structure et clauses pour mieux harmonisés et faciliter les évaluations et la reconnaissance de la conformité avec normes et loi relatif à la vie privé dans le monde.

Exemples de contrôles spécifiques « 27018 »

Voici quelques exemples d’exigences de ISO27018

1) A.2.1 — Consentement et choix
Le processeur doit soutenir le client pour obtenir un consentement valable, permettre sa modification ou son retrait et conserver la preuve de ces décisions.
Donc il faut avoir un écran de consentement granulaire (par finalité), page de préférences accessible en tout temps, registre des décisions avec horodatage et identité de l’utilisateur, et mise à jour automatique des traitements (ex. cesser l’envoi de courriels marketing dès le retrait du consentement).

2) A.10.1 — Avertissement des atteintes aux RP
Tout incident doit être évalué pour déterminer s’il y a une atteinte aux RP; le client doit être avisé rapidement avec les informations nécessaires pour ses obligations légales.
Donc concrètement, l’organisation doit avoir une procédure d’incident avec critères (gravité, types de RP touchés), avis au client dans un délai défini (par exemple 24 à 72 h), registre des incidents, exemple de message qui précise cause, portée, mesures prises et actions recommandées au client.

3) A.11.8 — Identifiant unique obligatoire
Les accès doivent être attribués individuellement; les comptes partagés sont à éviter pour avoir une traçabilité.

4) A.12.1 — Localisation des RP
Le processeur documente où les RP sont traités et stockées (production, sauvegardes, relève), et tient ces informations à jour.

5) A.5.1 — Suppression des fichiers temporaires
Les fichiers temporaires contenant des RP doivent être supprimés lorsqu’ils ne sont plus nécessaires.

Rapide liste de vérification

Répondez Oui ou Non à chaque question.

1. Votre SoA reflète‑t‑il la structure 2025 (chapitres 5 à 8) et les contrôles RP pertinents ?
2. Offrez‑vous à vos clients des moyens d’exercer les droits des personnes (portail et API, délais clairement définis) ?
3. Tenez‑vous un registre des sous‑traitants à jour avec les lieux de traitement et les garanties ?
4. Vos contrats incluent‑ils des clauses RP standardisées (finalité, usage interdit, audit, notification, rétention/effacement, localisation) ?
5. La gestion des identités prévoit‑elle la délégation au client, un cycle de vie complet (création‑modification‑fin) et une validation périodique ?
6. La journalisation limite‑t‑elle l’accès par organisation, inclut‑elle des revues périodiques, des règles de rétention et de purge automatiques ?
7. Vos procédures de suppression sont‑elles testées (production et sauvegardes), avec des délais publiés et des preuves d’effacement conservées ?
8. Disposez‑vous d’un inventaire des options de service de gestion des clés (KMS), des modules matériels de sécurité (HSM) et de l’option « apportez votre propre clé » (BYOK), et la politique de gestion des clés est‑elle communiquée aux clients ?
9. Vos sauvegardes et restaurations ont‑elles des OTR/OPR définis et testés, avec des emplacements documentés ?
10. Votre processus d’incident qualifie‑t‑il une atteinte aux RP selon des critères clairs, avec des guides d’intervention pour la notification et des registres à jour ?
11. Les environnements d’essai interdisent‑ils les RP, ou utilisent‑ils des données pseudonymisées/masquées avec effacement rapide ?
12. Offrez‑vous des formations de sensibilisation RP adaptées aux rôles (conséquences, gestes interdits) ?
13. Réalisez‑vous des évaluations des facteurs de vie privée (EFVP) pour les transferts hors Québec/Canada/UE et avez‑vous des garde‑fous contractuels en place ?
14. Tenez‑vous un dossier de preuves à jour (rapports, captures, journaux) et prévoyez‑vous une revue indépendante ?

Bref, la version 2025 d’ISO/IEC 27018 ne réinvente pas le programme de protection des RP ; c’est une mise à jour des pratiques vers la norme ISO27002:2022 et rend les engagements contractuels plus clairs.

Bref, en nous basant sur la norme ISO 27001:2022 et en cherchant uniquement les exigences explicites ou très directes de la Loi 25 (principalement la Loi sur la protection des renseignements personnels dans le secteur privé, LQ c P-39.1, telle que modifiée), voici une analyse contrôle par contrôle.

Important :

• Cette analyse se concentre sur les exigences explicites. Beaucoup d’autres contrôles ISO sont des bonnes pratiques qui aident à respecter l’obligation générale de sécurité (Art. 10), mais ne sont pas explicitement demandés terme à terme par la Loi.
• L’Article 10 de la Loi sur la vie privé demande de prendre les mesures de sécurité propres à assurer la protection des renseignements personnels, en tenant compte notamment de leur sensibilité, de la finalité de leur utilisation, de leur quantité, de leur répartition et de leur support. Ceci est une obligation générale qui sous-tend la pertinence de nombreux contrôles, mais nous ne listerons “Oui” que si la Loi demande spécifiquement le type de mesure décrite par le contrôle ISO.
• Les articles cités réfèrent à la Loi sur la protection des renseignements personnels dans le secteur privé (LQ c P-39.1), sauf indication contraire.

A.5 Contrôles organisationnels

• A.5.1 Politiques pour la sécurité de l’information: Oui.
• Justification: L’Art. 3.3 exige que toute entreprise exploitant une entreprise au Québec établisse et mette en œuvre des politiques et des pratiques encadrant sa gouvernance à l’égard des renseignements personnels et visant à assurer leur protection. Ces politiques doivent notamment prévoir un cadre applicable à la conservation et à la destruction des renseignements, les rôles et responsabilités des membres du personnel, et un processus de traitement des plaintes. Une politique de sécurité est une composante essentielle de cet encadrement.
• A.5.2 Rôles et responsabilités en matière de sécurité de l’information: Oui.
• Justification: L’Art. 3.1 désigne d’office la personne ayant la plus haute autorité comme responsable de la protection des renseignements personnels (peut déléguer). L’Art. 3.3 demande que les politiques de gouvernance prévoient “les rôles et les responsabilités des membres de son personnel tout au long du cycle de vie de ces renseignements”.
• A.5.3 Séparation des tâches: Non. La Loi 25 n’exige pas explicitement ce contrôle interne spécifique.
• A.5.4 Responsabilités de la direction: Oui (implicitement).
• Justification: L’existence d’un responsable désigné (Art. 3.1) et l’obligation d’établir des politiques de gouvernance (Art. 3.3) impliquent une responsabilité de la direction dans la supervision et l’approbation de ces mesures.
• A.5.5 Contact avec les autorités: Oui.
• Justification: L’Art. 21.0.1 exige la notification rapide à la Commission d’accès à l’information (autorité de contrôle) de tout incident de confidentialité présentant un risque de préjudice sérieux.
• A.5.6 Contact avec des groupes d’intérêt spécifiques: Non. La Loi 25 n’exige pas explicitement ce type de contact.
• A.5.7 Renseignement sur les menaces: Non. Utile pour l’Art. 10, mais pas explicitement exigé.
• A.5.8 Sécurité de l’information dans la gestion de projet: Oui (via les EFVP).
• Justification: L’Art. 3.2 exige la réalisation d’une Évaluation des Facteurs relatifs à la Vie Privée (EFVP) pour “tout projet d’acquisition, de développement et de refonte de système d’information ou de prestation électronique de services impliquant des renseignements personnels”.1 Une EFVP doit considérer les mesures de sécurité.
• A.5.9 Inventaire des informations et autres actifs associés: Non. La Loi 25 se concentre sur les renseignements personnels. Savoir où ils se trouvent est nécessaire pour se conformer, mais un inventaire complet de tous les actifs au sens ISO n’est pas explicitement exigé.
• A.5.10 Utilisation acceptable des informations et autres actifs associés: Non. Implicite dans les politiques (Art. 3.3) et la sécurité (Art. 10), mais pas formulé comme une exigence explicite de ce type de politique.
• A.5.11 Restitution des actifs: Non. Procédure interne non spécifiée par la Loi.
• A.5.12 Classification de l’information: Non. La Loi parle de “sensibilité” (Art. 10) mais n’impose pas de système de classification formel.
• A.5.13 Étiquetage de l’information: Non.
• A.5.14 Transfert d’informations: Oui (pour les Renseignements Personnels).
• Justification: L’Art. 17 encadre spécifiquement la communication de renseignements personnels à l’extérieur du Québec (nécessite une EFVP et des garanties de protection adéquates). De plus, l’Art. 10 (sécurité) s’applique à tout transfert, et les politiques (Art. 3.3) doivent couvrir le cycle de vie, incluant les transferts/communications.
• A.5.15 Contrôle d’accès: Oui (implicitement fondamental).
• Justification: Bien que l’Art. 10 soit général, limiter l’accès aux renseignements personnels aux seules personnes autorisées est une mesure de sécurité fondamentale et implicitement requise pour assurer la protection exigée. Les politiques (Art. 3.3) devraient l’adresser.
• A.5.16 Gestion des identités: Oui (implicitement nécessaire).
• Justification: Nécessaire pour mettre en œuvre le contrôle d’accès (A.5.15), donc implicitement requis par l’Art. 10 et les politiques (Art. 3.3).
• A.5.17 Informations d’authentification: Oui (implicitement nécessaire).
• Justification: Nécessaire pour la gestion des identités (A.5.16) et le contrôle d’accès (A.5.15), donc implicitement requis par l’Art. 10 et les politiques (Art. 3.3).
• A.5.18 Droits d’accès: Oui (implicitement nécessaire).
• Justification: Nécessaire pour mettre en œuvre le contrôle d’accès (A.5.15), donc implicitement requis par l’Art. 10 et les politiques (Art. 3.3).
• A.5.19 Sécurité de l’information dans les relations avec les fournisseurs: Oui.
• Justification: L’Art. 17 (communication hors Québec, souvent via fournisseurs) exige une EFVP et des garanties. L’Art. 10 exige une sécurité appropriée, ce qui implique une diligence raisonnable lorsque des fournisseurs traitent des renseignements personnels. L’Art. 3.2 (EFVP) peut aussi s’appliquer si un fournisseur est impliqué dans un projet visé.
• A.5.20 Traitement de la sécurité de l’information dans les accords avec les fournisseurs: Oui.
• Justification: Nécessaire pour formaliser les garanties requises par l’Art. 17 et assurer le respect de l’Art. 10 lorsque des fournisseurs sont impliqués.
• A.5.21 Gestion de la sécurité de l’information dans la chaîne d’approvisionnement des TIC: Oui.
• Justification: Variante de A.5.19/A.5.20, particulièrement pertinente pour les services infonuagiques ou autres maillons de la chaîne TIC traitant des renseignements personnels, en lien avec Art. 10, Art. 17, Art. 3.2.
• A.5.22 Surveillance, révision et gestion des changements des services fournisseurs: Oui.
• Justification: Suivi nécessaire pour s’assurer que les obligations contractuelles (A.5.20) et légales (Art. 10, Art. 17) sont respectées dans la durée.
• A.5.23 Sécurité de l’information pour l’utilisation des services Cloud: Oui.
• Justification: Cas spécifique de gestion des fournisseurs (A.5.19 à A.5.22) critique pour le respect de l’Art. 10, l’Art. 17 et potentiellement l’Art. 3.2 (EFVP).
• A.5.24 Planification et préparation de la gestion des incidents de sécurité de l’information: Oui.
• Justification: Soutient directement les exigences de gestion des “incidents de confidentialité” des Art. 21.0.1 (notification) et 21.0.2 (registre).
• A.5.25 Évaluation et décision concernant les événements de sécurité de l’information: Oui.
• Justification: Étape nécessaire pour déterminer s’il y a un “incident de confidentialité” et s’il présente un “risque de préjudice sérieux” (Art. 21.0.1).
• A.5.26 Réponse aux incidents de sécurité de l’information: Oui.
• Justification: L’action principale requise suite à un incident, incluant les mesures pour diminuer les risques (implicite dans Art. 21.0.1) et la tenue du registre (Art. 21.0.2).
• A.5.27 Tirer les leçons des incidents de sécurité de l’information: Non. Bonne pratique, mais pas une exigence explicite de la Loi 25.
• A.5.28 Collecte d’éléments de preuve: Non. Peut être nécessaire pour l’enquête (A.5.26), mais pas une exigence légale explicite en soi.
• A.5.29 Sécurité de l’information pendant les perturbations: Non. La continuité des activités n’est pas explicitement exigée par la Loi 25 (sauf si l’indisponibilité cause un préjudice relevant de l’Art. 10 ou d’un incident).
• A.5.30 Préparation des TIC pour la continuité d’activité: Non. Voir A.5.29.
• A.5.31 Exigences légales, statutaires, réglementaires et contractuelles: Oui.
• Justification: La Loi 25 est une exigence légale et réglementaire qui doit être identifiée et respectée. Les politiques (Art. 3.3) doivent refléter la conformité.
• A.5.32 Droits de propriété intellectuelle: Non. Non pertinent pour la protection des renseignements personnels.
• A.5.33 Protection des enregistrements: Oui.
• Justification: Les renseignements personnels constituent des enregistrements qui doivent être protégés (Art. 10) et gérés pour leur conservation et destruction (Art. 11, Art. 3.3).
• A.5.34 Confidentialité et protection des informations personnelles identifiables (PII): Oui.
• Justification: C’est l’objet même de la Loi 25. L’Art. 10 exige leur protection, l’Art. 3.3 exige des politiques de gouvernance, etc.
• A.5.35 Revue indépendante de la sécurité de l’information: Non. Non exigé explicitement par la Loi 25.
• A.5.36 Conformité aux politiques et normes: Oui (implicitement).
• Justification: L’obligation de mettre en œuvre des politiques (Art. 3.3) implique une vérification de la conformité à celles-ci.
• A.5.37 Procédures d’exploitation documentées: Non. Bonne pratique, mais pas explicitement exigé par la Loi 25.

A.6 Contrôles relatifs aux personnes

• A.6.1 Vérification des antécédents: Non. Non exigé par la Loi 25.
• A.6.2 Termes et conditions d’emploi: Non. Ne relève pas de la Loi 25, bien que des clauses de confidentialité soient une bonne pratique (supporte Art. 10).
• A.6.3 Sensibilisation, éducation et formation à la sécurité de l’information: Oui.
• Justification: L’Art. 3.3 exige que les politiques de gouvernance prévoient “les mesures de formation et de sensibilisation que [l’entreprise] offre aux membres de son personnel” concernant la protection des renseignements personnels.
• A.6.4 Processus disciplinaire: Non. Relève des RH internes.
• A.6.5 Responsabilités après la fin ou la modification de l’emploi: Non. Procédure interne.
• A.6.6 Accords de confidentialité ou de non-divulgation: Non. Pas explicitement exigé, mais bonne pratique (supporte Art. 10).
• A.6.7 Travail à distance: Non. La Loi exige la sécurité indépendamment du lieu (Art. 10), mais ne prescrit pas de politique spécifique pour le télétravail (ceci devrait être couvert par les politiques générales sous Art. 3.3 si applicable).
• A.6.8 Signalement des événements de sécurité de l’information: Oui.
• Justification: Mécanisme nécessaire pour que le personnel puisse signaler les incidents, permettant ainsi à l’entreprise de respecter ses obligations sous Art. 21.0.1 et 21.0.2. Fait partie de la formation/sensibilisation (Art. 3.3).

A.7 Contrôles physiques

• A.7.1 Périmètres de sécurité physique: Oui (implicitement fondamental).
• Justification: L’Art. 10 exige des mesures appropriées. La protection physique des lieux où sont stockés/traités des renseignements personnels est implicitement requise.
• A.7.2 Contrôles d’accès physique: Oui (implicitement fondamental).
• Justification: Nécessaire pour A.7.1. Lié à l’Art. 10.
• A.7.3 Sécurisation des bureaux, salles et installations: Oui (implicitement fondamental).
• Justification: Nécessaire pour A.7.1/A.7.2. Lié à l’Art. 10.
• A.7.4 Surveillance de la sécurité physique: Non. Méthode spécifique non exigée par la Loi 25.
• A.7.5 Protection contre les menaces physiques et environnementales: Oui (implicitement).
• Justification: Assurer la disponibilité/intégrité des renseignements personnels relève des “mesures appropriées” de l’Art. 10.
• A.7.6 Travail dans des zones sécurisées: Oui (implicitement).
• Justification: Lié à A.7.1-A.7.3 et Art. 10.
• A.7.7 Bureau propre et écran propre: Non. Pratique spécifique non exigée.
• A.7.8 Emplacement et protection des équipements: Oui (implicitement).
• Justification: Mesure de protection physique nécessaire sous Art. 10.
• A.7.9 Sécurité des actifs hors des locaux: Oui (implicitement).
• Justification: L’Art. 10 s’applique peu importe le lieu. Pertinent pour le télétravail, appareils mobiles.
• A.7.10 Supports de stockage: Oui.
• Justification: L’Art. 10 exige un stockage sécurisé. L’Art. 11 exige la destruction/anonymisation sécurisée (pertinent pour l’élimination des supports).
• A.7.11 Utilités: Non. Non mentionné explicitement.
• A.7.12 Sécurité du câblage: Non. Détail technique non mentionné.
• A.7.13 Maintenance des équipements: Non. Procédure interne (mais une maintenance non sécurisée pourrait violer Art. 10).
• A.7.14 Mise au rebut ou réutilisation sécurisée des équipements: Oui.
• Justification: Directement lié à l’Art. 11 (destruction/anonymisation) lorsque l’équipement contient des renseignements personnels. Également Art. 10.

A.8 Contrôles technologiques

• A.8.1 Terminaux utilisateurs: Oui (implicitement).
• Justification: Doivent être sécurisés conformément à l’Art. 10 s’ils traitent/stockent des renseignements personnels. Les politiques (Art. 3.3) devraient couvrir cela.
• A.8.2 Droits d’accès privilégiés: Oui (implicitement essentiel).
• Justification: Aspect essentiel du contrôle d’accès (A.5.15, A.5.18) nécessaire pour se conformer à l’Art. 10.
• A.8.3 Restriction de l’accès à l’information: Oui (implicitement essentiel).
• Justification: Cœur du contrôle d’accès (A.5.15, A.5.18) requis par l’Art. 10.
• A.8.4 Accès au code source: Non. Contrôle technique spécifique non exigé.
• A.8.5 Authentification sécurisée: Oui (implicitement essentiel).
• Justification: Partie essentielle de la gestion des identités/accès (A.5.16, A.5.17) requise par l’Art. 10.
• A.8.6 Gestion de la capacité: Non. Non exigé explicitement.
• A.8.7 Protection contre les logiciels malveillants: Oui (implicitement fondamental).
• Justification: Mesure de sécurité de base requise sous l’Art. 10.
• A.8.8 Gestion des vulnérabilités techniques: Oui (implicitement).
• Justification: Partie nécessaire du maintien de la sécurité requis par l’Art. 10.
• A.8.9 Gestion de la configuration: Oui (partiellement/implicitement).
• Justification: Configurations nécessaires pour appliquer la sécurité (Art. 10), particulièrement pertinent pour l’Art. 3.4 (Confidentialité par défaut).
• A.8.10 Suppression d’informations: Oui.
• Justification: Directement requis par l’Art. 11 (destruction lorsque la finalité est accomplie).
• A.8.11 Masquage des données: Oui (comme méthode d’anonymisation/sécurité).
• Justification: L’anonymisation est une option à la destruction sous Art. 11. Le masquage/pseudonymisation peut être une mesure de sécurité sous Art. 10 ou une mesure de mitigation dans une EFVP (Art. 3.2).
• A.8.12 Prévention des fuites de données: Oui (implicitement).
• Justification: Des mesures pour prévenir la communication ou l’accès non autorisé sont requises sous Art. 10.
• A.8.13 Sauvegarde des informations: Oui (implicitement).
• Justification: Nécessaire pour assurer l’intégrité et la disponibilité, considérées comme faisant partie des “mesures appropriées” sous Art. 10.
• A.8.14 Redondance des installations de traitement de l’information: Non. Mesure spécifique de continuité non exigée.
• A.8.15 Journalisation: Oui (implicitement).
• Justification: Nécessaire pour la surveillance, la détection/investigation des incidents (A.5.24-A.5.26, Art. 21.0.1/21.0.2), et potentiellement pour démontrer la conformité (Art. 10).
• A.8.16 Surveillance des activités: Oui (implicitement).
• Justification: Nécessaire pour détecter les incidents (Art. 21.0.1/21.0.2) et s’assurer de l’efficacité des contrôles (Art. 10).
• A.8.17 Synchronisation des horloges: Non. Détail technique supportant la journalisation, mais non exigé explicitement.
• A.8.18 Utilisation de programmes utilitaires privilégiés: Non. Contrôle technique spécifique lié à A.8.2.
• A.8.19 Installation de logiciels sur les systèmes opérationnels: Non. Pratique de gestion des changements non exigée explicitement.
• A.8.20 Sécurité des réseaux: Oui (implicitement fondamental).
• Justification: Mesure de sécurité de base requise sous l’Art. 10.
• A.8.21 Sécurité des services réseau: Oui (implicitement).
• Justification: Requis pour A.8.20. Lié à l’Art. 10.
• A.8.22 Ségrégation des réseaux: Non. Choix d’architecture spécifique non exigé.
• A.8.23 Filtrage Web: Non. Outil spécifique non exigé.
• A.8.24 Utilisation de la cryptographie: Oui (contextuellement/implicitement).
• Justification: L’Art. 10 exige des mesures appropriées tenant compte de la sensibilité. Le chiffrement est souvent une mesure clé jugée appropriée pour les renseignements personnels sensibles (stockage/transit). Une EFVP (Art. 3.2) pourrait aussi l’identifier comme nécessaire.
• A.8.25 Cycle de vie du développement sécurisé: Oui (partiellement/via EFVP & PbD).
• Justification: L’Art. 3.2 (EFVP) exige l’évaluation des impacts sur la vie privée des systèmes. L’Art. 3.4 (Confidentialité par conception/défaut) implique que les pratiques de développement sécurisé intègrent la confidentialité dès le départ.
• A.8.26 Exigences de sécurité des applications: Oui.
• Justification: Lié à A.8.25, Art. 3.2, Art. 3.4, et Art. 10. La sécurité doit être intégrée aux applications traitant des renseignements personnels.
• A.8.27 Architecture et ingénierie des systèmes sécurisés: Oui.
• Justification: Lié à A.8.25, A.8.26, Art. 3.2, Art. 3.4, Art. 10.
• A.8.28 Codage sécurisé: Oui.
• Justification: Lié à A.8.25-A.8.27. Essentiel pour la sécurité applicative (Art. 10) et la Confidentialité par Conception (Art. 3.4).
• A.8.29 Tests de sécurité dans le développement et l’acceptation: Oui.
• Justification: Lié à A.8.25-A.8.28. Nécessaire pour vérifier l’efficacité des mesures (Art. 10, Art. 3.4).
• A.8.30 Développement externalisé: Oui.
• Justification: Le développement par des fournisseurs nécessite une supervision similaire à A.5.19-A.5.22, assurant la conformité avec Art. 10, Art. 3.4, potentiellement Art. 17 et Art. 3.2.
• A.8.31 Séparation des environnements de développement, de test et de production: Non. Bonne pratique, non exigée explicitement.
• A.8.32 Gestion des changements: Non. Contrôle de processus non exigé explicitement (mais des changements non contrôlés pourraient violer Art. 10).
• A.8.33 Informations de test: Non. L’utilisation de renseignements personnels en test serait soumise à l’Art. 10 et aux règles de consentement, mais le contrôle sur les données de test n’est pas spécifiquement exigé.
• A.8.34 Protection des systèmes d’information lors des tests d’audit: Non.

Comme prévu, la liste des “Oui” basés sur des exigences explicites est limitée, mais elle touche des domaines important: gouvernance (politiques, rôles), gestion des incidents, gestion des fournisseurs/transferts, formation, destruction/anonymisation, EFVP et confidentialité par conception. De nombreux autres contrôles, notamment techniques et physiques, sont fortement impliqués par l’obligation générale de sécurité de l’Article 10, mais ne sont pas explicitement nommés dans la loi.

Quelques pièges

Croire que les backups suffisent

Un backup sans test, sans processus de restauration, sans redondance réseau ni accès physique alternatif = aucune garantie.

Un plan TI uniquement

Le plan de continuité TI touche les finances, les RH, le service à la clientèle. Tous sont impliqué.

Copier-coller un plan générique

La norme insiste sur l’adaptation au contexte de l’organisation (taille, secteur, menaces spécifiques). Copier un plan de banque pour une PME, c’est inutile.

Ignorer les fournisseurs

Si vous êtes dépendants d’un hébergeur, d’un fournisseur SaaS ou d’un service infonuagique, votre plan doit intégrer leur propre plan. Exigez des engagements contractuels (SLA).

Après lecture de la nouvelle version 2025 de la norme ISO/IEC 27031, je crois que c’est une avancée importante.

Elle est beaucoup plus claire et je la sens plus proche de la réalité qu’elle ne l’as été. Bref, c’est le temps de cesser de croire que la continuité se résume à « on a un backup quelque part ».

Un vrai plan de continuité, c’est un gage de résilience, de crédibilité et de survie. Et maintenant, vous avez une norme claire pour vous guider.

Lien avec la norme ISO/IEC 27001:2022

Plusieurs références ont lieux à l’analyse des causes racines dans la norme ISO27001:2022.

• Clause 6.1.2 — Analyse et appréciation des risques pour bien comprendre les scénarios de menaces
• Clause 9.1 — demande la collecte de données fiables et l’analyse des causes racines transforme ces données en renseignements utilisable pour l’avenir.
• Clause 10.2 — La clause principale de gestion des non conformité et création d’action corrective demande que chaque NC soit évalué pour connaitre les cause et donc d’empêcher une répétition.

The 5 Whys (Les cinq pourquoi)

La méthode des 5 Pourquoi consiste à poser la question « Pourquoi ? » de façon répétée pour remonter des symptômes d’un problème jusqu’à sa cause fondamentale.

En trouvant cette cause racine, on peut appliquer une action corrective qui élimine durablement le problème plutôt que d’en masquer les effets.

Sa rapidité et sa simplicité en font un outil privilégié dans les environnements certifiés ISO, parce-qu’elle est simple et efficace.

Elle a des limites face à des incidents complexes lorsque plusieurs causes indépendantes interagissent.

Comment faire une analyse des 5 pourquoi

1 — Formule clairement le problème et écris‑le. 
2 — Demande : « Pourquoi ce problème survient‑il ? » et note la réponse.
3 — Transforme cette réponse en un nouveau problème, puis demande encore : « Pourquoi cela arrive‑t‑il ? » et écris la nouvelle réponse.
4 — Répète la question « Pourquoi ? » jusqu’à ce qu’aucune explication plus profonde ne soit possible ; c’est alors que la cause racine est découverte. 
5 — Si plusieurs causes apparaissent en cours de route, conserve‑les : un même problème peut avoir plusieurs causes premières.

Fishbone Diagram (diagramme d’Ishikawa)

Le diagramme d’Ishikawa représente visuellement l’effet (« arête centrale ») et ses causes potentielles regroupées par catégories (Matériel, Méthodes, Main‑d’œuvre, Milieu, Mesures, etc.).

Il est recommandé lorsqu’un incident résulte d’interactions multiples — typiquement une défaillance de processus ou une erreur humaine couplée à un contrôle technique défaillant.

Sa force réside dans la stimulation de la réflexion collective, utile lors d’ateliers impliquant plusieurs parties prenantes. Sa limite est qu’il cartographie des hypothèses ; une étape de validation est nécessaire pour confirmer la cause première.

On l’utilise surtout quand un problème a plusieurs causes potentielles et qu’on veut structurer la réflexion collective.

Comment crée le diagramme d’Ishikawa

1. Définir le problème ou l’effet à analyser. Par exemple : comprendre pourquoi une série de pompes livrées à un client présente fréquemment des défauts.
2. Tracer l’ossature du diagramme. Dessinez au centre de la page une flèche horizontale orientée vers la droite ; elle représente l’arête dorsale du poisson. À l’extrémité de la flèche, comme la tête du poisson, inscrivez l’énoncé du problème (p. ex. : défauts fréquents des pompes) et encadrez‐le.
3. Identifier les grandes catégories de causes. À partir de l’arête centrale, dessinez des branches obliques qui feront office de côtes. Ishikawa proposait les « 6 M », mais il encourageait l’adaptation des intitulés pour mieux parler aux équipes :

Matériel : pièces, ingrédients, fournitures.

Machinerie : équipements de production, dispositifs de manutention, logiciels (dans certains secteurs, cette catégorie peut être scindée).

Méthodes : procédures, techniques, processus, règlements (notamment pour l’administration publique ou les industries très réglementées).

Mesures : indicateurs clés, instruments de mesure, points de collecte des données.

Main‑d’œuvre : personnes, ressources humaines, formations, compétences.

Milieu (Mother Nature) : environnement et facteurs externes.

On ajoute parfois un septième « M » : Money, c’est‑à‑dire les charges d’exploitation et les investissements.

4.Explorer les causes possibles. En vous appuyant sur ces catégories, demandez : « Pourquoi cela se produit‑il ? » et notez chaque cause plausible sous la branche adéquate, en restant concis. Une même cause peut figurer à plusieurs endroits si elle concerne plusieurs catégories.

5. Approfondir par itérations. Reprenez chaque cause et reposez la question « Pourquoi ? » afin d’atteindre des niveaux plus profonds ; tracez les sous‑causes comme des branches secondaires. L’empilement des branches reflète les relations de causalité.

6. Compléter le brainstorming. Lorsque les idées se tarissent, concentrez‑vous sur les branches où les causes sont moins nombreuses ; cela peut révéler des facteurs négligés.

7. Analyser et hiérarchiser. Examinez l’ensemble des causes recensées pour déterminer lesquelles méritent une action. Gardez à l’esprit que l’objectif est de traiter la cause racine, non les symptômes. Il peut être utile de redessiner le diagramme pour clarifier la présentation avant l’analyse finale.

Fault Tree Analysis (Analyse par l’arbre de défaillances)

L’FTA construit un arbre logique où l’événement indésirable est la racine et les causes sont déployées à l’aide de portes logiques AND/OR.

Cette démarche analytique convient aux événements techniques critiques, tels qu’une indisponibilité majeure d’un service de sécurité.

Elle exige cependant des compétences statistiques et peut devenir lourde pour les petites structures.

Comment crée le FTA (Analyse par arbre de défaillances)

1. Identifiez clairement le problème principal à analyser et définissez ses limites.
2. Recueillez toutes les informations pertinentes sur le système et consultez les experts concernés.
3. Construisez l’arbre en reliant les causes de base au problème principal à l’aide de portes logiques.
4. Analysez les chemins dans l’arbre pour comprendre les relations entre les causes et le problème.
5. Repérez les événements et les chemins critiques qui influencent le plus la probabilité du problème.
6. Développez des stratégies pour atténuer les risques en agissant sur les causes critiques.
7. Documentez l’analyse complète et partagez‑la avec les parties prenantes.
8. Surveillez l’efficacité des mesures mises en place et mettez régulièrement à jour l’arbre.

Causal Factor Tree Analysis (Analyse en arbre des facteurs causals)

La CFTA détaille chaque événement contributeur et ses facteurs de causalité dans un arbre chronologique.

L’approche peut être très longue et nécessite des informations précises sur la chronologie des faits.

Comment crée une analyse en arbre des facteurs causals.

1. Définir le problème: Écris clairement ce qui s’est passé (l’incident ou le problème principal).
2. Chercher des informations: Rassemble les informations sur ce qui s’est passé, comment fonctionne le système et valide avec les personnes concernées.
3. Dessiner l’arbre: Note les événements qui ont mené au problème et relie-les comme un arbre, avec des flèches pour montrer le lien.
4. Analyser les liens: Regarde comment les événements sont connectés et comprends leur enchaînement.
5. Repérer les points importants: Trouve les causes qui ont eu le plus d’impact.
6. Chercher des solutions: Note les idées pour éviter que ça recommence.
7. Suivre et améliorer: Vérifie plus tard si les solutions fonctionnent et mets à jour l’arbre si besoin.

Change Analysis (Analyse des changements)

Cette méthode compare l’état normal d’un système à l’état au moment de l’incident afin de mettre en évidence les modifications ayant pu introduire la non‑conformité.

Elle est particulièrement pertinente pour les environnements agiles ou fortement virtualisés où les mises à jour sont fréquentes.

Sa force est de cibler rapidement un changement mal maîtrisé, aligné avec l’esprit de la clause Gestion des changements (ISO 27002–5.33), même si elle dépend d’un registre de configuration fiable.

Comment faire une anayse des changements

1. Définir le système: Identifie clairement ce qui est analysé (processus, équipement, configuration, etc.).
2. Décrire l’état avant: Note comment le système fonctionnait avant le changement.
3. Décrire l’état après: Note ce qui a été modifié ou ajouté.
4. Comparer les deux états: Repère les différences entre avant et après.
5. Identifier les impacts: Cherche ce que ces différences ont causé (problèmes, erreurs, améliorations).
6. Évaluer: Demande pourquoi ces impacts sont apparus et comment les gérer.
7. Documenter l’analyse: Écris un résumé des observations et conclusions.
8. Proposer des actions: Suggère des ajustements ou des corrections si nécessaire.

Barrier Analysis (Analyse des barrières)

L’analyse des barrières examine les contrôles existants — physiques, techniques, organisationnels — et détermine lesquels ont échoué ou manqué.

Elle s’appuie aussi sur le modèle du fromage suisse, en évaluant pourquoi plusieurs couches de protection n’ont pas suffi et pourquoi une barrière censée stopper l’incident, comme un mur de béton protégeant des cyclistes, n’a pas fonctionné comme prévu.

La méthode est recommandée lorsque l’incident met en lumière une défense en profondeur insuffisante.

Elle peut également être utilisée pour comprendre ce qui empêche les individus de changer ou d’adopter un nouveau comportement.

Comment faire une analyse des barrières

1. Identifier l’incident ou le risque : définissez clairement ce que vous voulez protéger, éviter ou changer.
2. Lister les barrières existantes : notez tous les contrôles ou protections en place (techniques, humaines, organisationnelles).
3. Vérifier l’efficacité des barrières : évaluez si elles fonctionnent bien et s’il y a des failles.
4. Identifier les défaillances ou manques : cherchez ce qui a échoué ou ce qui manque comme barrière.
5. Proposer des améliorations : suggérez des moyens pour renforcer ou ajouter des barrières.
6. Documenter l’analyse : rédigez un résumé clair des résultats et des actions recommandées.
7. Suivre les actions correctives : vérifiez que les améliorations sont mises en place et qu’elles sont efficaces.

Risk Tree (Arbre de risques)

Le Risk Tree ressemble à l’FTA mais applique une logique orientée risque plutôt que défaillance pure.

Il est utilisé pour cartographier la combinaison d’événements menant à un risque inacceptable.

Dans un SGSI, il éclaire l’interaction entre menaces, vulnérabilités et impacts, contribuant à prioriser les actions correctives.

Sa complexité croît rapidement avec le nombre de facteurs de risque et peut dépasser les capacités d’analyse de petites équipes.

Comment faire l’arbre des risques

1. Définir clairement le risque ou l’événement que vous souhaitez analyser.
2. Identifier toutes les causes possibles qui peuvent mener à ce risque.
3. Décomposer chaque cause en sous-causes pour mieux comprendre les origines du risque.
4. Identifier les conséquences possibles si le risque se produit.
5. Rechercher les contrôles ou barrières déjà en place pour réduire ou maîtriser le risque.
6. Représenter le tout sous forme d’arbre, en reliant causes, sous-causes, conséquences et contrôles.
7. Analyser l’arbre pour repérer les zones critiques et décider des actions préventives ou correctives.

Parent Analysis

La Parent Analysis regroupe les incidents selon des catégories parentes communes (processus, technologie, comportement) afin d’identifier des tendances structurelles.

Elle s’emploie lorsque plusieurs incidents similaires surviennent au fil du temps.

Ses forces résident dans la vision macro qu’elle offre aux CISO, utile pour orienter des plans d’amélioration continus, mais sa faiblesse est qu’elle fournit une vue brève et peux caché des items spécificités d’un incident particulier.

Comment faire une “Parent analysis”

1. Collecte des incidents
   Rassembler tous les incidents de sécurité sur une période donnée, en veillant à inclure suffisamment de données pour détecter des motifs récurrents.
2. Catégorisation des incidents
   Classer chaque incident dans une catégorie parente selon un critère commun : Processus (ex. : défaillance dans une procédure) Technologie (ex. : vulnérabilité dans un système ou un logiciel) Comportement (ex. : erreur humaine, phishing réussi)
   Cette étape est cruciale pour structurer l’analyse et identifier les causes profondes.
3. Regroupement des incidents similaires
   Regrouper les incidents qui partagent la même catégorie parente afin de mettre en lumière des tendances ou des points faibles récurrents.
4. Analyse des tendances structurelles
   Examiner les groupes d’incidents pour comprendre les causes sous-jacentes communes, telles que des failles dans un processus, des lacunes technologiques ou des comportements à risque.
5. Synthèse macro pour les décideurs
   Présenter une vision globale des tendances, ce qui permet d’orienter les plans d’amélioration continue et les stratégies de mitigation.

Failure Mode and Effects Analysis (Analyse des modes de défaillance et de leurs effets, AMDE)

L’AMDE répertorie chaque composant d’un processus ou d’un actif, décrit ses modes de défaillance possibles et en évalue l’effet, la gravité, la probabilité et la détectabilité.

Elle convient aux environnements où la sécurité dépend d’équipements critiques ou de processus répétitifs.

Source: https://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis

Comment faire l’analyse des mode de défaillances

• Identifier le processus, le produit ou le système que vous souhaitez analyser.
• Lister les étapes du processus ou les composants du produit.
• Déterminer les modes de défaillance possibles (comment cela peut échouer).
• Identifier les effets de chaque défaillance (ce qui peut arriver si cela échoue).
• Évaluer la gravité de chaque effet (de faible à critique).
• Identifier les causes possibles de chaque défaillance.
• Évaluer la probabilité d’occurrence de chaque cause.
• Vérifier si des contrôles ou des détections existent déjà, et évaluer leur efficacité.
• Calculer le « score de priorité de risque » (RPN) en multipliant gravité × occurrence × détection.
• Prioriser les actions correctives à mettre en place selon les scores les plus élevés.
• Documenter l’analyse et suivre les améliorations mises en œuvre.

Management Oversight and Risk Tree (MORT)

Le MORT est une méthode d’analyse de causes profondes développée pour enquêter sur des événements majeurs, comme des accidents industriels, des défaillances opérationnelles ou des incidents de sécurité. Il est différent des autres:

• Il ne se contente pas d’analyser les défaillances techniques ou humaines.
• Il explore les failles dans le management, la supervision, la prise de décision et les systèmes organisationnels qui ont permis l’incident.

Il cherche à répondre à ces deux questions:

1. Qu’est-ce qui a mal fonctionné au niveau technique et opérationnel ?
2. Qu’est-ce qui a permis que ces défaillances ne soient ni prévues, ni détectées, ni corrigées ?

l’approche MORT repose sur deux piliers :

• Un arbre logique et structuré reliant tous les niveaux de causes.
• Un modèle d’évaluation de la direction qui identifie les problèmes systémiques et non seulement les symptômes visibles.

Comment faire une analyse MORT simplement

1. Définir l’événement ou l’incident à analyser
   Soyez précis : nature, date, lieu, impact.

2. Collecter les données
Rassemblez les rapports, interviews, enregistrements, procédures, logs… et créez une image complète.

3. Construire l’arbre MORT — Placez l’incident principal en haut, Branchez les causes immédiates (ex. : panne, erreur humaine, défaut matériel) et Développez vers le bas les causes profondes (ex. : absence de formation, contrôle qualité défaillant, décisions managériales, mauvaise communication).

4. Explorer deux grands axes
Échecs des contrôles: Pourquoi les dispositifs prévus n’ont pas fonctionné.
Faiblesses de gestion: Pourquoi l’organisation a échoué à prévenir ou corriger ces problèmes.

5. Utiliser les codes de priorisation (dans l’approche complète)
 Comme vu dans le MORT classique, utilisez des codes visuels pour distinguer : Ce qui est maîtrisé — Ce qui est incertain — Ce qui représente une faiblesse critique.

6. Identifier les conditions latentes
Priorités contradictoires, Objectifs flous, Manque de leadership, Culture de la performance au détriment de la sécurité.

7. Formuler des recommandations correctives robustes

Pour corriger les défaillances techniques, Renforcer la supervision, les processus, la culture et les politiques et mettre en place des indicateurs pour surveiller les changements.

Conclusion

Le choix de la méthode d’analyse de cause racine doit refléter la gravité et la complexité de l’incident, la maturité du SGSI et les ressources disponibles.

Une situation simple devrait utiliser la méthode des cinq pourquoi.

À l’inverse, un incident complexe ou récurrent pourra justifier l’emploi d’approches arborescentes comme l’FTA, la CFTA ou le MORT, afin de dévoiler les interdépendances techniques et organisationnelles.

Quel que soit l’outil retenu, l’intégration de la RCA dans le cycle PDCA renforce l’amélioration continue, assure la pérennité des actions correctives prévues à la clause 10.2 et à la fin consolide la robustesse du SGSI face aux menaces actuelles et futures.