El Bill C-26 decayó: qué exige el Bill C-8 de Canadá

El Bill C-26 ya no es el proyecto de ley canadiense sobre ciberseguridad de infraestructuras críticas. Quedó sin efecto al concluir la 44.ª legislatura, y su sucesor, el Bill C-8, recibió la sanción real el 15 de junio de 2026, con lo que se promulgó la Critical Cyber Systems Protection Act (CCSPA). Sin embargo, en agosto de 2026 la ley todavía no está en vigor y el anexo que debe designar a las clases de operadores sigue vacío, por lo que sus obligaciones de cumplimiento aún no han empezado a aplicarse.

Ese es el matiz que se les escapa a la mayoría de los resúmenes. La ley existe, pero los plazos operativos todavía no han empezado a correr. Los responsables de seguridad deberían aprovechar este intervalo para prepararse, sin confundir los requisitos ya aprobados, los reglamentos que aún deben redactarse y los controles razonables que la ley no impone.

¿Qué ocurrió con el Bill C-26?

El Bill C-26 no llegó a convertirse en ley. Alcanzó las últimas fases de la 44.ª legislatura, pero quedó sin efecto cuando el Parlamento se prorrogó en enero de 2025. El Gobierno presentó el Bill C-8, muy similar al anterior, en la nueva legislatura el 18 de junio de 2025.

El expediente parlamentario del Bill C-26 llega hasta el examen de las enmiendas del Senado. La documentación posterior del comité sobre el Bill C-8, publicada por el Gobierno federal, describe el Bill C-8 como prácticamente idéntico al proyecto anterior. El Bill C-8 completó el nuevo trámite legislativo y recibió la sanción real el 15 de junio de 2026.

El nombre jurídico actual importa. El Bill C-8 es ahora el capítulo 9 de los Statutes of Canada de 2026, cuyo título formal es An Act respecting cyber security, amending the Telecommunications Act and making consequential amendments to other Acts. Su segunda parte promulgó la Critical Cyber Systems Protection Act, abreviada habitualmente como CCSPA.

Llamar «Bill C-26» a este régimen solo resulta útil para explicar su historia o localizar una búsqueda antigua. Los planes de cumplimiento normativo, la documentación para el consejo de administración y los cuestionarios a proveedores deberían referirse al Bill C-8 o, mejor aún, a la CCSPA.

¿Está ya en vigor el Bill C-8?

Solo una parte del paquete está en vigor. Las enmiendas del Bill C-8 a la Telecommunications Act surtieron efecto con la sanción real. La CCSPA, que contiene el marco sobre el programa de ciberseguridad, la notificación de incidentes, la cadena de suministro, los registros y la aplicación de la ley, todavía figura expresamente como no vigente en el texto actual de Justice Laws.

El anuncio de la sanción real de Public Safety Canada indica que la implantación será gradual y por fases. La ley permite que el Gobernador en Consejo fije por orden fechas distintas para la entrada en vigor de sus disposiciones.

Faltan tres pasos para que una organización pueda calcular un plazo de cumplimiento efectivo:

1. Las órdenes de entrada en vigor deben activar las disposiciones correspondientes de la CCSPA.
2. Las órdenes de designación deben añadir al anexo 2 las clases de operadores y sus organismos reguladores.
3. Los reglamentos deben concretar aspectos como los tipos de incidentes sujetos a notificación, el plazo exacto, los requisitos del programa, la gestión de registros y las sanciones administrativas aplicables.

A 28 de agosto de 2026, el anexo 2 está vacío. No contiene ninguna combinación de clase de operador y organismo regulador. Por tanto, la ley enumera servicios esenciales, pero todavía no designa ninguna clase de empresas sujeta a las obligaciones aplicables a los operadores.

No es un motivo para ignorar la ley, sino para describir correctamente el presente: promulgada, pero no vigente y aún sin clases de operadores designadas.

¿A quién abarcará la Critical Cyber Systems Protection Act?

La CCSPA se ha concebido para los operadores designados de sistemas cibernéticos críticos que prestan servicios esenciales sujetos a regulación federal. No es una ley general de ciberseguridad para todas las empresas canadienses, ni siquiera para todas las compañías que venden a uno de los sectores enumerados.

El anexo 1 incluye actualmente seis servicios y sistemas esenciales:

La ley define un sistema cibernético crítico como aquel cuya confidencialidad, integridad o disponibilidad, si se vieran comprometidas, podrían afectar a la continuidad o la seguridad de un servicio o sistema esencial. Es un concepto más limitado que «TI importante». Una plataforma de correo puede ser importante, mientras que un sistema de control, pagos, encaminamiento, señalización o red puede ser crítico porque su pérdida interrumpiría el servicio subyacente.

El Gobernador en Consejo puede incorporar al anexo 2 clases de operadores y sus correspondientes organismos reguladores. Cuando una empresa pertenezca a una clase designada y sea propietaria, controle u opere un sistema cibernético crítico, los deberes legales se aplicarán a ese sistema.

Hasta que exista esa orden, conviene evitar dos atajos habituales:

• Un banco, un proveedor de telecomunicaciones, un ferrocarril, una aerolínea, un operador de tuberías o un operador nuclear no es automáticamente un operador designado a día de hoy. La lista de sectores y la designación del operador son dos pasos jurídicos distintos.
• Un proveedor de servicios en la nube o SaaS tampoco queda regulado automáticamente porque lo utilice un futuro operador designado. Los proveedores pueden recibir presión contractual a través de las obligaciones de sus clientes sobre la cadena de suministro, pero eso no equivale a una designación legal directa.

¿Qué tendrán que hacer los operadores designados?

Cuando la CCSPA entre en vigor y se designe a un operador, este necesitará un programa de ciberseguridad mantenido en el tiempo, no un documento redactado una sola vez. La ley reúne la gobernanza, la protección técnica, la respuesta a incidentes, el riesgo de terceros, la comunicación con el organismo regulador y las pruebas en un único ciclo operativo.

Establecer y mantener un programa de ciberseguridad

Los artículos 9 y 10 conceden a un operador recién designado 90 días desde que pasa a formar parte de una clase designada para establecer un programa de ciberseguridad y entregarlo o ponerlo a disposición del organismo regulador competente. El organismo puede ampliar ese plazo previa solicitud por escrito.

El programa debe incluir medidas para:

• identificar y gestionar los riesgos de ciberseguridad de la organización, incluidos los de la cadena de suministro y de terceros;
• proteger los sistemas cibernéticos críticos frente a vulneraciones;
• detectar incidentes que afecten o puedan afectar a esos sistemas; y
• reducir al mínimo el impacto de los incidentes.

El operador debe implantar y mantener el programa. También debe revisarlo en las fechas que establezca el reglamento o, por defecto, en cada aniversario de su creación. El plazo legal actual concede 60 días para completar esa revisión y 30 días desde su finalización para comunicar al organismo regulador si el programa ha cambiado.

Tratar los cambios en la cadena de suministro como eventos de seguridad

El artículo 15 dispone que un operador designado debe mitigar un riesgo de la cadena de suministro o de un tercero en cuanto lo identifique. El artículo 14 también exige notificar los cambios sustanciales en la propiedad, el control, la cadena de suministro o el uso de productos y servicios de terceros, dentro de los plazos que determine el reglamento.

De este modo, la gestión de proveedores pasa a formar parte del programa de seguridad activo. Un operador crítico no puede archivar un cuestionario de proveedor una vez al año y dar el riesgo por cerrado. Necesita un inventario, responsables definidos, criterios que activen la revisión de cambios sustanciales y una vía que conecte el hallazgo de un proveedor con una decisión de riesgo actualizada.

Conservar las pruebas en Canadá

El artículo 30 exige registros sobre la implantación del programa, los incidentes notificados, la mitigación en la cadena de suministro y las medidas adoptadas en virtud de las instrucciones de ciberseguridad. Esos registros deben conservarse en Canadá, en el lugar que se determine reglamentariamente o, si no se fija ninguno, en el establecimiento del operador. El organismo regulador o los futuros reglamentos determinarán el modo y el período de conservación.

La cuestión no se reduce a la ubicación del almacenamiento. Los registros deben demostrar qué hizo la organización. Una política sin historial de versiones, cronología del incidente, registro de decisiones ni pruebas de corrección será difícil de defender durante una inspección o una auditoría interna ordenada por el regulador.

¿Es exactamente de 72 horas el plazo para notificar incidentes de la CCSPA?

Todavía no. La ley fija un plazo máximo, no un plazo general definitivo. El artículo 17 exige que un operador designado notifique al Communications Security Establishment (CSE) los incidentes de ciberseguridad dentro del plazo que establezca el reglamento, que no podrá superar las 72 horas.

El reglamento todavía debe definir qué tipos de incidentes han de notificarse, el plazo exacto, el formato y el método de comunicación. Por tanto, no es correcto afirmar que todo evento cibernético deba notificarse en exactamente 72 horas.

La secuencia que establece la ley está clara, aunque falten los detalles:

1. Un operador designado detecta un incidente sujeto a notificación que afecta a uno de sus sistemas cibernéticos críticos.
2. Lo comunica al CSE dentro del plazo reglamentario, con un máximo de 72 horas.
3. Inmediatamente después, avisa al organismo regulador competente y le entrega una copia del informe.

La definición legal de incidente es amplia. Incluye un acto, una omisión o una circunstancia que interfiera o pueda interferir con la continuidad o la seguridad de un servicio esencial, o con la confidencialidad, integridad o disponibilidad de un sistema cibernético crítico. El reglamento todavía debe decidir qué incidentes incluidos en esa definición general activarán la obligación de notificación.

La notificación conforme a la CCSPA no eliminará otras obligaciones. El artículo 18.1 preserva expresamente la Personal Information Protection and Electronic Documents Act. Por ello, un solo incidente puede abrir líneas de trabajo separadas en materia de ciberseguridad, privacidad, contratos y regulación sectorial.

El objetivo más seguro para prepararse no es «enviarlo en la hora 71». Conviene contar con un proceso capaz de clasificar un evento, implicar a la asesoría jurídica, conservar las pruebas, informar a la dirección y preparar las notificaciones al CSE y al organismo regulador mucho antes del máximo legal.

¿Qué implica el Bill C-8 para los proveedores y las empresas SaaS?

La mayoría de los proveedores notarán el Bill C-8 a través de las exigencias de sus clientes antes que por una designación directa. Se trata de una inferencia a partir de los deberes de la ley sobre la cadena de suministro, no de una norma legal independiente aplicable a todos los proveedores.

Los operadores designados deberán identificar y mitigar los riesgos de los productos y servicios de terceros y, después, notificar los cambios sustanciales al organismo regulador. Por eso cabe prever varias preguntas en los procesos de compra:

• ¿Qué sistemas y servicios esenciales del cliente dependen del proveedor?
• ¿Dónde se almacenan los datos, registros, copias de seguridad e informes de incidentes?
• ¿Con qué rapidez debe el proveedor avisar al operador ante la sospecha de un incidente?
• ¿Qué subcontratistas pueden acceder al servicio?
• ¿Puede el operador obtener pruebas, resultados de auditorías y el estado de las correcciones?
• ¿Qué se considera un cambio sustancial del producto, el modelo de alojamiento, la propiedad o la cadena de suministro?

No inventes un plazo legal para proveedores ni una cláusula contractual obligatoria. El reglamento no es definitivo y cada operador tendrá necesidades distintas. Lo útil es trazar ahora las dependencias críticas de los clientes, para que las negociaciones contractuales partan de datos reales sobre la arquitectura y la respuesta, no de un anexo de seguridad genérico.

Si un proveedor también vende en Europa, conviene comparar esta estructura con la guía de notificación del Reglamento de Ciberresiliencia de la UE. Los regímenes difieren en su alcance y sus supuestos de activación, pero ambos penalizan la misma carencia operativa: descubrir en mitad de un incidente que nadie se responsabiliza de la recepción, la clasificación, la notificación ni el rastro de pruebas.

¿De cuánto son las sanciones de la CCSPA?

La CCSPA establece topes legales elevados, pero el régimen real de sanciones administrativas todavía necesita un reglamento. El artículo 91 limita la sanción que se fije reglamentariamente a 500 000 CAD para una persona física y 15 millones de CAD en cualquier otro caso.

Esas cifras no son multas automáticas por cualquier incidente. Primero, el reglamento debe determinar qué incumplimientos constituyen infracciones, clasificarlos y fijar el máximo aplicable a cada uno. La ley indica que las sanciones tienen por objeto promover el cumplimiento normativo y permite alegar la diligencia debida como defensa en un procedimiento administrativo.

El marco de aplicación contiene, no obstante, medidas contundentes:

• una infracción continuada puede computar como una infracción distinta por cada día;
• los administradores o directivos que hayan ordenado, autorizado, consentido, tolerado o participado en la infracción pueden responder personalmente;
• los organismos reguladores pueden inspeccionar, ordenar auditorías internas y emitir órdenes de cumplimiento; y
• otras disposiciones sobre infracciones penales permiten que los tribunales impongan multas a su discreción y, en determinados casos, penas de prisión a personas físicas.

La lección útil no es «cada incidente cuesta 15 millones de CAD». Es que las pruebas de una preparación razonable, una derivación adecuada, la mitigación y el seguimiento pueden ser importantes. El programa debe funcionar antes de que el organismo regulador lo solicite.

¿Qué deberían hacer los equipos de seguridad antes de que llegue el reglamento?

Prepara las medidas que seguirán siendo útiles aunque cambien los detalles y consulta la Canada Gazette para conocer las reglas definitivas. No adivines qué empresa será designada ni fijes una regla de notificación que aún no existe.

1. Relaciona los servicios esenciales con los sistemas que los sostienen. Parte del servicio del que dependen los clientes e identifica los sistemas cuya pérdida de confidencialidad, integridad o disponibilidad podría interrumpirlo.
2. Designa a un responsable ejecutivo y a otro operativo. El programa de ciberseguridad necesita una persona con capacidad de decisión y otra que pueda coordinar un incidente entre ingeniería, asesoría jurídica, comunicaciones, privacidad y la vía hacia el organismo regulador.
3. Haz inventario de las dependencias de la cadena de suministro. Registra proveedores críticos, subcontratistas, regiones de alojamiento, ubicaciones de datos, contactos para incidentes y criterios que activen la revisión de cambios sustanciales.
4. Crea un manual de clasificación y notificación de incidentes. Mantén configurable el umbral exacto de la CCSPA. Incluye las decisiones relacionadas con el CSE, el futuro regulador sectorial, la privacidad, los contratos, la aseguradora, las fuerzas del orden y las comunicaciones.
5. Realiza un simulacro cronometrado. Comprueba si el equipo puede detectar y clasificar el incidente, conservar las pruebas, autorizar la notificación e informar a la dirección dentro de un período inferior a 72 horas.
6. Conserva una cronología defendible. Registra cuándo ocurrió el evento, cuándo se detectó, quién tomó cada decisión, qué medidas de contención se ejecutaron y cuándo se avisó a terceros.
7. Consulta fuentes primarias. Revisa la página de la CCSPA en Justice Laws y la Canada Gazette para detectar órdenes de entrada en vigor, designaciones en el anexo 2 y reglamentos de aplicación.

La recepción externa de vulnerabilidades debe integrarse en ese trabajo. La CCSPA no exige un programa de divulgación de vulnerabilidades (VDP) ni un archivo security.txt, pero un aviso externo puede ser la primera señal de una debilidad en un sistema crítico. Nuestra guía para crear un programa de divulgación de vulnerabilidades explica el contacto público, el alcance, el puerto seguro (Safe Harbor) y la ruta interna de triaje.

Cómo ayuda Kit a crear un flujo de incidentes defendible

Kit cubre la recepción, la asignación de responsables, la coordinación y la documentación probatoria de los informes de vulnerabilidades. No basta para que una organización cumpla la CCSPA. No vigila redes, no mantiene un inventario de sistemas críticos, no gestiona el riesgo de proveedores ni presenta informes ante el CSE o un organismo regulador.

El módulo de seguridad de Kit ofrece a los investigadores externos un portal con la identidad visual de la organización para presentar informes y publica un archivo security.txt conforme a RFC 9116, para que cada hallazgo llegue a la empresa por un canal definido. Los informes pasan por un triaje estructurado, una evaluación CVSS, la asignación a un responsable, un historial de estados, la comunicación con el investigador y el seguimiento de SLA. Las rotaciones de guardia y la integración con PagerDuty ayudan a poner cada informe urgente en manos de una persona concreta.

Una vez validado el hallazgo, el traspaso a Jira o Linear puede llevar la corrección a la cola de ingeniería sin copiar por defecto detalles confidenciales sobre el exploit. La cronología, los mensajes, el análisis posterior al incidente, las pruebas y el expediente en PDF conservan qué ocurrió y por qué. Consulta los flujos detallados para el triaje de informes de vulnerabilidades y los análisis posteriores al incidente y de sus causas raíz.

El Bill C-8 ha fijado el rumbo legislativo, pero el perímetro operativo de la CCSPA todavía está en construcción. El Bill C-26 ya es historia. La situación actual es más acotada: la ley está promulgada, pero no en vigor; el anexo 2 está vacío; y los reglamentos determinarán los mecanismos exactos de notificación y sanción.

Por tanto, estamos ante una ventana de preparación, no ante una fecha límite de cumplimiento. Crea ahora el inventario, asigna responsables, define la vía de notificación y prepara las pruebas sobre proveedores y la cronología de incidentes. Cuando lleguen las designaciones y los reglamentos, tu equipo debería ajustar un sistema en funcionamiento, no empezar con un documento en blanco.