En bref : Les normes de continuité informatique appliquées au Québec et au Canada, soit la TGV de Santé Québec, ISO 22301, SOC 2, CAN/DGSI 104 et ITSP.10.171, exigent toutes des sauvegardes fiables, un plan de relance écrit et des tests documentés. Comprendre ce socle commun évite de rebâtir un programme de continuité à chaque nouvelle certification visée.
Un dirigeant qui vise plusieurs certifications à la fois se heurte vite à la même question : faut-il un programme de continuité différent pour chaque norme ? La réponse courte est non. Ce qui change d’un référentiel à l’autre, c’est la forme de la preuve exigée, pas la logique de fond.
Si vous partez de zéro, notre guide complet sur les sauvegardes, le plan de relance et les tests est le point de départ. Cet article-ci se concentre sur ce que chaque norme exige par-dessus ce socle, et sur ce qui reste identique d’une norme à l’autre.
Dans cet article
Que demande la TGV ?
La TGV exige des sauvegardes fiables, un plan de relance documenté et des tests, des critères logés dans sa famille Sécurité. La TGV, ou Trousse globale de vérification, est le processus de certification du ministère de la Santé et des Services sociaux (MSSS) du Québec pour les technologies destinées au réseau de la santé. Nous en détaillons le fonctionnement dans notre guide complet sur la certification TGV. Depuis sa mise à jour du 24 avril 2026, la grille de vérification compte 382 critères répartis en 7 familles, dont la famille Sécurité, qui regroupe à elle seule 112 critères.
Les exigences de continuité et de sauvegarde se retrouvent principalement dans cette famille. Le nombre exact de critères qui touchent spécifiquement vos sauvegardes, votre plan de relance et vos tests se confirme dans le fichier officiel de la grille, diffusé sur la page de l’orientation du MSSS sur la certification TGV (publication 24-715-38W). C’est la source à consulter avant de construire un dossier de preuve, pas un résumé comme celui-ci.
Ce qui compte pour un dirigeant à ce stade : un plan de relance mal documenté ou jamais testé n’est pas un détail à corriger en fin de parcours. C’est un écart qui coûte du temps précieux quand un appel d’offres est déjà sur la table.
Comme les autres normes de continuité informatique de ce comparatif, la TGV ne se contente pas de l’existence d’un plan. Elle en veut la preuve testée.
Que couvre ISO 22301 ?
ISO 22301 est la norme internationale de l’Organisation internationale de normalisation dédiée à la continuité d’activité. Contrairement à la TGV ou à CAN/DGSI 104, qui traitent la continuité parmi d’autres exigences, ISO 22301 n’a que ça comme sujet.
La norme exige un système de gestion complet : une analyse d’impact sur les affaires qui identifie vos processus critiques et le délai tolérable avant qu’une interruption devienne dommageable, des stratégies de continuité adaptées à ces processus, des plans documentés, des exercices réguliers pour vérifier que ces plans fonctionnent, et un mécanisme d’amélioration continue qui corrige ce que les exercices révèlent.
C’est la norme la plus exigeante des cinq sur le fond. Elle ne se contente pas de sauvegardes et d’un plan : elle demande de démontrer que l’organisation entière sait quoi faire, dans quel ordre, et pourquoi. La certification n’est pas un aboutissement figé. Elle repose sur des audits de surveillance périodiques, pas seulement sur l’audit initial, ce qui veut dire que le plan doit rester vivant, pas prendre la poussière dans un classeur partagé que personne ne rouvre.
Que demande SOC 2 en matière de disponibilité ?
SOC 2 traite la continuité informatique par son critère de disponibilité, l’un des cinq critères des services de confiance définis par l’association américaine des comptables agréés à travers ses Trust Services Criteria. Contrairement à ISO 22301 ou à la TGV, SOC 2 (System and Organization Controls 2) n’est pas une certification au sens strict : c’est un rapport d’audit, produit par un auditeur indépendant, qui atteste que certains contrôles fonctionnent comme promis.
Ce critère porte sur l’engagement de service pris envers vos clients : vos systèmes sont-ils accessibles comme promis, et que faites-vous pour tenir cet engagement en cas d’incident ? Les sauvegardes, le plan de relance et la surveillance des systèmes en sont les leviers concrets.
Un rapport SOC 2 de type II, le plus exigeant des deux types, ne se contente pas de vérifier que vos contrôles existent sur papier. L’auditeur vérifie qu’ils ont réellement fonctionné pendant la période couverte par le rapport. Un plan de relance jamais testé se voit, dans un rapport de type II, aussi clairement que sur le terrain.
Que demande CAN/DGSI 104 ?
CAN/DGSI 104 exige la sauvegarde des données comme contrôle de base, aux côtés de la protection des appareils et de la gestion des accès. CAN/DGSI 104 est la norme du Digital Governance Standards Institute à la base du programme CyberSécuritaire Canada, la certification de cybersécurité destinée aux petites et moyennes organisations.
Nous avons complété cette démarche pour notre propre cabinet, avec un certificat obtenu le 19 avril 2026. La sauvegarde n’y était pas une case abstraite dans un formulaire en ligne : c’était une preuve concrète à démontrer, exactement comme n’importe quelle organisation candidate le vit. La preuve attendue est une auto-déclaration appuyée de documents, pas un audit externe complet comme celui d’ISO 22301, ce qui rend la démarche plus accessible pour une petite structure, sans la rendre superficielle pour autant.
La certification CyberSécuritaire Canada n’est pas acquise pour toujours non plus. Elle s’accompagne d’un renouvellement, ce qui veut dire que le programme de sauvegarde documenté au moment de la certification doit rester à jour, pas seulement exister le jour de l’attestation.
Que demande ITSP.10.171 ?
ITSP.10.171 est la norme du Centre canadien pour la cybersécurité qui encadre la protection de l’information désignée, c’est-à-dire l’information sensible mais non classifiée que le gouvernement fédéral confie à ses fournisseurs. Elle sert de fondement technique au CPCSC, le programme canadien de certification en cybersécurité, aussi appelé PCCC.
Nous consacrons un guide complet au CPCSC et au PCCC ailleurs sur ce site. Sur les sauvegardes et la relance précisément, la prudence est de mise : les exigences exactes, et surtout ce qui distingue le niveau 1 du niveau 2, se lisent directement dans le texte de la norme, publié par le Centre canadien pour la cybersécurité. Une entreprise qui bâtit son dossier sur une paraphrase plutôt que sur la norme elle-même risque de découvrir l’écart au pire moment, pendant la vérification.
Comment les normes de continuité informatique se comparent-elles, exigence par exigence ?
Le tableau qui suit résume la position de chaque référentiel sur les trois mêmes exigences. Il est qualitatif : il indique la présence ou l’absence d’une exigence et le type de preuve attendu, pas un pointage.
<div style= »overflow-x: auto; »>
| Référentiel | Sauvegardes | Plan de relance écrit | Tests documentés | Nature de la preuve |
|---|---|---|---|---|
| TGV (Santé Québec) | Exigées | Exigé | Exigés | Dossier de certification vérifié par une firme externe |
| ISO 22301 | Exigées, un moyen parmi d’autres | Exigé, fondé sur une analyse d’impact | Exigés, de façon récurrente | Système de gestion audité, certification renouvelable |
| SOC 2 (disponibilité) | Exigées | Exigé | Exigés pour un rapport de type II | Rapport d’audit indépendant |
| CAN/DGSI 104 | Exigées, contrôle de base | Exigé | Recommandés | Auto-déclaration appuyée de preuves |
| ITSP.10.171 (CPCSC) | À confirmer dans la norme | À confirmer dans la norme | À confirmer dans la norme | Variable selon le niveau visé |
</div>
Deux lignes de ce tableau méritent un mot d’explication. La ligne ITSP.10.171 reste volontairement prudente : les exigences précises varient selon le niveau de certification visé, et les affirmer sans les avoir vérifiées dans le texte de la norme serait rendre un mauvais service à qui prépare un dossier. La ligne CAN/DGSI 104 distingue « recommandés » de « exigés » pour les tests : le contrôle de base porte sur la sauvegarde elle-même, pas sur un calendrier de tests aussi formel que celui d’ISO 22301.
Un seul programme de continuité informatique pour plusieurs certifications ?
Les cinq normes de continuité informatique de ce comparatif convergent vers un seul programme, sous une forme de preuve différente pour chacune. Des sauvegardes fiables et testées, un plan de relance écrit et connu de l’équipe, des exercices documentés qui prouvent que ce plan fonctionne : ce socle sert la TGV, ISO 22301, SOC 2, CAN/DGSI 104 et ITSP.10.171 à la fois. Ce qui change, c’est la forme de la preuve à déposer :
- TGV : un dossier de certification vérifié par une firme externe.
- ISO 22301 : un système de gestion audité et renouvelable.
- SOC 2 : un rapport d’audit indépendant.
- CAN/DGSI 104 : une auto-déclaration appuyée de preuves.
Construire ce socle une fois, puis l’adapter au format de chaque norme, coûte moins cher et prend moins de temps que de reconstruire un programme différent pour chaque démarche. Notre article sur le test de relance, ou test DR, documente précisément le type d’exercice que la plupart de ces référentiels exigent sous une forme ou une autre.
Concrètement, pour un dirigeant qui démarre, l’ordre de travail ressemble à ceci :
- Auditer la capacité de relance réelle avant même de choisir la norme à viser en premier.
- Bâtir une fois le socle commun : sauvegardes fiables, plan de relance écrit, tests documentés.
- Adapter ce socle au format exigé par la norme visée : dossier de certification, système de gestion audité, rapport d’audit ou auto-déclaration.
- Prioriser l’ordre des démarches selon les échéances contractuelles.
Reste une question que peu de dirigeants se posent avant qu’un auditeur la pose à leur place : votre plan fonctionnerait-il vraiment, aujourd’hui, si vous en aviez besoin ? Vous visez une certification, peu importe laquelle des cinq. Vérifiez d’abord, par un audit TI indépendant, que votre relance tiendrait la route : les faits tels qu’ils sont, avant que l’auditeur de certification ne les découvre à votre place.
Pour qui s’intéresse spécifiquement aux recoupements entre ISO 22301 et la grille TGV, notre comparatif HDS v2 et ISO 22301 face à la TGV creuse la question plus loin.
Pour aller plus loin avec Factero :
- test de sauvegardes et plan de relève
- accompagnement à la certification TGV
- accompagnement à la certification CAN/DGSI 104
Foire aux questions
Faut-il un plan de relance différent pour chaque certification ?
Non. Le contenu de fond, sauvegardes fiables, plan écrit, tests documentés, reste le même d’une démarche à l’autre. Ce qui varie, c’est la forme de la preuve à déposer : dossier de certification, système de gestion audité, rapport d’audit ou auto-déclaration.
À quelle fréquence faut-il tester un plan de relance ?
La fréquence exacte dépend du référentiel visé et n’est pas la même pour un système de gestion ISO 22301 que pour une auto-déclaration CAN/DGSI 104. Ce qui reste constant d’une norme à l’autre : un test jamais refait vieillit aussi vite que les systèmes qui changent autour de lui.
Quelle différence entre ISO 22301 et SOC 2 ?
SOC 2 n’est pas une certification, contrairement à ISO 22301. ISO 22301 est un système de gestion complet, audité et renouvelable, entièrement consacré à la continuité : analyse d’impact, plans documentés, exercices réguliers. SOC 2 est un rapport d’audit indépendant qui couvre la disponibilité parmi cinq critères de confiance, sans procédure de certification formelle. Les deux exigent sauvegardes, plan de relance et tests, sous une forme de preuve différente.
SOC 2 type I ou type II : quelle différence ?
Le rapport de type II est le plus exigeant des deux. L’auditeur y vérifie que les contrôles ont réellement fonctionné pendant toute la période couverte par le rapport, pas seulement qu’ils existent sur papier. Le rapport de type I n’offre pas cette profondeur. Un plan de relance jamais testé se voit, dans un rapport de type II, aussi clairement que sur le terrain.
Par où commencer pour une PME qui vise une certification de cybersécurité ?
Par un audit honnête de la capacité de relance réelle, avant de choisir la norme à viser en premier. Le socle commun, sauvegardes fiables, plan de relance écrit, tests documentés, se bâtit une fois, puis s’adapte au format de la norme choisie : dossier de certification, système de gestion audité, rapport d’audit ou auto-déclaration. L’ordre des démarches se décide ensuite selon les échéances contractuelles.
