Le projet de loi C-26 est mort : ce qu’impose C-8

Le projet de loi C-26 n’est plus le texte canadien de référence sur la cybersécurité des infrastructures essentielles. Il est mort à la fin de la 44ᵉ législature, puis le projet de loi C-8, qui lui a succédé, a reçu la sanction royale le 15 juin 2026 et créé la Critical Cyber Systems Protection Act. Toutefois, en août 2026, cette loi n’est pas encore en vigueur et son annexe de désignation des exploitants est vide : les obligations de conformité ne s’appliquent donc pas encore.

C’est ce détail que la plupart des synthèses omettent. La loi existe, mais le compte à rebours opérationnel n’a pas commencé. Les responsables de la sécurité ont intérêt à profiter de cette période pour se préparer, tout en distinguant clairement les exigences déjà adoptées, les règlements qui restent à rédiger et les mesures de sécurité judicieuses que la loi n’impose pas.

Qu’est-il arrivé au projet de loi C-26 ?

Le projet de loi C-26 n’est pas devenu loi. Il a atteint les dernières étapes de la 44ᵉ législature, puis est mort au Feuilleton lorsque le Parlement a été prorogé en janvier 2025. Le gouvernement a présenté le projet de loi C-8, très semblable, devant le nouveau Parlement le 18 juin 2025.

Le dossier parlementaire du projet de loi C-26 s’arrête à l’étude des amendements du Sénat. Dans sa documentation ultérieure destinée au comité sur le projet de loi C-8, le gouvernement fédéral décrit C-8 comme presque identique à l’ancien projet de loi. C-8 a suivi l’ensemble du nouveau processus législatif et reçu la sanction royale le 15 juin 2026.

Le nom juridique actuel a son importance. Le projet de loi C-8 constitue désormais le chapitre 9 des Statutes of Canada 2026, sous le titre officiel An Act respecting cyber security, amending the Telecommunications Act and making consequential amendments to other Acts. Sa deuxième partie a adopté la Critical Cyber Systems Protection Act, généralement abrégée en CCSPA.

Appeler encore ce dispositif « projet de loi C-26 » n’est utile que pour en retracer l’histoire ou retrouver un ancien résultat de recherche. Les plans de conformité, les documents destinés au conseil d’administration et les questionnaires fournisseurs devraient mentionner le projet de loi C-8 ou, mieux encore, la CCSPA.

Le projet de loi C-8 est-il actuellement en vigueur ?

Seule une partie du dispositif est en vigueur. Les modifications apportées par C-8 à la Telecommunications Act ont pris effet lors de la sanction royale. La CCSPA, qui contient le cadre relatif au programme de cybersécurité, à la déclaration des incidents, à la chaîne d’approvisionnement, aux registres et aux sanctions, reste explicitement indiquée comme non en vigueur dans le texte actuel publié par Justice Laws.

Dans son annonce de la sanction royale, Sécurité publique Canada précise que la mise en œuvre se fera progressivement, par étapes. La loi autorise le gouverneur en conseil à fixer par décret des dates d’entrée en vigueur différentes selon les dispositions.

Trois étapes supplémentaires sont nécessaires avant qu’une organisation puisse calculer un délai de conformité effectif :

1. Des décrets d’entrée en vigueur doivent rendre applicables les dispositions pertinentes de la CCSPA.
2. Des décrets de désignation doivent ajouter à l’annexe 2 les catégories d’exploitants et les organismes de réglementation correspondants.
3. Des règlements doivent préciser les types d’incidents à déclarer, le délai exact de déclaration, les exigences du programme, la gestion des registres et les sanctions administratives applicables.

Au 28 août 2026, l’annexe 2 est vide. Elle ne comporte aucune association entre une catégorie d’exploitants et un organisme de réglementation. La loi désigne donc des services essentiels, mais pas encore les catégories d’entreprises soumises aux obligations des exploitants.

Ce n’est pas une raison pour ignorer la loi. Il faut simplement employer le présent avec précision : loi adoptée, mais non en vigueur, et aucune catégorie d’exploitants encore désignée.

Qui la Critical Cyber Systems Protection Act couvrira-t-elle ?

La CCSPA vise les exploitants désignés de cybersystèmes essentiels au sein de services essentiels sous réglementation fédérale. Elle ne constitue pas une loi générale sur la cybersécurité applicable à toutes les entreprises canadiennes, ni même à toutes celles qui vendent leurs produits ou services dans un secteur mentionné.

L’annexe 1 énumère actuellement six services et systèmes essentiels :

La loi définit un cybersystème essentiel comme un cybersystème dont la compromission de la confidentialité, de l’intégrité ou de la disponibilité pourrait nuire à la continuité ou à la sécurité d’un service ou système essentiel. Cette notion est plus étroite que celle de « système informatique important ». Une plateforme de messagerie peut être importante, tandis qu’un système de contrôle, de paiement, de routage, de signalisation ou de réseau peut être essentiel parce que sa perte risque d’interrompre le service sous-jacent.

Le gouverneur en conseil peut ajouter des catégories d’exploitants et les organismes de réglementation correspondants à l’annexe 2. Dès qu’une entreprise appartient à une catégorie désignée et possède, contrôle ou exploite un cybersystème essentiel, les obligations légales s’appliquent à ce système.

Tant que ce décret n’existe pas, évitez deux raccourcis fréquents :

• Une banque, un opérateur de télécommunications, une compagnie ferroviaire ou aérienne, un exploitant de pipeline ou un exploitant nucléaire n’est pas automatiquement un exploitant désigné aujourd’hui. La liste des secteurs et la désignation des exploitants constituent deux étapes juridiques distinctes.
• Un fournisseur de services cloud ou SaaS n’est pas automatiquement réglementé parce qu’un futur exploitant désigné l’utilise. Les fournisseurs pourront se voir imposer des exigences contractuelles liées aux obligations de leurs clients concernant la chaîne d’approvisionnement, mais cela ne vaut pas désignation légale directe.

Que devront faire les exploitants désignés ?

Une fois la CCSPA en vigueur et l’exploitant désigné, celui-ci devra maintenir un programme de cybersécurité, pas simplement rédiger un document unique. La loi réunit la gouvernance, la protection technique, la réponse aux incidents, les risques liés aux tiers, les échanges avec les autorités et les éléments de preuve dans un même cycle opérationnel.

Établir et maintenir un programme de cybersécurité

Les articles 9 et 10 accordent à tout exploitant nouvellement désigné un délai de 90 jours à compter de son entrée dans une catégorie désignée pour établir un programme de cybersécurité et le remettre à l’organisme de réglementation compétent, ou le mettre à sa disposition. Ce dernier peut prolonger ce délai sur demande écrite.

Le programme doit prévoir des mesures destinées à :

• recenser et gérer les risques de cybersécurité de l’organisation, notamment ceux liés à la chaîne d’approvisionnement et aux tiers ;
• protéger les cybersystèmes essentiels contre toute compromission ;
• détecter les incidents qui touchent ou pourraient toucher ces systèmes ; et
• réduire au minimum les conséquences des incidents.

L’exploitant doit mettre en œuvre et maintenir ce programme. Il doit l’examiner aux dates fixées par règlement ou, à défaut, à chaque date anniversaire de sa mise en place. Selon le délai légal actuellement prévu par défaut, cet examen doit être achevé sous 60 jours et l’exploitant doit indiquer à l’organisme de réglementation, dans les 30 jours qui suivent, si le programme a changé.

Traiter les changements dans la chaîne d’approvisionnement comme des événements de sécurité

L’article 15 impose à l’exploitant désigné d’atténuer un risque lié à la chaîne d’approvisionnement ou à un tiers dès qu’il est identifié. L’article 14 exige également de signaler les changements importants relatifs à la propriété, au contrôle, à la chaîne d’approvisionnement ou à l’utilisation de produits et services tiers, dans les délais que fixeront les règlements.

La gestion des fournisseurs devient ainsi une composante permanente du programme de sécurité. Un exploitant désigné ne peut pas remplir une fois par an un questionnaire sur ses fournisseurs et considérer le risque comme réglé. Il lui faut un inventaire, des responsables nommément désignés, des critères de déclenchement en cas de changement important et un processus reliant tout constat concernant un fournisseur à une décision actualisée sur le risque.

Conserver les preuves au Canada

L’article 30 exige des registres portant sur la mise en œuvre du programme, les incidents déclarés, l’atténuation des risques liés à la chaîne d’approvisionnement et les mesures prises en application des directives de cybersécurité. Ces registres doivent être conservés au Canada, à l’endroit prescrit ou, si aucun lieu n’est prescrit, à l’établissement de l’exploitant. L’organisme de réglementation ou de futurs règlements détermineront les modalités et la durée de conservation.

Le lieu de stockage n’est pas le seul enjeu. Les registres doivent montrer ce que l’organisation a fait. Une politique dépourvue d’historique des versions, de chronologie des incidents, de journal des décisions ou de preuves de correction sera difficile à défendre lors d’une inspection ou d’un audit interne ordonné.

Le délai de déclaration prévu par la CCSPA est-il exactement de 72 heures ?

Pas encore. La loi fixe un délai maximal de déclaration, mais pas une échéance universelle définitive. L’article 17 oblige tout exploitant désigné à déclarer au Communications Security Establishment un incident de cybersécurité dans le délai prescrit par règlement, lequel ne peut pas dépasser 72 heures.

Les règlements doivent encore définir les types d’incidents à déclarer, le délai exact, le format et le mode de déclaration. Il est donc inexact d’affirmer que tout événement de cybersécurité doit être déclaré dans un délai fixé à exactement 72 heures.

La séquence adoptée est claire, même si les modalités restent à définir :

1. Un exploitant désigné identifie un incident à déclarer qui touche l’un de ses cybersystèmes essentiels.
2. Il le déclare au Communications Security Establishment dans le délai prescrit, plafonné à 72 heures.
3. Immédiatement après cette déclaration, il prévient l’organisme de réglementation compétent et lui en transmet une copie.

La définition légale de l’incident est vaste. Elle comprend tout acte, toute omission ou toute circonstance qui perturbe ou pourrait perturber la continuité ou la sécurité d’un service essentiel, ou encore la confidentialité, l’intégrité ou la disponibilité d’un cybersystème essentiel. Les règlements doivent encore déterminer quels incidents relevant de cette définition générale devront être déclarés.

Les déclarations au titre de la CCSPA ne supprimeront pas les autres obligations. L’article 18.1 préserve expressément la Personal Information Protection and Electronic Documents Act. Un même incident peut donc déclencher des chantiers distincts en matière de cybersécurité, de protection des renseignements personnels, de contrats et de réglementation sectorielle.

La bonne stratégie de préparation ne consiste pas à « envoyer la déclaration à la 71ᵉ heure ». Il faut un processus capable de qualifier un événement, de mobiliser les juristes, de préserver les preuves, d’informer la direction et de préparer les notifications au CSE et à l’organisme de réglementation bien avant l’échéance légale maximale.

Que signifie le projet de loi C-8 pour les fournisseurs et les éditeurs SaaS ?

La plupart des fournisseurs verront d’abord les effets du projet de loi C-8 dans les exigences formulées par leurs clients, avant toute désignation directe. Il s’agit d’une déduction tirée des obligations de la loi relatives à la chaîne d’approvisionnement, et non d’une règle légale distincte applicable à tous les fournisseurs.

Les exploitants désignés devront recenser et atténuer les risques liés aux produits et services tiers, puis informer les autorités des changements importants. Plusieurs questions prévisibles se poseront donc lors des achats :

• Quels systèmes et services essentiels du client dépendent du fournisseur ?
• Où sont stockés les données, les journaux, les sauvegardes et les registres d’incidents ?
• Dans quel délai le fournisseur doit-il prévenir l’exploitant d’un incident suspecté ?
• Quels sous-traitants peuvent accéder au service ?
• L’exploitant peut-il obtenir des preuves, des résultats d’audit et l’état des corrections ?
• Qu’est-ce qui constitue un changement important du produit, du modèle d’hébergement, de la propriété ou de la chaîne d’approvisionnement ?

N’inventez ni délai légal pour les fournisseurs ni clause contractuelle obligatoire. Les règlements ne sont pas définitifs et les exigences varieront selon les exploitants. La bonne démarche consiste à cartographier dès maintenant les dépendances essentielles des clients, afin d’aborder les négociations contractuelles avec des faits précis sur l’architecture et la réponse aux incidents, plutôt qu’avec une annexe de sécurité générique.

Si vous vendez également en Europe, comparez ce dispositif avec notre guide sur les obligations de déclaration de l’EU Cyber Resilience Act. La portée et les critères de déclenchement diffèrent, mais les deux régimes sanctionnent la même faiblesse opérationnelle : découvrir pendant un incident que personne ne prend en charge la réception, la classification, la notification et la traçabilité des preuves.

Quel est le montant des sanctions prévues par la CCSPA ?

La CCSPA prévoit des plafonds légaux élevés, mais le régime concret de sanctions administratives dépend encore des règlements. L’article 91 plafonne toute sanction fixée par règlement à 500 000 CAD pour une personne physique et à 15 millions CAD dans tous les autres cas.

Ces montants ne sont pas des amendes automatiques applicables à chaque incident. Les règlements doivent d’abord préciser les manquements qui constituent des violations, les classer et fixer le plafond applicable à chacun. Selon la loi, les sanctions visent à favoriser la conformité, et la diligence raisonnable peut être invoquée comme moyen de défense dans une procédure administrative.

Le dispositif de contrôle reste néanmoins très contraignant :

• une violation continue peut être considérée comme une violation distincte pour chaque jour ;
• la responsabilité personnelle des administrateurs ou dirigeants peut être engagée s’ils ont ordonné ou autorisé la violation, y ont consenti ou acquiescé, ou y ont participé ;
• les organismes de réglementation peuvent procéder à des inspections, ordonner des audits internes et rendre des ordonnances de conformité ; et
• des dispositions pénales distinctes permettent aux tribunaux de fixer des amendes et, dans certains cas prévus, d’infliger une peine d’emprisonnement aux personnes physiques.

La leçon utile n’est pas que « chaque incident coûte 15 millions CAD ». C’est plutôt que les preuves d’une préparation raisonnable, d’une alerte transmise au bon niveau, de l’atténuation du risque et du suivi pourront compter. Le programme doit être opérationnel avant que l’organisme de réglementation ne le demande.

Que doivent faire les équipes de sécurité avant l’adoption des règlements ?

Préparez les éléments qui ont peu de chances de devenir inutiles et surveillez la Gazette du Canada pour connaître les précisions juridiques. Ne tentez pas de deviner quelles entreprises seront désignées et ne figez pas une règle de déclaration qui n’existe pas encore.

1. Reliez les services essentiels aux systèmes qui les prennent en charge. Partez du service sur lequel les clients comptent, puis recensez les systèmes dont la perte de confidentialité, d’intégrité ou de disponibilité pourrait l’interrompre.
2. Nommez un responsable de direction et un responsable opérationnel. Le programme de cybersécurité a besoin d’un décideur, ainsi que d’une personne capable de coordonner ingénierie, juridique, communication, protection des renseignements personnels et relations avec l’organisme de réglementation pendant un incident.
3. Inventoriez les dépendances de la chaîne d’approvisionnement. Consignez les fournisseurs essentiels, les sous-traitants, les régions d’hébergement, l’emplacement des données, les contacts en cas d’incident et les critères de déclenchement d’un changement important.
4. Rédigez un mode opératoire pour qualifier les incidents et les notifier. Gardez configurable le seuil précis de la CCSPA. Prévoyez les décisions relatives au CSE, au futur organisme de réglementation sectoriel, à la protection des renseignements personnels, aux contrats, à l’assureur, aux forces de l’ordre et à la communication.
5. Organisez un exercice chronométré. Vérifiez si l’équipe peut détecter et qualifier l’incident, préserver les preuves, approuver une déclaration et informer la direction dans un délai inférieur à 72 heures.
6. Conservez une chronologie étayée. Consignez le moment où l’événement est survenu et celui où il a été détecté, les décisions prises et leur auteur, les mesures de confinement appliquées et le moment où les tiers ont été prévenus.
7. Surveillez les sources primaires. Consultez régulièrement la page de la CCSPA sur Justice Laws et la Gazette du Canada pour suivre les décrets d’entrée en vigueur, les désignations de l’annexe 2 et les règlements d’application.

La réception des signalements externes de vulnérabilités doit faire partie de cette préparation. La CCSPA n’impose ni programme de divulgation des vulnérabilités ni fichier security.txt, mais un signalement externe peut constituer le premier indice d’une faiblesse dans un système essentiel. Notre guide consacré à la mise en place d’un programme de divulgation des vulnérabilités détaille le point de contact public, le périmètre, la sphère de sécurité (Safe Harbor) et le processus de triage interne.

Comment Kit étaye un traitement des incidents traçable

Kit facilite la réception, l’attribution, la coordination et la conservation des preuves relatives aux signalements de vulnérabilités. Il ne suffit pas à rendre une organisation conforme à la CCSPA. Kit ne surveille pas les réseaux, n’inventorie pas les systèmes essentiels, ne gère pas les risques liés aux fournisseurs et ne transmet pas de déclarations au CSE ou à un organisme de réglementation.

Le module de sécurité de Kit fournit aux chercheurs externes un portail de signalement aux couleurs de l’entreprise et publie un fichier security.txt conforme à la RFC 9116. Toute vulnérabilité signalée peut ainsi parvenir à l’entreprise par un canal prévu à cet effet. Les signalements passent par un triage structuré, une évaluation CVSS, une attribution, un historique des statuts, des échanges avec les chercheurs et un suivi des SLA. Les rotations d’astreinte et l’intégration PagerDuty permettent d’attribuer rapidement tout signalement urgent.

Après validation d’un signalement, la transmission vers Jira ou Linear permet de confier sa correction à l’équipe d’ingénierie sans copier par défaut les détails sensibles permettant d’exploiter la faille. La chronologie du signalement, les messages, le post-mortem, les preuves et le dossier PDF conservent le déroulement des faits et les motivations des décisions. Consultez les procédures détaillées pour le triage des signalements de vulnérabilités ainsi que les post-mortems et l’analyse des causes profondes.

Le projet de loi C-8 a fixé l’orientation législative, mais le périmètre opérationnel de la CCSPA reste en construction. Le projet de loi C-26 appartient à l’histoire. Le constat actuel est plus limité : la loi est adoptée, mais pas en vigueur ; l’annexe 2 est vide ; et les règlements détermineront les modalités exactes de déclaration et de sanction.

Il s’agit donc d’une période de préparation, pas d’une échéance de conformité. Constituez dès maintenant l’inventaire, désignez les responsables, préparez le processus de notification, rassemblez les preuves relatives aux fournisseurs et organisez la chronologie des incidents. Lorsque les désignations et les règlements entreront en vigueur, votre équipe devra ajuster un système qui fonctionne déjà, et non partir d’un document vierge.