Powrót do aktualności

Krajowy system cyberbezpieczeństwa: jak pracować na aktualnym tekście ustawy i nie zgubić obowiązków

Autor: AnyLawyer AI

Opieka merytoryczna serwisu: Michał Jackowski (profesor AI i prawa)

Opublikowano: Źródła zweryfikowano:

Ogłoszenie tekstu jednolitego ustawy o krajowym systemie cyberbezpieczeństwa porządkuje punkt odniesienia dla podmiotów, które muszą utrzymywać odporność swoich systemów i sprawnie reagować na zdarzenia bezpieczeństwa. To dobry moment, by nie tylko pobrać aktualny tekst, lecz także sprawdzić, czy firmowe procedury, role, rejestry i dokumentacja rzeczywiście odpowiadają modelowi przewidzianemu w ustawie.

Kontekst: tekst jednolity nie tworzy nowej ustawy, ale porządkuje obowiązujący stan

Obwieszczenie Marszałka Sejmu z 29 grudnia 2025 r. ogłasza jednolity tekst ustawy z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (KSC). Tekst jednolity jest urzędowo uporządkowaną wersją ustawy: pozwala czytać regulację wraz ze zmianami uwzględnionymi w jednym dokumencie, zamiast składać jej treść z aktu pierwotnego i kolejnych nowelizacji.

Sam dokument wskazuje, że opracowano go na podstawie tekstu jednolitego ogłoszonego w Dz.U. z 2026 r. poz. 20 oraz zmian opublikowanych pod pozycjami 252, 815 i 1003. W praktyce dla działu prawnego, bezpieczeństwa informacji i compliance (systemu zapewniania zgodności z prawem i procedurami) oznacza to prostą zasadę: w bieżącej pracy należy odwoływać się do tekstu jednolitego, a nie opierać procedur wyłącznie na historycznym tekście ustawy z 2018 r.

Ustawa ma przy tym europejski kontekst. Jej przypis wskazuje, że wdraża dyrektywę NIS 2, czyli dyrektywę UE 2022/2555 dotyczącą wysokiego wspólnego poziomu cyberbezpieczeństwa na terytorium Unii. Służy też częściowemu stosowaniu unijnego rozporządzenia dotyczącego sektorowych aspektów cyberbezpieczeństwa w transgranicznych przepływach energii elektrycznej.

Co dokładnie reguluje ustawa

Zakres regulacji wyznacza art. 1 ust. 1 ustawy o KSC. Nie jest to zatem wyłącznie ustawa o zabezpieczeniach technicznych, takich jak hasła, kopie zapasowe czy aktualizacje oprogramowania. Obejmuje organizację całego systemu, obowiązki jego uczestników, nadzór i kontrolę, a także dokumenty strategiczne państwa.

W art. 1 ust. 1 ustawodawca wskazuje wprost:

„Ustawa określa:

  1. organizację krajowego systemu cyberbezpieczeństwa oraz zadania i obowiązki podmiotów wchodzących w skład tego systemu;
  2. sposób sprawowania nadzoru i kontroli w zakresie stosowania przepisów ustawy;”

art. 1 ust. 1 pkt 1–2 ustawy o krajowym systemie cyberbezpieczeństwa

To ważne z dwóch powodów. Po pierwsze, obowiązki trzeba czytać razem z mechanizmem kontroli — dokumentacja ma służyć nie tylko wewnętrznemu porządkowi, ale również wykazaniu, jak organizacja realizuje swoje zadania. Po drugie, KSC obejmuje także Strategię Cyberbezpieczeństwa Rzeczypospolitej Polskiej oraz Krajowy plan reagowania na incydenty i sytuacje kryzysowe w cyberbezpieczeństwie na dużą skalę.

Art. 1 ust. 2 wymienia ograniczone wyłączenie: ustawy nie stosuje się do podmiotów wykonujących działalność leczniczą, tworzonych przez Szefa Agencji Bezpieczeństwa Wewnętrznego albo Szefa Agencji Wywiadu. Nie należy jednak z tego wyciągać wniosku, że działalność lecznicza jako taka pozostaje poza systemem. W orzecznictwie wskazano na znaczenie sektora zdrowotnego, w tym świadczeniodawców mających w strukturze szpitalny oddział ratunkowy, centrum urazowe lub centrum urazowe dla dzieci.

Cel systemu opisuje art. 3 ustawy, przywołany przez Wojewódzki Sąd Administracyjny w Szczecinie:

„krajowy system cyberbezpieczeństwa ma na celu zapewnienie cyberbezpieczeństwa na poziomie krajowym, w tym niezakłóconego świadczenia usług kluczowych i usług cyfrowych, przez osiągnięcie odpowiedniego poziomu bezpieczeństwa systemów informacyjnych służących do świadczenia tych usług oraz zapewnienie obsługi incydentów.”

wyrok WSA w Szczecinie, I SAB/Sz 190/24

Prostym językiem: punktem ciężkości jest ciągłość i bezpieczeństwo usług opartych na systemach informacyjnych oraz zdolność do obsługi incydentów. „Systemy informacyjne” to nie tylko serwery w firmowej serwerowni, ale narzędzia, dane i usługi, od których zależy świadczenie danej usługi.

Kto powinien zweryfikować procedury

Pierwszym krokiem nie jest kupno kolejnego narzędzia bezpieczeństwa, lecz ustalenie, czy organizacja wchodzi w zakres systemu i w jakiej roli. Art. 1 mówi o „podmiotach wchodzących w skład” KSC, a aktualny art. 2 zawiera rozbudowany słownik pojęć, który pomaga identyfikować działalności cyfrowe.

Na szczególną uwagę zasługują podmioty świadczące usługi cyfrowe lub wspierające ich dostępność. Ustawa definiuje m.in. dostawcę sieci dostarczania treści, dostawcę internetowej platformy handlowej oraz dostawcę chmury obliczeniowej. Ten ostatni to podmiot świadczący usługę dającą dostęp do „skalowalnego i elastycznego zbioru zasobów obliczeniowych” wspólnie wykorzystywanych przez wielu użytkowników.

Weryfikacja powinna objąć również dostawców sprzętu lub oprogramowania. Ustawa zalicza do tej kategorii producenta, upoważnionego przedstawiciela, importera lub dystrybutora produktu ICT, usługi ICT albo procesu ICT. ICT oznacza technologie informacyjno-komunikacyjne — sprzęt, oprogramowanie i usługi służące przetwarzaniu lub przekazywaniu informacji.

Nie wolno ograniczać analizy do nazwy branży czy kodu działalności. Trzeba ustalić faktyczny model usługi, systemy wykorzystywane do jej realizacji, zależności od dostawców oraz skutki ich niedostępności. Dopiero potem można przypisać odpowiedzialności i procedury.

Jak to działa w praktyce: spółka korzystająca z chmury, zewnętrznego systemu sprzedaży i dostawcy sieci dostarczania treści powinna ustalić, które systemy podtrzymują jej usługę oraz kto może wykryć, zakwalifikować i obsłużyć zakłócenie — spółka, dostawca czy obie strony.

Zarządzanie ryzykiem i obsługa incydentów: procedura musi dać się wykonać i udowodnić

Ustawa ujmuje bezpieczeństwo systemów informacyjnych jako ich odporność na zdarzenia naruszające poufność, integralność, dostępność i autentyczność danych lub usług. Poufność oznacza ochronę przed dostępem nieuprawnionych osób; integralność — że dane są poprawne i kompletne; dostępność — że uprawniony użytkownik może z nich skorzystać; autentyczność — że można potwierdzić pochodzenie informacji lub tożsamość podmiotu.

W aktualnym tekście funkcjonują krajowe zespoły reagowania: CSIRT GOV, prowadzony przez Szefa ABW, CSIRT MON, prowadzony przez Ministra Obrony Narodowej, oraz CSIRT NASK, prowadzony przez NASK. CSIRT to zespół reagowania na incydenty bezpieczeństwa komputerowego. Ustawa zna także CSIRT sektorowy, działający dla określonego sektora lub podsektora.

Praktyczna procedura zarządzania ryzykiem powinna więc odpowiadać na cztery pytania: jakie systemy wspierają usługę, co może zagrozić ich poufności, integralności, dostępności lub autentyczności, kto podejmuje decyzje oraz jak organizacja dokumentuje wynik oceny i działania naprawcze. Z kolei procedura incydentowa musi rozróżniać zwykłe zdarzenie od zdarzeń o poważniejszych konsekwencjach dla świadczenia usługi.

Orzecznictwo przywołuje ustawowe rozróżnienie m.in. incydentu krytycznego, poważnego i istotnego. Incydent poważny to taki, który powoduje lub może spowodować poważne obniżenie jakości albo przerwanie ciągłości świadczenia usługi kluczowej. Incydent krytyczny wiąże się ze znaczną szkodą dla bezpieczeństwa lub porządku publicznego, interesów gospodarczych, działania instytucji publicznych, praw i wolności obywatelskich albo życia i zdrowia ludzi.

Na co uważać przy aktualizacji dokumentacji compliance

Największym błędem jest stworzenie dokumentacji, która opisuje idealny proces, ale nie odzwierciedla realnego działania organizacji. W decyzji dotyczącej szpitala Prezes UODO zwrócił uwagę, że sam incydent nie przesądza jeszcze o naruszeniu przepisów. Kluczowa jest jednak zdolność podmiotu do wykazania, jakie środki stosował i jak nimi zarządzał.

„W toku postępowania Szpital powinien był natomiast wykazać Prezesowi UODO, że – pomimo zaistnienia incydentu – przestrzegał zasad dotyczących przetwarzania danych osobowych oraz zrealizował obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych w celu ochrony takich danych przy przetwarzaniu.”

decyzja Prezesa UODO, DKN.5131.48.2022

Chociaż sprawa dotyczyła ochrony danych osobowych, jej praktyczna lekcja dla cyberbezpieczeństwa jest uniwersalna: działania prowadzone bez uporządkowanej procedury i bez dowodów wykonania są bardzo trudne do obrony. Prezes UODO zakwestionował w szczególności brak dokumentowania przeglądów i płynących z nich wniosków.

„Ponadto brak jakiegokolwiek dokumentowania przeprowadzanych przeglądów, w tym w szczególności płynących z nich wniosków, nie tylko pozostaje w sprzeczności z zasadą rozliczalności, o której mowa w art. 5 ust. 2 rozporządzenia 2016/679, ale także wyklucza przejrzystość dokonywanych w tym zakresie działań oraz możliwość sprawowania przez Szpital faktycznej kontroli nad procesem wdrażania rekomendacji sformułowanych w rezultacie przeprowadzonych testów.”

decyzja Prezesa UODO, DKN.5131.48.2022, pkt 91

Dokumentacja KSC nie zastępuje automatycznie dokumentacji ochrony danych. Organ wyraźnie zaznaczył, że audyt zgodności z ustawą o KSC koncentruje się na bezpiecznym i niezakłóconym świadczeniu usług, a nie na ochronie praw i wolności osób fizycznych, która jest osią RODO. Jeśli więc incydent dotyczy jednocześnie usługi i danych osobowych, potrzebna jest skoordynowana, ale odrębna analiza obu reżimów.

Co to oznacza w praktyce

  1. Pracuj na tekście jednolitym. Zaktualizuj odwołania w politykach, procedurach i umowach do tekstu jednolitego ustawy o KSC.

  2. Zrób mapę usług i systemów. Ustal, które systemy, dostawcy chmury, platformy lub usługi dostarczania treści są potrzebne do niezakłóconego świadczenia usługi.

  3. Przypisz role w incydencie. Procedura powinna wskazywać osoby odpowiedzialne za wykrycie, ocenę wpływu, decyzję operacyjną, kontakt z właściwym CSIRT i dokumentowanie działań.

  4. Zamień deklaracje w dowody. Zachowuj wyniki testów, przeglądów, ocen ryzyka, decyzje o działaniach naprawczych oraz potwierdzenia ich wykonania.

  5. Nie mieszaj KSC z RODO. Bezpieczeństwo usługi i ochrona danych osobowych często dotyczą tego samego zdarzenia, ale są odrębnymi obszarami oceny i wymagają odrębnej dokumentacji.

Źródła