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.