Bill C-26 przepadł. Czego wymaga kanadyjski Bill C-8

Bill C-26 nie jest już kanadyjskim projektem ustawy o cyberbezpieczeństwie infrastruktury krytycznej. Przepadł wraz z końcem 44. kadencji parlamentu, a jego następca, Bill C-8, uzyskał sankcję królewską 15 czerwca 2026 r. Na jego mocy uchwalono Critical Cyber Systems Protection Act.

W sierpniu 2026 r. ustawa nadal jednak nie obowiązuje, a wykaz klas operatorów, które mają zostać wyznaczone, jest pusty. Obowiązki w zakresie zgodności z przepisami nie mają więc jeszcze zastosowania.

Większość omówień pomija właśnie ten szczegół. Ustawa istnieje, ale ustawowe terminy jeszcze nie biegną. Osoby odpowiedzialne za bezpieczeństwo powinny wykorzystać ten czas na przygotowania i wyraźnie odróżniać uchwalone wymogi od przepisów wykonawczych, które dopiero powstaną, oraz od rozsądnych zabezpieczeń, których sama ustawa nie nakazuje.

Co się stało z Bill C-26?

Bill C-26 nie stał się prawem. Dotarł do ostatnich etapów prac w 44. kadencji parlamentu, po czym wraz z prorogacją parlamentu w styczniu 2025 r. prace nad nim zakończyły się bez uchwalenia. 18 czerwca 2025 r. rząd przedstawił w nowej kadencji bardzo podobny Bill C-8.

Dokumentacja parlamentarna dotycząca Bill C-26 kończy się na rozpatrywaniu poprawek Senatu. W późniejszym rządowym materiale dla komisji dotyczącym Bill C-8 nowy projekt opisano jako niemal identyczny z poprzednim.

Bill C-8 przeszedł pełną drogę ustawodawczą i uzyskał sankcję królewską 15 czerwca 2026 r.

Obecna nazwa prawna ma znaczenie. Bill C-8 jest dziś ustawą opublikowaną jako Statutes of Canada 2026, rozdział 9, pod formalnym tytułem An Act respecting cyber security, amending the Telecommunications Act and making consequential amendments to other Acts.

Na mocy części drugiej uchwalono Critical Cyber Systems Protection Act, zwykle określaną skrótem CCSPA.

Nazwy „Bill C-26” warto używać wyłącznie przy opisywaniu historii lub wyszukiwaniu starszych materiałów. Plany zgodności, materiały dla zarządu i kwestionariusze dla dostawców powinny odnosić się do Bill C-8, a najlepiej do CCSPA.

Czy Bill C-8 już obowiązuje?

Obowiązuje tylko część pakietu. Zmiany w Telecommunications Act przewidziane przez Bill C-8 weszły w życie wraz z sankcją królewską. CCSPA, która ustanawia ramy programu cyberbezpieczeństwa, zgłaszania incydentów, bezpieczeństwa łańcucha dostaw, prowadzenia dokumentacji i egzekwowania przepisów, w aktualnym tekście Justice Laws nadal jest wyraźnie oznaczona jako nieobowiązująca.

W komunikacie Public Safety Canada o sankcji królewskiej zapowiedziano wdrażanie etapami. Ustawa pozwala Governor in Council wyznaczyć w drodze zarządzeń różne daty wejścia w życie poszczególnych przepisów.

Zanim organizacja będzie mogła wyliczyć wiążący termin, potrzebne są jeszcze trzy kroki:

1. Zarządzenia o wejściu w życie muszą wprowadzić w życie odpowiednie przepisy CCSPA.
2. Zarządzenia o wyznaczeniu operatorów muszą dodać klasy operatorów i właściwe organy regulacyjne do Schedule 2.
3. Przepisy wykonawcze muszą określić między innymi rodzaje zgłaszanych incydentów, dokładny termin zgłoszenia, wymogi programu, sposób prowadzenia dokumentacji i właściwe kary administracyjne.

Na 28 sierpnia 2026 r. Schedule 2 pozostaje pusty. Nie przypisano w nim żadnej klasy operatorów do organu regulacyjnego. Ustawa wskazuje zatem usługi o zasadniczym znaczeniu, ale nie wyznacza jeszcze klas przedsiębiorstw, na których spoczywałyby obowiązki operatora.

To nie powód, by ignorować ustawę. Stan obecny trzeba natomiast opisywać precyzyjnie: ustawa została uchwalona, lecz nie obowiązuje i nie wyznaczono jeszcze żadnych klas operatorów.

Kogo obejmie Critical Cyber Systems Protection Act?

CCSPA ma objąć wyznaczonych operatorów krytycznych systemów teleinformatycznych wspierających usługi o zasadniczym znaczeniu, podlegające regulacji federalnej. Nie jest to ogólna ustawa o cyberbezpieczeństwie dla każdej kanadyjskiej firmy ani nawet dla każdego przedsiębiorstwa sprzedającego produkty lub usługi w wymienionych sektorach.

Schedule 1 wymienia obecnie sześć usług i systemów o zasadniczym znaczeniu:

Ustawa definiuje krytyczny system teleinformatyczny jako system, którego naruszenie poufności, integralności lub dostępności mogłoby wpłynąć na ciągłość albo bezpieczeństwo usługi bądź systemu o zasadniczym znaczeniu. To pojęcie węższe niż „ważne IT”.

Platforma pocztowa może być ważna. System sterowania, płatności, trasowania, sygnalizacji lub system sieciowy może być natomiast krytyczny, ponieważ jego utrata może przerwać świadczenie podstawowej usługi.

Governor in Council może dodawać do Schedule 2 klasy operatorów i odpowiadające im organy regulacyjne. Gdy firma znajdzie się w wyznaczonej klasie i będzie właścicielem krytycznego systemu teleinformatycznego albo będzie go kontrolować lub obsługiwać, obowiązki ustawowe zaczną dotyczyć tego systemu.

Dopóki takie zarządzenie nie powstanie, unikaj dwóch częstych uproszczeń:

• Bank, operator telekomunikacyjny, kolej, linia lotnicza, operator rurociągu lub elektrowni jądrowej nie jest dziś automatycznie wyznaczonym operatorem. Lista sektorów i wyznaczenie operatora to dwa odrębne kroki prawne.
• Dostawca chmury lub SaaS nie podlega ustawie automatycznie tylko dlatego, że korzysta z niego przyszły wyznaczony operator. Obowiązki klientów dotyczące łańcucha dostaw mogą przełożyć się na wymogi umowne wobec dostawców, ale nie jest to tym samym co bezpośrednie wyznaczenie na mocy ustawy.

Jakie obowiązki będą mieli wyznaczeni operatorzy?

Po wejściu CCSPA w życie i wyznaczeniu operatora potrzebny będzie stale utrzymywany program cyberbezpieczeństwa, a nie jednorazowy dokument z zasadami. Ustawa łączy nadzór organizacyjny, ochronę techniczną, reagowanie na incydenty, ryzyko stron trzecich, komunikację z organami regulacyjnymi i dokumentację w jeden działający proces.

Ustanowienie i utrzymywanie programu cyberbezpieczeństwa

Artykuły 9 i 10 dają nowo wyznaczonemu operatorowi 90 dni od chwili, gdy stanie się członkiem wyznaczonej klasy, na ustanowienie programu cyberbezpieczeństwa oraz przekazanie go właściwemu organowi regulacyjnemu lub udostępnienie mu programu. Na pisemny wniosek organ może przedłużyć ten termin.

Program musi obejmować działania, które pozwolą:

• identyfikować ryzyko dla cyberbezpieczeństwa organizacji i nim zarządzać, w tym ryzyko związane z łańcuchem dostaw i stronami trzecimi;
• chronić krytyczne systemy teleinformatyczne przed naruszeniem;
• wykrywać incydenty, które wpływają lub mogą wpływać na te systemy;
• ograniczać skutki incydentów.

Operator musi wdrożyć i utrzymywać program. Przeglądy mają odbywać się w terminach określonych w przepisach wykonawczych, a przy ich braku domyślnie w każdą rocznicę ustanowienia programu. Obecny przepis domyślny daje 60 dni na zakończenie przeglądu i kolejne 30 dni na poinformowanie organu regulacyjnego, czy program się zmienił.

Traktowanie zmian w łańcuchu dostaw jak zdarzeń bezpieczeństwa

Artykuł 15 wymaga ograniczenia ryzyka związanego z łańcuchem dostaw lub stroną trzecią natychmiast po jego zidentyfikowaniu. Artykuł 14 nakazuje także zgłaszać istotne zmiany dotyczące własności, kontroli, łańcucha dostaw lub korzystania z produktów i usług stron trzecich. Terminy tych zgłoszeń określą przepisy wykonawcze.

Zarządzanie dostawcami staje się zatem częścią stale działającego programu bezpieczeństwa. Operator krytycznego systemu teleinformatycznego nie może raz w roku odłożyć do akt kwestionariusza dostawcy i uznać ryzyka za zamknięte.

Potrzebuje aktualnego wykazu, wyznaczonych osób odpowiedzialnych, reguł rozpoznawania istotnych zmian oraz procesu, który prowadzi od wykrycia problemu u dostawcy do ponownej oceny ryzyka i decyzji o dalszych działaniach.

Przechowywanie dokumentacji w Kanadzie

Artykuł 30 wymaga dokumentacji obejmującej realizację programu, zgłoszone incydenty, ograniczanie ryzyka w łańcuchu dostaw oraz działania podjęte na mocy poleceń dotyczących cyberbezpieczeństwa. Dokumentację trzeba przechowywać w Kanadzie, w określonym miejscu albo, jeśli nie zostało ono wskazane, w siedzibie operatora. Sposób i okres przechowywania ustali organ regulacyjny lub przyszłe przepisy wykonawcze.

Nie chodzi jedynie o miejsce przechowywania danych. Dokumentacja musi pokazywać, co organizacja rzeczywiście zrobiła.

Sam dokument zasad, bez historii wersji, chronologii incydentu, rejestru decyzji i dowodów usunięcia problemu, będzie trudny do obrony podczas kontroli lub nakazanego audytu wewnętrznego.

Czy termin zgłoszenia incydentu na mocy CCSPA wynosi dokładnie 72 godziny?

Jeszcze nie. Ustawa wyznacza maksymalny przedział na zgłoszenie, a nie ostateczny, powszechnie obowiązujący termin. Sekcja 17 wymaga, aby wyznaczony operator zgłosił incydent cybernetyczny do Communications Security Establishment w okresie określonym w przepisach wykonawczych. Okres ten nie może przekroczyć 72 godzin.

Przepisy wykonawcze muszą jeszcze określić rodzaje incydentów podlegających zgłoszeniu, dokładny termin, formularz i sposób zgłaszania. Stwierdzenie, że każde zdarzenie cybernetyczne trzeba zgłosić dokładnie w ciągu 72 godzin, jest więc nieprawdziwe.

Uchwalona sekwencja działań jest jasna, choć szczegóły pozostają otwarte:

1. Wyznaczony operator rozpoznaje podlegający zgłoszeniu incydent dotyczący jednego z jego krytycznych systemów cybernetycznych.
2. Zgłasza incydent do Communications Security Establishment w wymaganym okresie, nie dłuższym niż 72 godziny.
3. Natychmiast po zgłoszeniu informuje właściwy organ regulacyjny i przekazuje mu kopię.

Ustawowa definicja incydentu jest szeroka. Obejmuje działanie, zaniechanie lub okoliczność, które zakłócają lub mogą zakłócić ciągłość albo bezpieczeństwo usługi o zasadniczym znaczeniu bądź poufność, integralność lub dostępność krytycznego systemu cybernetycznego. Dopiero przepisy wykonawcze rozstrzygną, które zdarzenia mieszczące się w tej szerokiej definicji uruchomią obowiązek zgłoszenia.

Zgłoszenie na mocy CCSPA nie znosi innych obowiązków. Sekcja 18.1 wyraźnie zachowuje stosowanie Personal Information Protection and Electronic Documents Act. Jeden incydent może więc uruchomić odrębne procesy dotyczące cyberbezpieczeństwa, prywatności, umów i regulacji sektorowych.

Najbezpieczniejszym celem przygotowań nie jest „wysłać w 71. godzinie”. Potrzebny jest proces, który pozwoli znacznie wcześniej zaklasyfikować zdarzenie, zaangażować prawników, zabezpieczyć dowody, poinformować kierownictwo oraz przygotować powiadomienia dla CSE i organu regulacyjnego.

Co Bill C-8 oznacza dla dostawców i firm SaaS?

Większość dostawców odczuje skutki Bill C-8 najpierw w wymaganiach klientów, a dopiero później, jeśli w ogóle, wskutek bezpośredniego wyznaczenia. To wniosek wynikający z ustawowych obowiązków dotyczących łańcucha dostaw, a nie osobna reguła ustawowa obejmująca każdego dostawcę.

Wyznaczeni operatorzy będą musieli rozpoznawać i ograniczać ryzyko wynikające z korzystania z produktów i usług stron trzecich, a następnie zgłaszać istotne zmiany organom regulacyjnym. Można więc przewidzieć kilka pytań w procesie zakupowym:

• Które systemy klienta i usługi o zasadniczym znaczeniu zależą od dostawcy?
• Gdzie są przechowywane dane, logi, kopie zapasowe i dokumentacja incydentów?
• Jak szybko dostawca musi powiadomić operatora o podejrzeniu incydentu?
• Którzy podwykonawcy mogą mieć dostęp do usługi?
• Czy operator może uzyskać dowody, wyniki audytu i informacje o usunięciu problemu?
• Co stanowi istotną zmianę produktu, modelu hostingu, własności lub łańcucha dostaw?

Nie należy wymyślać ustawowego terminu dla dostawcy ani obowiązkowego postanowienia umownego. Przepisy wykonawcze nie są gotowe, a operatorzy będą mieć różne potrzeby. Warto już teraz zmapować krytyczne zależności po stronie klientów. Dzięki temu negocjacje umowne zaczną się od rzeczywistej architektury i konkretnych zasad reagowania, a nie od ogólnego załącznika o bezpieczeństwie.

Dostawcy działający także w Europie mogą porównać tę konstrukcję z przewodnikiem po zgłaszaniu na mocy unijnego Cyber Resilience Act. Zakres i przesłanki obu systemów są różne, lecz oba ujawniają tę samą słabość operacyjną: dopiero podczas incydentu okazuje się, że nikt nie odpowiada za przyjęcie zgłoszenia, klasyfikację, powiadomienia i ślad dowodowy.

Jak wysokie są kary na mocy CCSPA?

CCSPA ustanawia wysokie ustawowe limity, lecz system kar administracyjnych nadal wymaga przepisów wykonawczych. Sekcja 91 ogranicza karę ustaloną w tych przepisach do 500 000 CAD dla osoby fizycznej i 15 mln CAD w każdym innym przypadku.

Nie są to automatyczne kary za dowolny incydent. Przepisy wykonawcze muszą najpierw wskazać naruszenia podlegające karze, sklasyfikować je i ustalić właściwy maksymalny wymiar każdej kary. Zgodnie z ustawą kary mają służyć zapewnieniu zgodności z przepisami, a dochowanie należytej staranności może stanowić obronę w postępowaniu administracyjnym.

Mechanizmy egzekwowania przepisów pozostają surowe:

• trwające naruszenie może być liczone jako odrębne naruszenie za każdy dzień;
• dyrektorzy lub członkowie władz, którzy nakazali naruszenie, zatwierdzili je, zgodzili się na nie, przyzwolili na nie lub w nim uczestniczyli, mogą odpowiadać osobiście;
• organy regulacyjne mogą przeprowadzać kontrole, nakazywać audyty wewnętrzne i wydawać nakazy zapewnienia zgodności;
• odrębne przepisy o czynach zabronionych pozwalają sądowi ustalać wysokość grzywny, a w określonych przypadkach przewidują karę pozbawienia wolności dla osób fizycznych.

Nie należy wyciągać z tego wniosku, że „każde naruszenie kosztuje 15 mln CAD”. Znaczenie mogą mieć dowody rozsądnego przygotowania, właściwej eskalacji, ograniczania szkód i doprowadzania spraw do końca. Program musi działać, zanim poprosi o niego organ regulacyjny.

Co zespoły bezpieczeństwa powinny zrobić przed wydaniem przepisów wykonawczych?

Warto przygotować elementy, które niemal na pewno się przydadzą, i jednocześnie śledzić Canada Gazette w poszukiwaniu szczegółów prawnych. Nie należy zgadywać, która firma zostanie wyznaczona, ani utrwalać zasad zgłaszania, które jeszcze nie powstały.

1. Powiąż usługi o zasadniczym znaczeniu ze wspierającymi je systemami. Zacznij od usługi, na której polegają klienci, a potem wskaż systemy, których utrata poufności, integralności lub dostępności mogłaby przerwać jej świadczenie.
2. Wyznacz osobę odpowiedzialną na szczeblu kierowniczym i właściciela operacyjnego. Program cyberbezpieczeństwa potrzebuje decydenta oraz osoby, która przeprowadzi incydent przez działania zespołów inżynieryjnych, prawnych, komunikacji i prywatności aż do kontaktu z organem regulacyjnym.
3. Sporządź wykaz zależności w łańcuchu dostaw. Zapisz krytycznych dostawców, podwykonawców, regiony hostingu, lokalizacje danych, kontakty do zgłaszania incydentów i przesłanki istotnej zmiany.
4. Przygotuj procedurę klasyfikacji incydentów i powiadamiania. Dokładny próg CCSPA pozostaw konfigurowalny. Uwzględnij decyzje dotyczące CSE, przyszłego organu sektorowego, prywatności, umów, ubezpieczyciela, organów ścigania i komunikacji.
5. Przeprowadź ćwiczenie z pomiarem czasu. Sprawdź, czy zespół potrafi wykryć i zaklasyfikować zdarzenie, zabezpieczyć dowody, zatwierdzić zgłoszenie oraz poinformować kierownictwo w czasie krótszym niż 72 godziny.
6. Zachowaj chronologię, którą da się obronić. Zapisuj, kiedy doszło do zdarzenia i kiedy je wykryto, kto podjął poszczególne decyzje, jakie działania ograniczające wykonano oraz kiedy powiadomiono strony trzecie.
7. Śledź źródła pierwotne. Monitoruj stronę CCSPA w Justice Laws oraz Canada Gazette pod kątem rozporządzeń o wejściu w życie, wyznaczeń w Schedule 2 i przepisów wykonawczych.

Przyjmowanie zewnętrznych zgłoszeń o podatnościach powinno być częścią tych działań. CCSPA nie wymaga programu ujawniania podatności (VDP) ani pliku security.txt, ale zewnętrzne zgłoszenie może być pierwszym sygnałem słabości w systemie krytycznym. Nasz przewodnik po tworzeniu programu ujawniania podatności omawia publiczny kanał kontaktu, zakres, safe harbor oraz wewnętrzną ścieżkę triażu.

Jak Kit wspiera możliwy do obrony proces obsługi incydentu

Kit wspiera przyjmowanie zgłoszeń o podatnościach, przypisywanie odpowiedzialności, koordynację i gromadzenie dowodów. Nie zapewnia organizacji zgodności z CCSPA. Nie monitoruje sieci, nie tworzy wykazu systemów krytycznych, nie zarządza ryzykiem dostawców i nie składa zgłoszeń do CSE ani organu regulacyjnego.

Moduł bezpieczeństwa Kit udostępnia zewnętrznym badaczom portal do zgłoszeń spójny z identyfikacją wizualną organizacji i publikuje plik security.txt zgodny z RFC 9116. Informacja o podatności trafia więc do firmy właściwym kanałem. Zgłoszenia przechodzą przez ustrukturyzowany triaż, ocenę CVSS, przypisanie, historię statusów, komunikację z badaczem i śledzenie SLA. Rotacje dyżurów i integracja z PagerDuty pomagają szybko wskazać osobę odpowiedzialną za pilne zgłoszenie.

Po potwierdzeniu podatności integracja z Jira lub Linear pozwala przekazać usunięcie problemu do kolejki zespołu inżynieryjnego bez domyślnego kopiowania wrażliwych szczegółów wykorzystania luki. Oś czasu zgłoszenia, wiadomości, postmortem, dowody i dossier zachowują informacje o tym, co się wydarzyło i dlaczego. Szczegółowe procesy opisują instrukcje triażu zgłoszeń o podatnościach oraz postmortem i analizy przyczyn źródłowych.

Bill C-8 wyznaczył kierunek ustawodawstwa, lecz zakres operacyjny CCSPA nadal powstaje. Bill C-26 to już historia. Obecny stan jest bardziej precyzyjny: ustawa została uchwalona, ale nie obowiązuje; wykaz Schedule 2 jest pusty; a dokładne zasady zgłaszania i wymierzania kar określą przepisy wykonawcze.

To czas na przygotowania, nie termin osiągnięcia zgodności. Już teraz opracuj wykaz systemów, przypisz odpowiedzialność, przygotuj ścieżkę powiadamiania, zbierz dowody dotyczące dostawców i zadbaj o chronologię incydentów. Gdy pojawią się wyznaczenia operatorów i przepisy wykonawcze, zespół powinien dostosować działający system, a nie zaczynać od pustego dokumentu.