Réponse rapide

Le volet Sécurité de la TGV compte 104 critères répartis en 16 sous-domaines numérotés S01 à S16. C’est le volet le plus volumineux du référentiel : il représente 40,9 % des 254 critères totaux.

Cet article :

1. décrit chacun des 16 sous-domaines avec son libellé officiel exact, son nombre de critères et des citations littérales des critères clés (issues du fichier source liste-criteres-TGV_v2024-06-18.xls);
2. distingue clairement ce qu’exige le critère (citation officielle) et les approches typiques de mise en œuvre (recommandations);
3. fournit une cartographie détaillée de chaque sous-domaine vers les contrôles ISO 27001:2022 (Annexe A);
4. explique comment réutiliser une SoA ISO 27001:2022 pour structurer le dossier TGV;
5. signale l’anomalie de numérotation S08.19 dans le fichier officiel.

Note préalable. Cet article reproduit des citations courtes des critères TGV à des fins d’illustration analytique. Le fichier officiel reste la référence pour toute préparation effective; consultez-le directement.

Sommaire

1. Position du volet Sécurité dans la TGV
2. Pourquoi 16 sous-domaines? Une parenté ISO 27001:2013
3. Comment lire les sections par sous-domaine
4. Les 16 sous-domaines en détail
5. Cartographie détaillée S01-S16 ↔ ISO 27001:2022
6. Comment réutiliser votre SoA ISO 27001:2022 dans le dossier TGV
7. L’anomalie du critère S08.19
8. Le mécanisme d’exception MSSS
9. Quelles sont les trois erreurs structurelles à éviter en préparation TGV?
10. Glossaire
11. FAQ
12. Sources et méthodologie

1. Position du volet Sécurité dans la TGV

En bref : Le volet Sécurité de la TGV regroupe 104 critères de cybersécurité organisés en 16 sous-domaines codés S01 à S16, ce qui en fait le volet le plus volumineux du référentiel (40,9 % des 254 critères). Selon l’extraction directe du fichier officiel liste-criteres-TGV_v2024-06-18.xls du MSSS, les 5 autres volets — PRPS (75), Interopérabilité (56), Technologie (9), Performance (7) et Général (3) — couvrent les 59,1 % restants.

Le volet Sécurité est l’un des six volets de la TGV.

Volet	Code	Critères	%
Sécurité	S01-S16	104	40,9 %
PRPS	P01-P11	75	29,5 %
Interopérabilité	I01-I57	56	22,0 %
Technologie	T01-T09	9	3,5 %
Performance	PF01-PF07	7	2,8 %
Général	G01-G02 et I10	3	1,2 %
Total		254	100 %

Pour une vue comparative complète de la TGV avec les autres référentiels (Loi 25, Loi 5/LRSSS, HIPAA, SOC 2, ISO 27001:2022), consultez l’article pilier sur la certification TGV.

Contexte juridique applicable au volet Sécurité. Plusieurs critères du volet S interagissent désormais avec la Loi sur les renseignements de santé et de services sociaux (Loi 5 / LRSSS), entrée en vigueur graduellement à compter du 1er juillet 2024 (certaines dispositions s’appliquent ultérieurement). Cette loi crée un cadre juridique exclusif pour les RSSS au Québec. Trois sous-domaines du volet Sécurité y sont particulièrement reliés :

• S04.05 (rappel des obligations post-emploi) — qui inclut désormais les obligations LRSSS pour le personnel ayant manipulé des RSSS;
• S10.07 (rétention des journaux selon les lois en vigueur) — la LRSSS introduit des obligations de traçabilité supplémentaires sur les accès aux RSSS;
• S14.02 (notification d’incident) — qui se conjugue avec les obligations de notification de la LRSSS et de la Loi 25.

Les fournisseurs PST devraient consulter la communication la plus récente du MSSS et de la Commission d’accès à l’information pour le statut applicable à leur périmètre.

2. Pourquoi 16 sous-domaines? Une parenté ISO 27001:2013

En bref : La TGV organise son volet Sécurité en 16 sous-domaines parce qu’elle s’inspire de la structure de l’ISO/IEC 27001:2013 (qui regroupait ses 114 contrôles en 14 domaines dans son Annexe A). La version actuelle ISO/IEC 27001:2022 a réorganisé l’Annexe A en 4 thèmes regroupant 93 contrôles, dont 11 nouveaux. La TGV n’a pas migré vers cette nouvelle structure, ce qui impose un travail de remappage pour les organisations certifiées sur la version 2022.

L’organisation du volet Sécurité en 16 sous-domaines reflète une parenté méthodologique avec l’ISO 27001:2013 :

• L’ISO/IEC 27001:2013 organisait son Annexe A en 14 domaines (A.5 à A.18) regroupant 114 contrôles.
• L’ISO/IEC 27001:2022 a fondamentalement réorganisé l’Annexe A en 4 thèmes (A.5 Organisationnels, A.6 Personnes, A.7 Physiques, A.8 Technologiques) regroupant 93 contrôles, dont 11 nouveaux.

La TGV conserve un découpage en 16 sous-domaines plus proche de la structure 2013, tout en intégrant la substance de la version 2022 (les contrôles existent dans les deux versions, à 11 exceptions près).

Note importante. La période de transition entre ISO 27001:2013 et ISO 27001:2022 s’est terminée le 31 octobre 2025 (IAF Resolution 2021-22). Toutes les organisations certifiées ISO 27001 doivent désormais l’être sur la version 2022. Pour la TGV, ceci implique un travail de remappage entre les 16 sous-domaines TGV et la nouvelle structure 4 thèmes / 93 contrôles d’ISO 27001:2022 — voir la section 5.

Point conceptuel important : ISO 27001:2022 ≠ Annexe A

L’ISO 27001:2022 n’est pas un référentiel de contrôles. C’est un référentiel de système de management de la sécurité de l’information (SMSI) :

• les clauses 4 à 10 définissent les exigences obligatoires sur le SMSI (contexte, leadership, planification, soutien, opération, évaluation, amélioration);
• l’Annexe A est un catalogue de contrôles parmi lesquels l’organisation choisit selon son analyse de risques.

La TGV, elle, ne vérifie pas un système de management : elle vérifie qu’à un moment donné, la version X d’un PST satisfait les 254 critères. Cette différence change la nature des comparaisons faites dans cet article.

3. Comment lire les sections par sous-domaine

Pour chacun des 16 sous-domaines, vous trouverez :

1. son libellé officiel et son nombre de critères (extraits du fichier source);
2. la portée du sous-domaine en une ou deux phrases;
3. des citations littérales des critères clés (entre guillemets, en italique);
4. les approches typiques de mise en œuvre : implémentations courantes pour démontrer la conformité, distinguées clairement de la prescription officielle;
5. les erreurs fréquentes observées en pratique.

Distinction importante. Les citations littérales (en italique entre guillemets) reproduisent le texte officiel des critères. Les approches typiques sont des recommandations Factero; le Bureau de certification du MSSS n’impose pas une implémentation spécifique tant que le critère officiel est satisfait.

4. Les 16 sous-domaines en détail

S01 — Gestion des risques (3 critères)

Portée. Évaluation des risques de sécurité réalisée à la conception et maintenue tout au long du cycle de vie. C’est le sous-domaine qui ouvre le volet Sécurité — pas la politique de sécurité (qui vient en S02).

Citations.

• S01.01 : « Une évaluation des risques de sécurité a été réalisée lors de la conception de votre application et avant sa mise en production. »
• S01.02 : « Vous procédez à des évaluations périodiques des risques et vulnérabilités potentiels […]. »
• S01.03 : « L’évaluation continue des risques est approuvée par la direction […]. »

Approches typiques.

• Méthodologie d’analyse de risques documentée (souvent inspirée d’ISO/IEC 27005 ou EBIOS RM).
• Rapport d’analyse de risques initial daté et signé par la direction.
• Procédure de mise à jour de l’analyse en cas de changement majeur.
• Registre des risques résiduels acceptés.

Note d’asymétrie avec ISO 27001:2022. Les 3 critères S01 sont un sous-ensemble des exigences ISO 27001:2022 sur la gestion des risques (clauses 6.1.2, 6.1.3, 8.2, 8.3). Pour un fournisseur partant d’ISO 27001:2022, satisfaire S01 est trivial. Pour un fournisseur partant de la TGV uniquement, démontrer l’équivalence ISO 27001:2022 demanderait un effort substantiel.

Erreurs fréquentes.

• Analyse de risques faite une fois, jamais mise à jour.
• Acceptation tacite des risques résiduels par la direction sans signature formelle.
• Méthodologie absente — l’analyse existe mais on ne sait pas comment elle a été faite.

S02 — Politique de sécurité (4 critères)

Portée. Existence, approbation, diffusion et mise à jour des politiques de sécurité de l’information.

Citations.

• S02.01 : « Vous disposez de politique(s) de sécurité présentant : vos objectifs; vos principes directeurs en la matière; les rôles et responsabilités; la gestion des dérogations et des exceptions. »
• S02.03 : « Ces politiques sont approuvées par la direction, communiquées aux personnes intéressées et sont maintenues à jour. »

Approches typiques.

• Politique-cadre de sécurité signée par le plus haut dirigeant.
• Politiques sectorielles (gestion des accès, classification, télétravail).
• Procédure de révision documentée.
• Preuves de communication aux employés (intranet, courriel daté, attestation de lecture).

Erreurs fréquentes.

• Politique générique téléchargée sans adaptation au contexte du PST.
• Aucune trace de communication aux employés.
• Politiques contradictoires entre elles.

S03 — Organisation de la sécurité (6 critères)

Portée. Rôles et responsabilités, séparation des tâches incompatibles, intégration de la sécurité à la gestion de projet, risques mobiles, télétravail.

Citations.

• S03.01 : « Vous avez défini les responsabilités en matière de sécurité au sein de votre organisation. »
• S03.02 : « Votre application et les différents actifs permettant son exploitation ont un responsable attitré chargé de leur sécurité. »
• S03.03 : « Les tâches incompatibles relatives à votre application ont été identifiées et des mesures ont été prises pour en limiter son usage inapproprié. »
• S03.04 : « Vous disposez d’une méthode de gestion de projet intégrant la sécurité et permettant d’identifier les risques et de les traiter adéquatement. »
• S03.05 : « Vous gérez les risques spécifiques liés aux appareils mobiles. »
• S03.06 : « Vous disposez d’une politique permettant de couvrir les risques liés au télétravail. »

Approches typiques.

• Organigramme de la sécurité avec rôle dédié (RSSI ou équivalent).
• Description de fonction du responsable sécurité référencée dans S03.02.
• Matrice de séparation des tâches (S03.03) — qui peut faire quoi, qui ne peut pas cumuler.
• Méthode de gestion de projet avec checkpoints sécurité (S03.04) — souvent inspirée de NIST SP 800-160 ou ISO/IEC 27034.
• Politique BYOD et politique de télétravail signées (S03.05, S03.06).

Erreurs fréquentes.

• Le même développeur fait le code, les revues de sécurité et les déploiements en production.
• Aucun rôle sécurité formalisé.
• Politique télétravail rédigée pendant la pandémie sans révision depuis.

S04 — Sécurité des ressources humaines (5 critères)

Portée. Compétences, sensibilisation, formation, sanctions, obligations post-emploi. La sensibilisation et la formation ne forment pas un sous-domaine séparé — elles sont intégrées ici.

Citations.

• S04.02 : « Un programme de sensibilisation et de formation à la sécurité est en place pour tous les membres du personnel de l’entreprise (y compris la direction). »
• S04.04 : « Des sanctions appropriées sont approuvées pour les membres du personnel qui ne respectent pas les politiques et procédures de sécurité. »
• S04.05 : « À l’issue de la relation d’emploi, vous rappelez aux personnes concernées les obligations qui restent valables. »

Approches typiques.

• Programme de formation annuel obligatoire avec taux de complétion suivi.
• Liste nominative des employés formés (date pour chacun).
• Politique de sanctions disciplinaires (à articuler avec la Loi sur les normes du travail du Québec).
• Procédure de fin d’emploi avec rappel formel des obligations de confidentialité.

Erreurs fréquentes.

• Formation faite à l’embauche, jamais reprise.
• Aucune politique de sanctions documentée.
• Départ d’employés sans rappel formel.

S05 — Gestion des actifs (8 critères)

Portée. Inventaire des actifs, classification de sensibilité, conditions d’utilisation, retour des actifs en fin d’emploi, encadrement des supports amovibles, mise au rebut sécurisée. Le sous-domaine traite des actifs en tant que tels (matériels, logiciels, infrastructures); la cartographie spécifique des renseignements personnels et des RSSS relève principalement du volet PRPS — mais la classification de confidentialité (S05.05) recoupe nécessairement la sensibilité des données traitées.

Citations.

• S05.05 : « Votre application et les différents actifs permettant son exploitation sont classifiés (catégorisés) en matière de Disponibilité, d’Intégrité et de Confidentialité. »
• S05.07 : « L’utilisation des supports amovibles est encadrée conformément aux exigences découlant de la classification de l’information qui s’y trouve. »
• S05.08 : « Vous disposez d’une procédure formelle vous permettant de vous assurer d’une mise au rebut sécurisée des supports d’information […]. »

Approches typiques.

• Inventaire des actifs avec propriétaire et classification DIC.
• Politique de classification de l’information avec niveaux (public, interne, confidentiel, sensible).
• Politique d’encadrement des supports amovibles. L’interdiction par défaut des USB est une bonne pratique commune mais le critère S05.07 demande de l’encadrement, pas une interdiction stricte.
• Procédure de mise au rebut (destruction physique des disques, certificats de destruction).

Erreurs fréquentes.

• Inventaire incomplet (oubli des serveurs de développement, des SaaS shadow IT).
• Classification théorique mais jamais appliquée concrètement.
• Aucune procédure de destruction des disques en fin de vie.

S06 — Contrôle des accès (23 critères)

Portée. Sous-domaine de loin le plus volumineux du volet Sécurité (23 critères, 24 par catégorie en incluant l’anomalie S08.19 — voir section 7). Couvre la gestion complète des identités et des accès (IAM) : politique, gestion des comptes, MFA, complexité de mots de passe, journalisation, comptes à privilèges, déconnexion automatique, comptes génériques, mots de passe en dur, CAPTCHA, surveillance des attaques de type credential stuffing.

Citations clés.

• S06.06 : « Tout accès à votre application s’effectuant via le réseau public (Internet) doit se faire par le biais d’une authentification multifacteurs. »
• S06.07 : « Votre application fournit un mécanisme d’authentification utilisant des protocoles natifs sécurisés et modernes (par exemple : LDAPS). Elle permet l’utilisation de fédérations d’identités modernes (par exemple : SAML ou OpenID). »
• S06.11 : « Votre application et les systèmes permettant son fonctionnement ne comportent aucun mot de passe dans des scripts automatisés, des macros, le code source ou toute autre utilisation pouvant rendre complexes les mises à jour des mots de passe. Dans le cas contraire, une demande d’exception doit être effectuée auprès du MSSS. »
• S06.16 : « Votre application permet de désactiver un identifiant automatiquement après un maximum de cinq tentatives de connexion échouées. »
• S06.18 : « Votre application n’utilise aucun compte générique. À défaut, une demande d’exception doit être demandée auprès du MSSS. »
• S06.21 : « L’authentification aux services externes critiques de votre PST est protégée par un dispositif CAPTCHA. »
• S06.23 : « L’infrastructure qui héberge votre PST permet la surveillance et la détection d’attaques de type bourrage de justificatifs (credential stuffing) ou par dictionnaire […]. »

Approches typiques.

• Politique IAM complète couvrant MFA, complexité de mots de passe, cycle de vie des comptes.
• Configuration MFA. Approches modernes recommandées : TOTP au minimum, FIDO2/passkeys préférés (NIST SP 800-63B déconseille l’authentification SMS pour les usages sensibles).
• Registre des comptes privilégiés avec justification.
• Captures de configuration : verrouillage à 5 tentatives (S06.16), déconnexion après inactivité (S08.19/S06.19).
• Preuve de revue périodique des accès.
• Pour S06.23 : description du dispositif de détection (rate limiting, géolocalisation, behavior analytics, bot management type Cloudflare Turnstile, hCaptcha). Le critère ne nomme pas une technologie spécifique.

Notes sur le mécanisme d’exception. S06.11 et S06.18 mentionnent explicitement la possibilité d’une demande d’exception au MSSS lorsque le critère ne peut être strictement satisfait. Voir la section 8.

Erreurs fréquentes.

• MFA pour les utilisateurs réguliers mais pas pour les comptes administrateurs.
• Comptes génériques partagés (admin@, support@) sans demande d’exception.
• Mots de passe en dur dans le code (Git, scripts CI/CD).
• Aucun mécanisme de détection des attaques de force brute.
• Revue d’accès « annuelle théorique » jamais réellement effectuée.

S07 — Cryptographie (3 critères)

Portée. Chiffrement des données sensibles, chiffrement et authentification des communications inter-composantes, gestion des clés.

Citations.

• S07.01 : « L’ensemble des données sensibles dont les renseignements personnels et les renseignements personnels de santé font l’objet d’un chiffrement (lors de leur entreposage et de leurs communications). »
• S07.02 : « Toutes les communications entre les composantes de votre application sont chiffrées et font l’objet d’une authentification de part et d’autre. »
• S07.03 : « La gestion des clés utilisées par votre application et ses composantes fait l’objet d’une documentation formelle, et ce, tout au long de leur cycle de vie. »

Approches typiques.

• Politique cryptographique précisant les algorithmes acceptés. Recommandations courantes (cf. NIST SP 800-52 Rev. 2 sur TLS, NIST SP 800-131A sur les transitions cryptographiques) : TLS 1.3 préféré, TLS 1.2 acceptable (TLS 1.0/1.1 désactivés), AES-256 pour le chiffrement symétrique, SHA-256 minimum pour les fonctions de hachage.
• Pour S07.02 — « authentification de part et d’autre » : plusieurs implémentations acceptables, dont mTLS (TLS mutuel), signatures HMAC, JWT mutuels, IPsec en mode mutuel. Le critère ne nomme pas une méthode précise.
• Pour S07.03 — gestion des clés : HSM (Hardware Security Module) ou KMS managé (AWS KMS, Azure Key Vault, GCP KMS) avec FIPS 140-3 préféré (FIPS 140-2 acceptable pour les modules certifiés avant la transition NIST de 2022; aucun nouveau module ne peut désormais être validé sous FIPS 140-2).
• Inventaire des certificats avec dates d’expiration.
• Preuve de configuration TLS sur les endpoints (rapport SSL Labs, qualys).

Erreurs fréquentes.

• TLS 1.0 ou 1.1 encore acceptés sur certains endpoints (souvent endpoints de gestion).
• Certificats expirés ou auto-signés en production.
• Clés stockées dans le code source ou dans des variables d’environnement non chiffrées.
• Communications inter-microservices en clair sur le réseau interne (S07.02 ignoré).

S08 — Sécurité physique et environnementale (4 critères)

Portée. Protection physique des locaux d’hébergement et de développement, entretien du matériel, politique de bureau propre.

Note sur l’anomalie S08.19. Le fichier officiel contient un critère codé S08.19 qui porte sur la déconnexion automatique de session après inactivité. Ce critère est en réalité catégorisé « Contrôle des accès » et appartient probablement au sous-domaine S06 (notre interprétation, fondée sur la catégorie et la position séquentielle entre S06.18 et S06.20; non confirmée par communication officielle MSSS). Voir la section 7.

Citations.

• S08.01 : « Les locaux où sont hébergées les différentes composantes permettant à votre application de fonctionner font l’objet d’un contrôle d’accès et de mesures de protection physiques appropriées. »
• S08.03 : « Vous vous assurez que le matériel hébergeant votre application fait l’objet d’un entretien approprié permettant de garantir sa disponibilité et son intégrité. »
• S08.04 : « Vous avez adopté une politique du bureau propre et de l’écran vide applicable au personnel impliqué dans le développement et le soutien de votre application. »
• S08.19 (numéroté ainsi dans le fichier mais catégorisé « Contrôle des accès ») : « Votre application dispose d’une fonction permettant la déconnexion automatique d’une session après un délai d’inactivité (configurable). »

Approches typiques.

• Si hébergement on-premise : description des contrôles physiques (badge, caméras, registre des visiteurs, climatisation, détection incendie).
• Si hébergement cloud : attestations SOC 2 / ISO 27001 du fournisseur (Microsoft, AWS, Google) avec sections pertinentes surlignées et contrat de service-cadre.
• Politique de bureau propre signée par le personnel.

Erreurs fréquentes.

• Pour un cloud SaaS : aucune attestation du fournisseur fournie.
• Bureaux à aire ouverte sans politique de bureau propre.
• Aucune politique applicable aux développeurs en télétravail.

S09 — Sécurité liée à l’exploitation (12 critères)

Portée. Deuxième sous-domaine le plus volumineux du volet S avec 12 critères. Procédures d’exploitation documentées, guides, sauvegardes (avec exigence anti-rançongiciel), gestion des changements, gestion des vulnérabilités et correctifs, technologies récentes prises en charge, absence de portes dérobées, protection antimalware avec EDR.

Citations clés.

• S09.04 : « L’infrastructure permettant à votre application de fonctionner ainsi que ses données (lorsqu’hébergées sous votre responsabilité) bénéficient d’un système de sauvegarde à l’abri des rançongiciels. »
• S09.09 : « Vous appliquez dans les meilleurs délais les correctifs de sécurité de toute composante de votre application et de son environnement […]. »
• S09.10 : « L’ensemble des composantes de votre application et de son environnement est documenté et s’appuie sur des technologies récentes prises en charge par leur fournisseur respectif. »
• S09.11 : « Votre application est exempte de porte dérobée permettant une connexion à l’insu de l’acquéreur et de l’utilisateur. »
• S09.12 : « L’ensemble des systèmes permettant à votre application de fonctionner dispose d’une solution de protection antivirus récente avec fonction d’EDR. »

Approches typiques.

• Pour S09.04 — « à l’abri des rançongiciels » : plusieurs approches acceptables, dont sauvegardes immuables (S3 Object Lock, Azure Immutable Blob Storage, write-once read-many), sauvegardes hors-ligne (air-gapped), sauvegardes chez un tiers logiquement séparé. Le critère ne prescrit pas une approche spécifique.
• Pour S09.09 — « dans les meilleurs délais » : des cibles SLA basées sur la criticité CVSS sont une approche courante (cf. NIST SP 800-40 Rev. 4 sur la gestion des correctifs et CIS Controls v8 Safeguard 7.1) — par exemple : CVSS critique ≥ 9,0 en 7 jours ouvrables; élevé 7,0-8,9 en 30 jours; moyen en 90 jours. Le critère TGV ne fixe pas de délai chiffré.
• Pour S09.12 — EDR : solution EDR/XDR distincte de l’antivirus classique (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint Plan 2, etc.) avec console centralisée. Le critère exige « une fonction d’EDR », ce qui exclut un antivirus de base.
• Procédure de gestion des changements avec workflow d’approbation.
• Politique et procédure de sauvegarde avec preuves de restauration testée.

Erreurs fréquentes.

• Antivirus installé sans console de gestion centralisée; aucune visibilité sur les agents en panne.
• EDR confondu avec antivirus classique.
• Sauvegardes effectuées mais jamais testées en restauration.
• Sauvegardes accessibles depuis le réseau de production (compromission rançongiciel = compromission des sauvegardes).
• Composantes en fin de support en production (Windows Server 2012, anciennes versions de bibliothèques tierces).

S10 — Journalisation et surveillance (7 critères)

Portée. Collecte des journaux d’activité, exploitation, alertes, détection d’intrusion, rôle d’auditeur, protection des journaux, rétention selon les lois en vigueur.

Citations.

• S10.01 : « Toute activité effectuée avec votre application (incluant l’activité d’un pilote ou d’un administrateur) doit pouvoir être journalisée de manière à pouvoir identifier l’acteur (personne ou système), les circonstances, le moment, la nature de cette activité et les informations concernées. »
• S10.04 : « Votre application et son environnement sous votre responsabilité (incluant vos fournisseurs) bénéficient de systèmes de détection d’intrusion. »
• S10.07 : « L’information journalisée […] doit pouvoir être conservée selon le calendrier établi en fonction des lois, normes et règlements en vigueur. »

Approches typiques.

• Politique de journalisation précisant les sources collectées.
• Description du SIEM ou de la plateforme de centralisation (Splunk, Microsoft Sentinel, Elastic, Datadog).
• Configuration des règles de détection (corrélations, seuils, alertes prioritaires).
• Politique de rétention par type de journal, avec mécanisme de protection contre l’altération (write-once storage, hashing chaîné, transfert temps réel hors du serveur d’origine).
• Tableau des durées de rétention exigées par la loi (LSSSS, Loi 25, exigences sectorielles RSSS).

Erreurs fréquentes.

• Journaux conservés sur le serveur d’origine.
• Journaux applicatifs absents (seulement OS et réseau collectés).
• Aucune surveillance hors heures de bureau.
• Rétention insuffisante par rapport aux exigences sectorielles santé.

S11 — Sécurité des communications (5 critères)

Portée. Sécurité des communications inter-composantes (incluant soutien à distance), cloisonnement des environnements, sécurité du courriel, sensibilisation à l’hameçonnage, formation cybersécurité continue.

Citations.

• S11.01 : « Toutes les communications entre les composantes de votre application et les composantes avec qui elle interagit comportent des mécanismes permettant d’assurer la sécurité des informations qui y transitent (incluant le cas échéant les mécanismes de soutien à distance). »
• S11.02 : « L’environnement d’exécution de votre application est cloisonné de manière à compartimenter les éléments ne nécessitant ni des mêmes droits ni des mêmes ressources (ex. : accès public, zone serveur). »
• S11.03 : « Si votre application utilise le service de courrier électronique, il ne concerne pas d’information confidentielle à moins que des mécanismes de protection appropriés soient mis en place. »
• S11.04 : « Vous planifiez en continu des campagnes de simulation à l’hameçonnage afin de sensibiliser les intervenants (sous votre responsabilité) de l’écosystème de production de votre PST. »
• S11.05 : « Les intervenants sous votre responsabilité de l’écosystème de votre PST doivent bénéficier en continu d’un plan de formation en cybersécurité sur : les menaces numériques; la sécurité des appareils mobiles; l’hameçonnage; les virus et les rançongiciels; l’ingénierie sociale ou l’art de la manipulation. »

Approches typiques.

• Schéma de segmentation réseau (zones, DMZ, séparation Dev/Prod, microsegmentation Zero Trust si applicable).
• Configuration des pare-feu et politiques de réseau.
• Configuration de la sécurité du courriel : SPF, DKIM, DMARC (progression typique : p=none → p=quarantine → p=reject), avec MTA-STS, idéalement BIMI et TLS-RPT.
• Calendrier des simulations d’hameçonnage avec résultats anonymisés communiqués aux participants.
• Plan de formation cybersécurité avec modules réguliers couvrant les cinq thèmes listés en S11.05.

Erreurs fréquentes.

• DMARC en p=none indéfiniment.
• Aucune segmentation réseau (un seul VLAN plat où tout communique avec tout).
• Transferts de RSSS par courriel non chiffré.
• Simulations d’hameçonnage faites mais résultats jamais communiqués aux participants.

S12 — Acquisition, développement et maintenance (8 critères)

Portée. Sécurité tout au long du cycle de développement.

Citations.

• S12.01 : « Vous considérez la sécurité à chacune des étapes du développement de votre application. »
• S12.02 : « Vos environnements de développement, de test et d’exploitation sont distincts. »
• S12.04 : « Les développeurs de votre application (ainsi que les éventuels sous-traitants) respectent les principes d’ingénierie de la sécurité des systèmes. »
• S12.05 : « Vous supervisez tout développement réalisé à l’externe. »
• S12.06 : « Aucune information confidentielle de production n’est utilisée dans le cadre du développement de votre application. »
• S12.07 : « Vous disposez d’une stratégie de tests applicatifs. »
• S12.08 : « Vous considérez les vulnérabilités des composantes tierces sur lesquelles s’appuie votre application et vous faites les mises à jour en conséquence. »

Approches typiques.

• Procédure SDLC sécurisée (DevSecOps).
• Outillage de tests automatisés intégré au CI/CD : SAST (SonarQube, Checkmarx, Semgrep), DAST (OWASP ZAP, Burp Suite Pro), SCA (Snyk, Dependabot, OWASP Dependency-Check).
• Procédure de masquage ou anonymisation des données pour les environnements de test.
• Pratiques modernes de chaîne d’approvisionnement logicielle : SBOM (Software Bill of Materials) en SPDX ou CycloneDX, signature des artefacts (sigstore, SLSA).
• Procédure de revue de code avec critères sécurité explicites.

Erreurs fréquentes.

• Données de production copiées dans les environnements de test sans masquage.
• Bibliothèques open source utilisées sans aucune analyse de vulnérabilités connues (CVE).
• Tests SAST/DAST faits manuellement, jamais intégrés au pipeline.

S13 — Relation avec les fournisseurs (6 critères)

Portée. Gestion des risques fournisseurs.

Citations.

• S13.01 : « Vous avez mené toute évaluation des menaces et des risques ainsi que toute évaluation des facteurs relatifs à la vie privée nécessaires pour tout recours à un fournisseur tiers impliqué dans le développement, l’exploitation, la maintenance et l’évolution de votre application. »
• S13.04 : « Vous avez établi les processus et les procédures permettant de surveiller la conformité des fournisseurs envers ces exigences. »
• S13.06 : « Vous évaluez sur une base régulière la performance de vos fournisseurs. »

Approches typiques.

• Inventaire des sous-traitants critiques avec niveau de risque évalué.
• Clauses de sécurité types dans les contrats fournisseurs (DPA, SLA, droit d’audit, notification d’incident).
• Attestations de conformité des fournisseurs critiques (SOC 2, ISO 27001, HITRUST).
• Procédure de revue annuelle des fournisseurs avec scorecard.

Erreurs fréquentes.

• Inventaire des fournisseurs absent ou tenu de mémoire.
• Contrats sans clause de notification d’incident.

S14 — Gestion des incidents liés à la sécurité (3 critères)

Citations.

• S14.02 : « Tout incident portant sur les données des clients de votre application est porté à leur connaissance dans les meilleurs délais selon un processus établi. »
• S14.03 : engagement à collaborer avec les clients pour la prise en charge d’un incident.

Approches typiques.

• Plan de réponse aux incidents (PRI) documenté.
• Modèles de communication client (SLA de notification, contenu, canaux).
• Articulation explicite avec les obligations de notification de la Loi 25 (CAI) et du contexte sectoriel santé.
• Registre des incidents survenus.
• Exercices de simulation (tabletop ou red team).

Erreurs fréquentes.

• PRI existe en théorie mais l’équipe ne l’a jamais lu ni testé.
• Aucune simulation.
• Pas d’articulation avec les obligations Loi 25.

S15 — Continuité de l’activité (aspects sécurité) (3 critères)

Citations.

• S15.01 : « Vous disposez d’un plan de continuité de vos activités (maintenance et exploitation de votre application). »
• S15.02 : « Les infrastructures permettant l’exploitation de votre application font l’objet d’un plan de recouvrement après sinistre. »
• S15.03 : « Ce plan de reprise est testé périodiquement afin de vérifier son efficacité. »

Approches typiques.

• Analyse d’impact d’affaires (BIA) avec RTO et RPO par processus.
• Plan de continuité d’affaires (PCA) signé par la direction.
• Plan de reprise informatique (DRP) avec procédures opérationnelles détaillées.
• Calendrier d’exercices de relève. Le critère S15.03 dit « périodiquement » sans imposer une fréquence spécifique; la fréquence devrait être justifiée par l’analyse de risques.
• Documentation de l’infrastructure de redondance.

Erreurs fréquentes.

• BIA jamais validée par les responsables d’affaires.
• DRP basé sur l’hypothèse que les sauvegardes existeront — sans test réel de restauration.

S16 — Gestion de la conformité (3 critères)

Citations.

• S16.01 : « Vous disposez d’une stratégie de validation de la conformité technique […]. »
• S16.02 : « Votre application a fait l’objet d’un test d’intrusion par un prestataire indépendant et reconnu par le MSSS. »
• S16.03 : garantie sur la propriété intellectuelle du code conformément à la Loi sur les droits d’auteur.

Approches typiques.

• Stratégie de validation continue (audits internes, scans automatisés, tests de pénétration).
• Rapport de test d’intrusion avec mention de la firme et de sa reconnaissance par le MSSS. Le critère S16.02 ne fixe pas de fréquence chiffrée; le test doit être en cohérence avec le cycle de certification.
• Plan de remédiation des vulnérabilités identifiées avec dates et statuts.
• Pour S16.03 : registre des composantes logicielles avec licences explicitées (MIT, GPL, Apache, propriétaire).

Note importante. Pour les modalités précises du test d’intrusion (boîte blanche/grise/noire, périmètre, livrables), consultez le document Orientation sur les tests d’intrusion publié par le Bureau de certification du MSSS.

Délais de remédiation pentest officiellement attendus (selon le document Certification — Trousse globale de vérification (TGV) du MSSS, juin 2024) :

• « le fournisseur doit apporter les correctifs nécessaires ou mettre en place des mesures de mitigation dans un délai maximal de 15 jours ouvrables suivant la réception du rapport de test »;
• « le fournisseur doit informer le BCH de toute vulnérabilité critique dès qu’il en a été informé et il doit présenter un plan de mise en place des mesures de mitigation dans les trois jours ouvrables suivants ».

Comparaison avec ISO 27001:2022. Le standard ISO 27001:2022 ne mandate pas explicitement de test d’intrusion, mais le contrôle A.8.29 (Security testing in development and acceptance) couvre cette exigence quand l’organisation l’implémente effectivement. La majorité des organisations certifiées ISO 27001:2022 conduisent des tests d’intrusion réguliers, soit dans le cadre d’A.8.29, soit pour répondre à des exigences clients. La spécificité du critère TGV S16.02 n’est pas l’existence du test — qui est une pratique ISO courante — mais la prescription d’une firme reconnue par le MSSS assortie de délais de remédiation imposés.

Erreurs fréquentes.

• Test d’intrusion réalisé par une firme non reconnue par le MSSS — refus en vérification.
• Aucune analyse SCA des composantes tierces.

5. Cartographie détaillée S01-S16 ↔ ISO 27001:2022

En bref : Sur les 16 sous-domaines du volet Sécurité TGV, 11 sont en couverture directe avec ISO 27001:2022 (55 critères, ≈ 53 % du volet S), 4 en couverture partielle où la TGV est plus prescriptive (45 critères, ≈ 43 %), et 1 en couverture inverse où ISO 27001:2022 dépasse les exigences TGV (S01, 3 critères). Cette cartographie mesure la réutilisabilité documentaire des artefacts SoA pour le dossier TGV, pas une équivalence conceptuelle.

Voici la cartographie haut niveau des 16 sous-domaines TGV vers les contrôles de l’Annexe A d’ISO 27001:2022.

Méthodologie

Cette cartographie est construite par croisement entre :

• les libellés des 104 critères TGV extraits du fichier source;
• les 93 contrôles d’ISO 27001:2022 (Annexe A);
• les clauses 4-10 d’ISO 27001:2022 lorsque pertinentes (notamment pour S01).

Dimension mesurée : la « couverture » telle qu’utilisée dans cette cartographie désigne la réutilisabilité documentaire et de preuves — c’est-à-dire la mesure dans laquelle les artefacts produits pour satisfaire un contrôle ISO 27001:2022 (politiques, procédures, captures, journaux, registres) peuvent être réutilisés pour démontrer un critère TGV moyennant un re-formatage. Cette dimension n’est pas une équivalence conceptuelle entre les deux référentiels (qui attestent des objets différents — voir section 2), mais une mesure pratique de transfert d’investissement documentaire.

Niveaux de couverture :

• Directe : un contrôle ISO 27001:2022 satisfait substantiellement l’exigence TGV moyennant production de la preuve équivalente, sans travail technique additionnel significatif.
• Partielle : couverture conceptuelle, mais TGV est plus prescriptive et demande un travail d’adaptation documentaire ou technique pour certains critères du sous-domaine.
• Inverse : ISO 27001:2022 dépasse largement les exigences TGV. Le fournisseur ISO couvre TGV automatiquement, mais l’inverse demanderait un effort substantiel.

Tableau de cartographie

Sous-domaines en couverture directe (11 sous-domaines, 55 critères)

Les artefacts produits pour la SoA ISO 27001:2022 peuvent être réutilisés directement moyennant un re-formatage documentaire.

Sous-domaine TGV	# critères	Contrôles ISO 27001:2022 (Annexe A)	Notes
S02 Politique de sécurité	4	A.5.1 Information security policies; A.5.4 Management responsibilities; Clause 5.2 (Politique)	Mappage très direct.
S03 Organisation de la sécurité	6	A.5.2 Roles; A.5.3 Segregation of duties; A.5.8 Project management; A.6.7 Remote working; A.8.1 User end point devices	A.6.7 nouveau en 2022, parfait pour S03.06.
S04 Sécurité des RH	5	A.6.1 Screening; A.6.2 Terms; A.6.3 Awareness; A.6.4 Disciplinary; A.6.5 Post-employment; Clause 7.2 (Compétence)	Couverture quasi-totale.
S05 Gestion des actifs	8	A.5.9 Inventory; A.5.10 Acceptable use; A.5.11 Return; A.5.12 Classification; A.5.13 Labelling; A.7.10 Storage media; A.7.14 Secure disposal; A.8.10 Information deletion	A.8.10 nouveau en 2022.
S07 Cryptographie	3	A.8.24 Use of cryptography	Un seul contrôle ISO couvre les 3 critères TGV.
S08 Sécurité physique	4	A.7.1 Perimeters; A.7.2 Entry; A.7.3 Securing offices; A.7.4 Physical monitoring; A.7.5 Threats; A.7.7 Clear desk; A.7.13 Maintenance	A.7.4 nouveau en 2022.
S11 Sécurité des communications	5	A.8.20 Networks; A.8.21 Network services; A.8.22 Segregation; A.8.23 Web filtering; A.5.14 Information transfer; A.6.3 Awareness	A.8.23 nouveau en 2022.
S12 Développement	8	A.8.25 SDLC; A.8.26 App security; A.8.27 Architecture; A.8.28 Secure coding; A.8.29 Testing; A.8.30 Outsourced; A.8.31 Separation Dev/Test/Prod; A.8.33 Test info; A.5.21 ICT supply chain	A.8.28 nouveau en 2022. Très bon recouvrement.
S13 Fournisseurs	6	A.5.19 à A.5.23 (Supplier relationships)	Mappage très direct, A.5.23 (Cloud) nouveau en 2022.
S14 Incidents	3	A.5.24 Planning; A.5.25 Assessment; A.5.26 Response; A.5.27 Learning; A.5.28 Evidence	Couverture complète.
S15 Continuité	3	A.5.29 Disruption; A.5.30 ICT readiness; A.8.13 Backup; A.8.14 Redundancy	A.5.30 nouveau en 2022.

Sous-domaines en couverture partielle (4 sous-domaines, 45 critères)

ISO 27001:2022 couvre la majorité des critères de ces sous-domaines, mais quelques critères TGV sont plus prescriptifs et requièrent des compléments documentaires ou techniques.

Sous-domaine TGV	# critères	Contrôles ISO 27001:2022 (Annexe A)	Critères TGV-spécifiques
S06 Contrôle des accès	23	A.5.15 Access control; A.5.16 Identity management; A.5.17 Authentication info; A.5.18 Access rights; A.8.2 Privileged access; A.8.3 Information access restriction; A.8.4 Access to source code; A.8.5 Secure authentication	Verrouillage à 5 essais (S06.16); MFA universelle Internet (S06.06); CAPTCHA (S06.21); credential stuffing (S06.23)
S09 Sécurité de l’exploitation	12	A.5.37 Documented procedures; A.8.6 Capacity; A.8.7 Malware; A.8.8 Vulnerabilities; A.8.9 Configuration; A.8.13 Backup; A.8.19 Software installation; A.8.32 Change management	Sauvegardes anti-rançongiciels (S09.04); EDR explicite (S09.12); exemption de portes dérobées (S09.11)
S10 Journalisation	7	A.8.15 Logging; A.8.16 Monitoring; A.8.17 Clock sync; A.5.7 Threat intelligence	Durées de rétention sectorielles RSSS dépassant l’attente ISO
S16 Conformité	3	A.5.31 Legal; A.5.32 IPR; A.5.35 Independent review; A.5.36 Compliance; A.8.34 Audit testing	Test d’intrusion par firme reconnue par le MSSS (S16.02), avec délais de remédiation imposés

Sous-domaine en couverture inverse (1 sous-domaine, 3 critères)

ISO 27001:2022 dépasse largement les exigences TGV. Le fournisseur ISO couvre TGV automatiquement, mais l’inverse demanderait un effort substantiel.

Sous-domaine TGV	# critères	Contrôles ISO 27001:2022	Notes
S01 Gestion des risques	3	Clauses 6.1.2, 6.1.3, 8.2, 8.3 (SMSI)	TGV ⊂ ISO. ISO va beaucoup plus loin avec la SoA et le plan de traitement.

Synthèse de couverture

Sur les 16 sous-domaines du volet Sécurité TGV (104 critères au total) :

• 11 sous-domaines en couverture directe : S02, S03, S04, S05, S07, S08, S11, S12, S13, S14, S15. Total : 55 critères (≈ 53 % du volet S).
• 4 sous-domaines en couverture partielle : S06 (23), S09 (12), S10 (7), S16 (3). Total : 45 critères (≈ 43 % du volet S). Dans ces sous-domaines, la majorité des critères correspond directement à des contrôles Annexe A; un sous-ensemble est plus prescriptif que ce que demande ISO 27001:2022 — notamment :
• S06 : verrouillage à 5 essais (S06.16), MFA universelle pour accès Internet (S06.06), CAPTCHA obligatoire (S06.21), détection de credential stuffing (S06.23).
• S09 : sauvegardes anti-rançongiciels (S09.04), EDR explicite (S09.12), absence de portes dérobées (S09.11).
• S10 : durées de rétention sectorielles dépassant l’attente ISO.
• S16 : test d’intrusion par firme reconnue par le MSSS (S16.02).
• 1 sous-domaine en couverture inverse : S01. Total : 3 critères (≈ 3 % du volet S). ISO 27001:2022 dépasse largement les exigences TGV S01 grâce aux clauses 6.1.2, 6.1.3, 8.2 et 8.3 et à la production de la SoA.

Distribution des critères par niveau de couverture :

Niveau	Sous-domaines	Critères	% du volet S
Directe	11	55	≈ 53 %
Partielle	4	45	≈ 43 %
Inverse	1	3	≈ 3 %
Total	16	103	≈ 99 %*

* L’écart d’un critère par rapport au total de 104 vient de l’anomalie S08.19 (catégorisé en S08 par code Num mais en S06 par catégorie réelle); il bascule dans S06 « partielle » par catégorie réelle ou dans S08 « directe » par code Num.

Limites de cette cartographie. Cette analyse est conduite au niveau sous-domaine, pas critère par critère. Une cartographie exhaustive critère-par-critère (104 lignes individuelles avec leurs contrôles ISO 27001:2022 correspondants spécifiques, leurs preuves typiques et leur niveau de couverture précis) est un travail substantiel à venir et fera l’objet d’un article ou d’un livrable distinct.

Note importante sur l’hétérogénéité interne des sous-domaines « Partielle ». L’étiquette « Partielle » au niveau du sous-domaine peut donner une impression trompeuse. Au sein d’un sous-domaine partiel, la majorité des critères est en réalité directement couverte par des contrôles Annexe A ISO 27001:2022 : seul un sous-ensemble (typiquement 5 à 7 critères selon le sous-domaine) introduit des prescriptions sectorielles spécifiques au TGV. Par exemple, dans S06 (23 critères), la majorité correspond directement à A.5.15-A.5.18 et A.8.2-A.8.5 (politique IAM, gestion des identités, comptes privilégiés, etc.); seuls quelques-uns (S06.06 MFA universelle, S06.16 verrouillage à 5 essais, S06.21 CAPTCHA, S06.23 credential stuffing, S06.18 comptes génériques) sont vraiment « TGV-spécifiques ». La même hétérogénéité se retrouve dans S09, S10 et S16. Une cartographie au niveau critère ferait probablement apparaître une distribution plus favorable encore au transfert depuis ISO 27001:2022.

6. Comment réutiliser votre SoA ISO 27001:2022 dans le dossier TGV

En bref : Pour un fournisseur certifié ISO 27001:2022, la Statement of Applicability (SoA) est l’actif documentaire le plus précieux à réutiliser pour la TGV. La mécanique consiste à indexer chaque contrôle Annexe A applicable et ses preuves par les critères TGV correspondants. L’opération est principalement documentaire (re-formatage), pas technique. Les écarts résiduels concernent les exigences sectorielles santé et les contrôles ISO exclus de la SoA.

Pour un fournisseur certifié ISO 27001:2022, la Statement of Applicability (SoA) est l’actif documentaire le plus précieux pour la préparation TGV.

6.1 Qu’est-ce que la SoA?

La SoA est un document obligatoire de la certification ISO 27001:2022. Elle :

1. liste les 93 contrôles de l’Annexe A;
2. indique pour chacun s’il est applicable ou non au périmètre du SMSI;
3. justifie les exclusions;
4. référence les politiques, procédures et preuves de mise en œuvre pour les contrôles applicables;
5. indique le statut d’implémentation.

6.2 De la SoA au dossier TGV : la mécanique

L’opération principale est documentaire (pas technique). Pour chaque contrôle Annexe A applicable et implémenté dans la SoA :

1. Identifier les critères TGV correspondants en utilisant le tableau de cartographie de la section 5.
2. Réutiliser les mêmes preuves (politiques, procédures, captures, journaux) avec une nouvelle indexation par critère TGV.
3. Pour les contrôles ISO exclus de la SoA (par exemple physiques pour un éditeur SaaS pur cloud) : récupérer les attestations du fournisseur cloud (SOC 2, ISO 27001 du fournisseur) qui couvrent l’exclusion.
4. Pour les 9 % de critères TGV sans équivalent direct ISO : produire les artefacts spécifiques (exigence anti-rançongiciel, attestation de pentest par firme reconnue MSSS, cartographie RSSS, etc.).

6.3 Les pièges du re-formatage

• Format différent. La SoA produit une vue par contrôle ISO; le Bureau de certification du MSSS attend une vue par critère TGV. Un même artefact peut servir 4-5 critères TGV. Une matrice de correspondance évite de dupliquer la documentation.
• Périmètre. Le périmètre du SMSI ISO 27001:2022 (qui peut inclure plusieurs produits ou services) n’est pas nécessairement aligné avec le périmètre TGV (qui est la version X d’un PST). Les preuves doivent être pertinentes pour le PST spécifique.
• Niveau de détail. ISO 27001:2022 demande un « comment » (le contrôle est en place); la TGV demande souvent un « quoi exactement » (la configuration technique précise, le délai, la fréquence). Combler cet écart demande des artefacts complémentaires.

6.4 Estimation d’effort

Pour un SMSI ISO 27001:2022 mature et bien documenté, le re-formatage vers le format TGV demande, selon l’expérience d’accompagnement de Factero, un effort substantiel de plusieurs mois, incluant :

• la production de la matrice de correspondance critère-par-critère (1-2 semaines),
• le complément documentaire pour les écarts identifiés (variable selon le PST),
• la production des artefacts sectoriels santé (cartographie RSSS, arrimage DSQ si applicable, contrats d’hébergement).

L’effort exact dépend de facteurs nombreux (taille du SMSI, qualité documentaire de départ, complexité d’arrimage sectoriel, nombre d’environnements cloud, etc.) — un fournisseur souhaitant une estimation chiffrée devrait consulter directement plusieurs firmes vérificatrices ou consultants spécialisés.

7. L’anomalie du critère S08.19

En bref : Le fichier officiel TGV contient une anomalie de numérotation : le critère codé S08.19 (sur la déconnexion automatique de session) est en réalité catégorisé « Contrôle des accès » et appartient probablement à S06 (typo possible pour S06.19). Notre interprétation se fonde sur la catégorie et la position séquentielle entre S06.18 et S06.20; elle n’est pas confirmée par communication officielle MSSS. Le total de 104 critères au volet Sécurité reste inchangé dans les deux interprétations.

Le fichier officiel liste-criteres-TGV_v2024-06-18.xls contient une anomalie de numérotation qui mérite mention :

• Le critère codé S08.19 porte sur la « déconnexion automatique d’une session après un délai d’inactivité (configurable) ».
• Sa catégorie dans le fichier est « Contrôle des accès », et non « Sécurité physique et environnementale ».
• Sa position dans la séquence est entre les critères S06.18 et S06.20.

L’interprétation comme typo de S06.19 est notre lecture, fondée sur la catégorie « Contrôle des accès » et la position séquentielle. À notre connaissance, le MSSS n’a publié aucun correctif officiel ni communication confirmant cette interprétation. Toute correspondance officielle clarifiant ce point sera intégrée à une mise à jour de cet article.

Conséquence sur les décomptes :

• Par code Num strict tel que publié : S06 = 23 critères, S08 = 5 critères.
• Par catégorie réelle : S06 = 24 critères, S08 = 4 critères.

Le total de 104 critères au volet Sécurité reste inchangé dans les deux interprétations.

8. Le mécanisme d’exception MSSS

En bref : Plusieurs critères du volet Sécurité TGV (notamment S06.11 sur les mots de passe en dur et S06.18 sur les comptes génériques) prévoient explicitement une demande d’exception au MSSS lorsque le critère ne peut être strictement satisfait. Ce mécanisme requiert une demande explicite et une acceptation explicite — il n’est pas équivalent à la SoA d’ISO 27001:2022 qui est unilatérale et basée sur l’analyse de risques.

Plusieurs critères du volet Sécurité prévoient explicitement la possibilité d’une demande d’exception lorsque le critère ne peut être strictement satisfait pour des raisons techniques ou opérationnelles. C’est le cas notamment de :

• S06.11 : mots de passe en dur dans le code source — « Dans le cas contraire, une demande d’exception doit être effectuée auprès du MSSS. »
• S06.18 : comptes génériques — « À défaut, une demande d’exception doit être demandée auprès du MSSS. »

Ce mécanisme est important parce qu’il introduit une certaine flexibilité dans un référentiel par ailleurs prescriptif. Une exception accordée par le MSSS permet de poursuivre la certification avec une documentation de la justification et, généralement, des contrôles compensatoires.

Le mécanisme d’exception n’est pas équivalent à la SoA d’ISO 27001:2022 (qui est unilatérale et basée sur l’analyse de risques). L’exception TGV nécessite une demande explicite auprès du MSSS et une acceptation explicite.

9. Quelles sont les trois erreurs structurelles à éviter en préparation TGV?

En bref : Les trois erreurs structurelles les plus fréquentes en préparation TGV : (1) confondre l’existence d’un document signé et la démonstration d’un contrôle effectivement appliqué — le Bureau de certification cherche les preuves d’application, pas la documentation seule; (2) sous-estimer le volume de preuves opérationnelles à accumuler dans la durée (plusieurs mois minimum); (3) traiter le volet Sécurité indépendamment des volets PRPS, Technologie et Interopérabilité avec lesquels il interagit étroitement.

Erreur 1 — Confondre « avoir un document » et « démontrer un contrôle »

Le Bureau de certification du MSSS et les firmes vérificatrices ne se contentent pas de vérifier qu’un document existe. Ils cherchent la preuve d’application. Une politique signée mais que les employés ne connaissent pas (S02.03), une procédure documentée mais jamais exécutée, un PCA daté mais jamais testé (S15.03) : autant d’écarts qui se transforment en non-conformités.

Correctif : pour chaque document, prévoir au moins une preuve d’application opérationnelle (capture, journal, attestation, exercice).

Erreur 2 — Sous-estimer le volume de preuves opérationnelles

Les fournisseurs préparent souvent un dossier impressionnant de politiques et procédures, mais arrivent en vérification avec très peu de traces opérationnelles : registres d’accès, captures de configuration, journaux d’incidents, listes de présence aux formations.

Correctif : démarrer la collecte d’artefacts opérationnels plusieurs mois avant la soumission.

Erreur 3 — Traiter le volet Sécurité indépendamment des autres volets

Plusieurs critères du volet Sécurité interagissent étroitement avec PRPS, Technologie ou Interopérabilité :

• S05 (Gestion des actifs) chevauche P03.03 (Inventaire des renseignements personnels).
• S07.01 (Chiffrement) chevauche P08.01 (Sécurité des RP).
• S13 (Fournisseurs) chevauche P01.09 (Conformité des partenaires PRP).
• S11 (Communications) chevauche I01-I09 (Standards d’interopérabilité).

Correctif : construire une vue intégrée des artefacts dès le départ, avec des documents conçus pour servir simultanément plusieurs volets.

10. Glossaire

• BCH — Bureau de certification et d’homologation (ancien nom du Bureau de certification du MSSS).
• BCM — Business Continuity Management.
• BIA — Business Impact Analysis.
• CAI — Commission d’accès à l’information du Québec.
• CB — Certification Body (organisme de certification ISO 27001:2022).
• DIC — Disponibilité, Intégrité, Confidentialité.
• DPO — Data Protection Officer (rôle GDPR; à comparer au Responsable PRP du Québec).
• DRP — Disaster Recovery Plan (plan de reprise informatique).
• DSN — Dossier santé numérique (cadre prévu par la Loi 5).
• DSQ — Dossier santé Québec.
• EBIOS RM — Expression des Besoins et Identification des Objectifs de Sécurité — Risk Manager (méthode d’analyse de risques publiée par l’ANSSI).
• EDR — Endpoint Detection and Response.
• EFVP — Évaluation des facteurs relatifs à la vie privée.
• FIDO2 — Standard moderne d’authentification sans mot de passe (passkeys).
• GIU — Gestion de l’identification des usagers (services communs provinciaux).
• HSM — Hardware Security Module.
• IAM — Identity and Access Management.
• IPMÉ — Identifiant patient maître d’établissement.
• KMS — Key Management Service (AWS, Azure, GCP).
• Loi 5 — Loi sur les renseignements de santé et de services sociaux (LRSSS), entrée en vigueur le 1er juillet 2024.
• LRSSS — voir Loi 5.
• LSSSS — Loi sur les services de santé et les services sociaux (Québec).
• MLA — Multilateral Recognition Arrangement (accords IAF d’accréditation).
• mTLS — TLS mutuel (authentification mutuelle de part et d’autre).
• MSSS — Ministère de la Santé et des Services sociaux du Québec.
• NAM — Numéro d’assurance maladie (RAMQ).
• *NIST SP 800- ** — Special Publications du NIST (séries de publications techniques de référence en cybersécurité).
• NIU — Numéro d’identification unique (provincial).
• PCA — Plan de continuité d’affaires.
• PIMS — Privacy Information Management System (ISO 27701).
• PRI — Plan de réponse aux incidents.
• PRP / PRPS — Protection des renseignements personnels / et de santé.
• PST — Produit ou service technologique.
• RPO — Recovery Point Objective.
• RSSS — Renseignements de santé et de services sociaux.
• RTO — Recovery Time Objective.
• SaaS — Software as a Service.
• SAST / DAST / SCA — Static / Dynamic / Software Composition Application Security Testing.
• SBOM — Software Bill of Materials.
• SIEM — Security Information and Event Management.
• SMSI — Système de management de la sécurité de l’information.
• SoA — Statement of Applicability (ISO 27001:2022).
• SSAE 18 — Statement on Standards for Attestation Engagements 18 (norme AICPA encadrant les missions d’attestation).
• SSSS — Santé et services sociaux (le réseau québécois).
• TGV — Trousse globale de vérification (MSSS Québec).
• TOTP — Time-based One-Time Password.

11. FAQ

Combien de critères y a-t-il dans le volet Sécurité de la TGV?

Le volet Sécurité (S01 à S16) compte 104 critères sur les 254 critères totaux du référentiel TGV, soit 40,9 % du référentiel.

Quel est le sous-domaine le plus volumineux du volet Sécurité TGV?

Le sous-domaine S06 (Contrôle des accès) avec 23 critères (24 par catégorie réelle, en incluant l’anomalie S08.19). Le deuxième plus volumineux est S09 (Sécurité liée à l’exploitation) avec 12 critères.

Une certification ISO 27001:2022 couvre-t-elle entièrement le volet Sécurité TGV?

Non, mais elle couvre l’essentiel. Sur les 16 sous-domaines : 11 en couverture directe (55 critères, ≈ 53 % du volet S), 4 en couverture partielle (45 critères, ≈ 43 %, où certains critères TGV sont plus prescriptifs qu’ISO 27001:2022), et 1 en couverture inverse (S01, 3 critères, où ISO 27001:2022 dépasse largement TGV grâce à ses clauses sur la gestion des risques).

Quelle différence entre la TGV et l’ISO 27001:2022 sur le volet Sécurité?

La TGV est prescriptive (liste de critères à démontrer) alors qu’ISO 27001:2022 est basée sur le risque (l’organisation justifie ses choix de contrôles via l’analyse de risques et la SoA). De plus, ISO 27001:2022 atteste un système de management (SMSI) tandis que la TGV vérifie l’état d’un PST à un moment donné.

Peut-on demander une exception pour un critère qu’on ne peut pas satisfaire?

Oui pour certains critères qui prévoient explicitement ce mécanisme (notamment S06.11 et S06.18). La demande d’exception doit être adressée au MSSS et acceptée explicitement.

Pourquoi le S04 ne s’appelle-t-il pas « Sensibilisation »?

Parce que la sensibilisation et la formation, dans la TGV, ne forment pas un sous-domaine séparé : elles sont intégrées dans S04 « Sécurité des ressources humaines » avec les autres aspects RH.

Y a-t-il des erreurs ou anomalies dans le fichier officiel TGV?

Oui, une anomalie identifiable : le critère codé S08.19 est en réalité catégorisé « Contrôle des accès » et appartient logiquement au sous-domaine S06. Voir la section 7.

12. Sources et méthodologie

12.1 Sources officielles

• Fichier officiel des critères TGV : liste-criteres-TGV_v2024-06-18.xls publié par le MSSS — accessible via la page Orientations, procédures et documents utiles du Bureau de certification.
• Page principale du Bureau de certification : msss.gouv.qc.ca/professionnels/certification-produits-et-services-technologiques.
• Document d’orientation TGV : Certification – Trousse globale de vérification (TGV), MSSS, juin 2024 — publications.msss.gouv.qc.ca/msss/document-003757.
• Orientation sur les tests d’intrusion, Bureau de certification du MSSS.
• ISO/IEC 27001:2022 et ISO/IEC 27002:2022.
• ISO/IEC 27006:2015 (exigences pour organismes d’audit et de certification de SMSI).
• ISO/IEC 27007:2020 (lignes directrices pour l’audit du SMSI).
• ISO/IEC 27008:2019 (lignes directrices pour l’audit des contrôles de l’Annexe A).
• IAF Resolution 2021-22 sur la fin de la transition ISO 27001:2013 → 2022.
• NIST FIPS 140-3 (norme actuelle pour la validation des modules cryptographiques, en remplacement de FIPS 140-2 depuis 2019).
• NIST SP 800-52 Rev. 2 (TLS).
• NIST SP 800-63B (authentification, dont SMS-OTP déprécié).
• NIST SP 800-40 Rev. 4 (gestion des correctifs).
• NIST SP 800-115 (security testing technique).
• NIST SP 800-131A (transitions cryptographiques).
• CIS Controls v8 (référentiel de contrôles industriels, notamment Safeguard 7.1 sur la gestion des correctifs).

12.2 Méthodologie

L’analyse présentée dans cet article est issue d’une extraction programmatique du fichier officiel des critères TGV au 27 avril 2026 :

• Le décompte de 104 critères au volet Sécurité et la répartition par sous-domaine (3, 4, 6, 5, 8, 23, 3, 4, 12, 7, 5, 8, 6, 3, 3, 3) reflètent le contenu exact du fichier source.
• Les libellés des sous-domaines ont été extraits tels quels des cellules « Catégorie » du fichier officiel.
• Les citations littérales sont des extraits directs du contenu du fichier officiel.
• L’anomalie de numérotation S08.19 a été identifiée par le croisement des codes Num et des catégories.

Cartographie TGV ↔ ISO 27001:2022. La cartographie de la section 5 est conduite au niveau sous-domaine par croisement entre les libellés des critères TGV et les libellés des contrôles d’ISO 27001:2022 (Annexe A et clauses pertinentes). La dimension mesurée est la réutilisabilité documentaire et de preuves (capacité à transférer les artefacts SoA vers le format TGV moyennant re-formatage), pas une équivalence conceptuelle. Une cartographie critère-par-critère exhaustive demeure un livrable à venir.

Estimations qualitatives. Les pourcentages de couverture (≈ 53 % directe, ≈ 43 % partielle, ≈ 3 % inverse) sont calculés à partir du nombre de critères contenus dans chaque sous-domaine selon la qualification haut niveau du tableau de la section 5. Ils servent à orienter une décision stratégique de séquencement, pas à fonder un argument contractuel.

12.3 Mises à jour de l’article

• 28 avril 2026 : publication initiale.
• 29 avril 2026 (v3.1) : précisions méthodologiques sur la dimension mesurée; reformulation de la synthèse cartographique au niveau sous-domaine; mise à jour FIPS 140-2 → FIPS 140-3; cadrage de l’anomalie S08.19 comme inférence non confirmée par le MSSS; ajout de citations littérales pour S08, S13 et S08.19; précision sur la pratique du test d’intrusion en ISO 27001:2022 (A.8.29); ajout d’ISO 27007:2020 et 27008:2019 aux sources; complément du glossaire.
• 29 avril 2026 (v3.2) : nom institutionnel mis à jour (« Bureau de certification », anciennement « BCH »); ajout de la note explicite sur l’hétérogénéité interne des sous-domaines « Partielle »; ajout des délais officiels de remédiation pentest (15 jours ouvrables / 3 jours pour vulnérabilité critique) cités du document MSSS de juin 2024; sources NIST SP 800-* citées inline pour les recommandations TLS, patch SLAs, security testing; ajout de SaaS, Loi 5/LRSSS, DSN, SSAE 18 au glossaire; désactivation des liens « à venir » dans la section Articles connexes.
• 29 avril 2026 (v3.3) : ajout d’une section contextuelle sur la Loi 5 (LRSSS) au début de l’article, identifiant les sous-domaines du volet Sécurité directement concernés (S04.05, S10.07, S14.02); qualification de l’estimation de re-formatage SoA → TGV comme « selon l’expérience d’accompagnement de Factero »; cohérence éditoriale renforcée avec l’article pilier de la grappe.
• 30 avril 2026 (v3.4) : optimisations AIO. Ajout d’encadrés « En bref » au début de chaque section H2. Reformulation du titre de la section 9 en question utilisateur. Tableau de cartographie scindé en trois blocs (couverture directe / partielle / inverse) pour faciliter le retrieval par les LLM. Citations littérales étendues pour les sous-domaines S03, S11, S12 (alignement sur le patron S06).

À propos de l’auteur

Sébastien Robert est l’associé principal chez Services conseils Factero. Il pratique en TI depuis 2002, avec une spécialisation en gouvernance, audit, cybersécurité et conformité. Il accompagne des organisations québécoises dans leur préparation à des certifications réglementaires et volontaires.

Services conseils Factero est une firme indépendante de services-conseils en gouvernance TI, cybersécurité et conformité, établie à Saint-Jean-sur-Richelieu (Québec). Factero est elle-même certifiée CAN/DGSI 104:2021 (Rév. 1 : 2024) dans le cadre du programme CyberSécuritaire Canada.

Coordonnées : 900, du Séminaire Nord, suite 320, Saint-Jean-sur-Richelieu (Québec) J2W 1C9 — factero.ca.

Déclaration de transparence. Services conseils Factero offre un service d’accompagnement à la préparation TGV. Cet article est rédigé à des fins informatives et éducatives. Il ne constitue pas un avis juridique. Les fournisseurs visant la certification TGV devraient consulter directement le Bureau de certification du MSSS (certification@sante.quebec) pour valider l’applicabilité et le périmètre exact de leur démarche.