Jeżeli rozdział 3 znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20 t.j., zmiana Dz.U. 2026 poz. 252) ma swoje serce, to znajduje się ono w art. 8. Przepis ten transponuje do polskiego prawa art. 21 dyrektywy 2022/2555 (NIS2), który wymaga od państw członkowskich nałożenia na podmioty kluczowe i ważne obowiązku wdrożenia odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych. To w nim zawarty jest katalog 14 obszarów, w których podmiot kluczowy lub ważny musi wdrożyć odpowiednie i proporcjonalne do oszacowanego ryzyka środki techniczne i organizacyjne. Te 14 liter — od (a) do (n) — to praktyczna mapa tego, co organ nadzorczy będzie sprawdzał w trakcie audytu i co powinno znaleźć się w dokumentacji systemu zarządzania bezpieczeństwem informacji z art. 10 KSC. W tym wpisie omawiamy każdy z tych obszarów — z odniesieniem do tekstu przepisu i wskazówkami praktycznymi.

Trzy poziomy obowiązku z art. 8 ust. 1 KSC

Zanim przejdziemy do 14 obszarów, warto przypomnieć, że art. 8 ust. 1 KSC zawiera pięć rodzajów wymogów:

  • Pkt 1 — prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem;
  • Pkt 2 — wdrożenie 14 środków technicznych i organizacyjnych (lit. a–n) — sercem przepisu;
  • Pkt 3 — zbieranie informacji o cyberzagrożeniach i podatnościach;
  • Pkt 4 — zarządzanie incydentami;
  • Pkt 5 — stosowanie środków zapobiegających i ograniczających wpływ incydentów (lit. a–d).

Skupiamy się tu na pkt 2 — to on jest zarówno najbardziej rozbudowany merytorycznie, jak i najczęściej przedmiotem czynności nadzorczych.

Art. 8 ust. 1 pkt 2 KSC wprost wymaga, aby środki były „odpowiednie i proporcjonalne do oszacowanego ryzyka". Sześć kryteriów doboru:

  • najnowszy stan wiedzy;
  • koszty wdrożenia;
  • wielkość podmiotu;
  • prawdopodobieństwo wystąpienia incydentów;
  • narażenie podmiotu na ryzyka;
  • skutki społeczne i gospodarcze.

To istotny detal — KSC nie wymaga „najwyższego" poziomu zabezpieczeń, tylko odpowiednich i proporcjonalnych. Oznacza to, że standard „dla mikro" będzie inny niż „dla podmiotu kluczowego z 5000 pracowników". Ale każdy podmiot musi być w stanie udokumentować, jak doszedł do wybranego poziomu — to dowód podczas kontroli z art. 53 ust. 2 pkt 1 KSC.

Lit. (a) — polityki szacowania ryzyka oraz bezpieczeństwa systemu informacyjnego

Pierwszy obszar to polityki. Nie jedna polityka, nie ogólna „polityka bezpieczeństwa", ale system polityk: główna polityka SZBI plus polityki tematyczne (kontroli dostępu, kryptografii, zarządzania incydentami, łańcucha dostaw itp.). Konstrukcja „polityka + polityki tematyczne" odpowiada wprost katalogowi z art. 21 ust. 2 lit. a dyrektywy NIS2.

Z naszego doświadczenia dokumentacja, która spełnia wymóg art. 8 ust. 1 pkt 2 lit. a KSC, ma trzy poziomy:

  • Polityka główna — zatwierdzona przez kierownika podmiotu, wyznacza cele, ramy organizacyjne, role i odpowiedzialności;
  • Polityki tematyczne — szczegółowe regulacje dla konkretnych obszarów (np. polityka MFA, polityka backupu, polityka łańcucha dostaw);
  • Procedury operacyjne — instrukcje wykonawcze dla zespołu IT, opisujące „jak konkretnie".

Dokument musi być żywy — przeglądany regularnie (rekomendujemy co najmniej raz w roku), aktualizowany po incydentach poważnych, dostępny dla osób upoważnionych zgodnie z art. 10 ust. 6 pkt 1 KSC.

Lit. (b) — bezpieczeństwo w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego

Drugi obszar to bezpieczeństwo cyklu życia systemu (Secure SDLC, Software Development Life Cycle). Dotyczy całego procesu od nabywania (wymagania bezpieczeństwa w zamówieniach), przez rozwój (przegląd kodu, testy bezpieczeństwa, threat modelling), utrzymanie (patch management, change management) i eksploatację (monitoring, logi).

W praktyce w sektorze IT i finansowym standardem są: testy penetracyjne przed produkcyjnym wdrożeniem, regularny code review pod kątem podatności, automatyzowane skanowanie zależności, separacja środowisk DEV/STAGE/PROD. W mniejszych organizacjach — minimum to procedura zatwierdzania zmian w systemach krytycznych z udziałem osoby odpowiedzialnej za bezpieczeństwo.

Lit. (c) — bezpieczeństwo fizyczne i środowiskowe uwzględniające kontrole dostępu

Trzeci obszar to bezpieczeństwo „warstwy zerowej" — pomieszczeń serwerowni, biur, miejsc pracy. Kontrola dostępu obejmuje fizyczny dostęp do serwerowni (karty, biometria, dziennik wejść), zabezpieczenia środowiskowe (klimatyzacja, monitoring temperatury, gaszenie pożarowe, UPS-y) oraz polityki czystego biurka i blokowania stacji roboczych.

W praktyce w przypadku korzystania z usług data center (collocation, IaaS) część odpowiedzialności przechodzi na dostawcę — co musi być uregulowane w umowie zgodnie z art. 8 ust. 1 pkt 2 lit. e KSC (łańcuch dostaw, omawiany niżej).

Lit. (d) — bezpieczeństwo zasobów ludzkich

Czwarty obszar to HR security — proces onboardingu (umowy o poufności, formalne pełnomocnictwa do dostępów), w trakcie zatrudnienia (oceny okresowe, szkolenia, zarządzanie zmianami stanowisk) i offboardingu (cofnięcie dostępów, zwrot sprzętu, odebranie kart).

Należy tu też wpiąć obowiązek z art. 8f KSC — wymóg KRK przed dopuszczeniem do zadań cybersec — oraz procedurę cyklicznych szkoleń dla pracowników (art. 8 ust. 1 pkt 2 lit. i, omawiana poniżej). W praktyce HR security to obszar często zaniedbywany, dopóki nie wystąpi incydent związany z byłym pracownikiem (insider threat).

Lit. (e) — bezpieczeństwo i ciągłość łańcucha dostaw produktów ICT

Piąty obszar to łańcuch dostaw. To jeden z najtrudniejszych operacyjnie wymogów, bo zmusza podmiot do oceny i zarządzania ryzykiem nie tylko własnym, ale także swoich dostawców.

Art. 8 ust. 2 KSC wprost wskazuje, że wdrażając środki dotyczące łańcucha dostaw, podmiot uwzględnia:

  • podatności związane z dostawcą sprzętu lub oprogramowania;
  • ogólną jakość produktów ICT, usług ICT i procesów ICT pochodzących od dostawcy;
  • wyniki skoordynowanej oceny bezpieczeństwa przeprowadzonej przez Grupę Współpracy NIS2 (art. 22 ust. 1 dyrektywy 2022/2555);
  • wyniki postępowania w sprawie uznania za dostawcę wysokiego ryzyka (art. 67b KSC).

W praktyce oznacza to, że dla każdego krytycznego dostawcy ICT podmiot powinien mieć: ocenę ryzyka, klauzule kontraktowe (z prawem do audytu, raportowaniem incydentów, klauzulą exit), monitoring stanu bezpieczeństwa dostawcy w czasie i procedurę reakcji na incydent po stronie dostawcy. Dla podmiotów finansowych ten obszar dodatkowo nakłada się na art. 28–30 DORA i ramy zarządzania ryzykiem, do których wracamy w wpisie o art. 8i KSC i sektorze finansowym.

Lit. (f) — plany ciągłości działania, plany awaryjne, plany odtworzenia działalności

Szósty obszar to BCP/DRP (Business Continuity Planning / Disaster Recovery Planning). Art. 8 ust. 1 pkt 2 lit. f KSC wymaga wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności.

Plany muszą zapewniać poufność, integralność, dostępność i autentyczność informacji, a także umożliwiać odtworzenie systemu informacyjnego po zdarzeniu, które spowodowało straty przekraczające zdolności podmiotu do odbudowy za pomocą własnych środków.

W praktyce każdy podmiot powinien mieć:

  • udokumentowany BCP z wyznaczonym RTO (Recovery Time Objective) i RPO (Recovery Point Objective) dla każdego krytycznego procesu;
  • procedury odtwarzania (DRP) dla kluczowych systemów;
  • regularne testy odtworzenia (rekomendujemy: pełny test co najmniej raz w roku, częściowe testy częściej);
  • strategię backupu zgodną z modelem 3-2-1 (3 kopie, na 2 różnych nośnikach, 1 poza lokalizacją).

Lit. (g) — monitorowanie systemu informacyjnego w trybie ciągłym

Siódmy obszar to monitoring. Wprost: „objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi systemem monitorowania w trybie ciągłym."

Ustawa nie narzuca konkretnej technologii — w szczególności nie wymaga wprost SIEM. Ale w praktyce dla podmiotów kluczowych standardem branżowym jest:

  • centralna agregacja logów z systemów krytycznych (SIEM, ELK, Splunk lub rozwiązanie zarządzane);
  • definicja zdarzeń bezpieczeństwa wymagających eskalacji;
  • alerting do zespołu SOC lub MSSP w trybie 24/7;
  • regularna analiza fałszywie dodatnich i fałszywie ujemnych alertów.

Dla mniejszych podmiotów ważnych dopuszczalne mogą być rozwiązania prostsze (np. centralizacja logów bez automatycznej korelacji), ale nadal muszą zapewniać „tryb ciągły" w rozumieniu art. 8 ust. 1 pkt 2 lit. g KSC.

Lit. (h) — polityki i procedury oceny skuteczności środków technicznych i organizacyjnych

Ósmy obszar to ocena skuteczności. Wymaga, aby podmiot miał formalny mechanizm sprawdzania, czy zastosowane środki rzeczywiście działają — przez pomiary, testy, audyty wewnętrzne, przeglądy.

W praktyce to obszar często łączony z testami penetracyjnymi, vulnerability scanningiem oraz testami kontrolnymi (np. tabletop exercises dla planów ciągłości). Wynik oceny skuteczności staje się danymi wejściowymi do kolejnego cyklu szacowania ryzyka z art. 8 ust. 1 pkt 1 KSC.

Lit. (i) — edukacja z zakresu cyberbezpieczeństwa dla personelu podmiotu

Dziewiąty obszar to szkolenia personelu (odróżniane od corocznego szkolenia zarządu z art. 8e). Obejmuje program awareness dla wszystkich pracowników oraz dedykowane szkolenia dla osób na stanowiskach wymagających specjalistycznej wiedzy (administratorzy, deweloperzy, security officerzy).

W praktyce standard rynkowy to:

  • coroczny program awareness z modułami o phishingu, hasłach, rozpoznawaniu malware i procedurze zgłaszania podejrzanych aktywności;
  • symulacje phishingu (regularne kampanie testowe z analizą wyników);
  • szkolenia stanowiskowe — przy rozpoczęciu pracy, przy zmianie stanowiska, po incydencie.

Lit. (j) — podstawowe zasady cyberhigieny

Dziesiąty obszar to cyberhigiena. To pojęcie obejmuje podstawowe praktyki bezpieczeństwa: silne hasła i MFA, polityka czystego biurka i ekranu, zasada najmniejszych uprawnień, regularne aktualizacje, antywirus / EDR, zarządzanie urządzeniami przenośnymi (BYOD, USB), bezpieczna poczta (SPF/DKIM/DMARC, filtrowanie załączników), bezpieczne korzystanie z internetu, kopie zapasowe.

Co warto zaznaczyć — cyberhigiena ma szczególną pozycję dla sektora bankowości i infrastruktury rynków finansowych. Art. 8i ust. 1 KSC wyłącza dla tego sektora większość przepisów art. 8, z wyjątkiem m.in. art. 8 ust. 1 pkt 2 lit. j. Innymi słowy — nawet podmiot finansowy stosujący w pełni DORA musi przestrzegać podstawowych zasad cyberhigieny zgodnie z KSC. To temat, do którego wracamy w wpisie o art. 8i i lex specialis dla sektora finansowego.

Lit. (k) — polityki i procedury stosowania kryptografii, w tym szyfrowania

Jedenasty obszar to kryptografia. Wymaga formalnych polityk i procedur w obszarze szyfrowania danych w transmisji (TLS, VPN), w spoczynku (szyfrowanie dysków, baz danych), zarządzania kluczami (generowanie, dystrybucja, rotacja, niszczenie kluczy) oraz wyboru algorytmów (zgodnie ze stanem wiedzy — co implikuje stopniową migrację z algorytmów uznawanych za przestarzałe).

W praktyce minimum to:

  • TLS 1.2+ na wszystkich kanałach komunikacji wewnętrznej i zewnętrznej;
  • szyfrowanie laptopów (BitLocker, FileVault) i nośników wymiennych;
  • szyfrowanie baz danych zawierających dane wrażliwe lub objęte tajemnicą zawodową;
  • udokumentowana procedura zarządzania kluczami (KMS lub procedura ręczna, ale formalna).

Lit. (l) — bezpieczne środki komunikacji elektronicznej, uwzględniające MFA w stosownych przypadkach

Dwunasty obszar to bezpieczna komunikacja elektroniczna w ramach krajowego systemu cyberbezpieczeństwa oraz wewnątrz podmiotu. Obejmuje narzędzia komunikacji służbowej (e-mail, komunikatory, portale klienckie) z naciskiem na MFA tam, gdzie ryzyko tego wymaga.

W praktyce — MFA powinno być standardem dla wszystkich kont uprzywilejowanych (administracyjne, dostęp do systemów krytycznych, dostęp z poza sieci firmowej), a co najmniej rekomendowane dla wszystkich kont z dostępem do danych wrażliwych. Dla komunikacji z organem właściwym i CSIRT — przez system S46 z art. 46 ust. 1 KSC.

Lit. (m) — zarządzanie aktywami

Trzynasty obszar to inwentaryzacja i zarządzanie aktywami ICT. Każdy podmiot musi wiedzieć, jakie systemy, serwery, aplikacje, bazy danych, urządzenia mobilne i komponenty sieciowe posiada — i w jakim są stanie.

Ustawa nie wymaga konkretnej technologii (CMDB, dedykowane narzędzie ITAM, Excel — w mniejszych podmiotach), ale wymaga, aby rejestr był aktualny, kompletny i zawierał klasyfikację aktywów (np. krytyczne / ważne / standardowe). To dane wejściowe do szacowania ryzyka z art. 8 ust. 1 pkt 1 KSC i do procesu zarządzania podatnościami.

Lit. (n) — polityki kontroli dostępu

Czternasty obszar to kontrola dostępu (Identity and Access Management, IAM). Obejmuje wszystkie elementy zarządzania tożsamościami i uprawnieniami:

  • proces nadawania uprawnień (z zatwierdzeniem przez właściciela systemu);
  • zasada najmniejszych uprawnień (least privilege);
  • regularne przeglądy uprawnień (rekomendowane: co najmniej raz w roku, dla kont uprzywilejowanych — częściej);
  • odebranie uprawnień przy offboardingu lub zmianie stanowiska;
  • monitoring i logowanie wszystkich operacji uprzywilejowanych;
  • zarządzanie tożsamościami zewnętrznych użytkowników (kontrahenci, dostawcy).

W praktyce IAM to obszar, który najczęściej generuje zarówno największe ryzyka (incydenty związane z nadmiernymi uprawnieniami, niewycofanymi dostępami), jak i największe wartości operacyjne — dobrze zorganizowany IAM jest fundamentem skutecznego cybersec.

Pięć środków zapobiegających i ograniczających — art. 8 ust. 1 pkt 5 KSC

Oprócz 14 obszarów z lit. a–n, art. 8 ust. 1 pkt 5 KSC nakłada dodatkowy obowiązek stosowania środków zapobiegających i ograniczających wpływ incydentów na bezpieczeństwo systemu informacyjnego, w tym:

  • (a) stosowanie mechanizmów zapewniających poufność, integralność, dostępność i autentyczność danych przetwarzanych w systemie informacyjnym;
  • (b) regularne aktualizacje oprogramowania, stosowne do zaleceń producenta, z uwzględnieniem analizy wpływu aktualizacji na bezpieczeństwo świadczonej usługi;
  • (c) ochrona przed nieuprawnioną modyfikacją w systemie informacyjnym;
  • (d) niezwłoczne podejmowanie działań po dostrzeżeniu podatności lub cyberzagrożeń, w tym czasowe ograniczenie ruchu sieciowego przychodzącego do infrastruktury, jeżeli takie ograniczenie jest niezbędne (z uwzględnieniem konieczności minimalizacji skutków ograniczenia dostępności).

Mapowanie KSC na DORA dla podmiotów finansowych

Dla podmiotów objętych zarówno KSC, jak i rozporządzeniem 2022/2554 (DORA) — w szczególności podmiotów finansowych z definicji art. 2 pkt 11a KSC — ustawodawca przewiduje w art. 8i ust. 1 KSC, że do podmiotów z sektora bankowości i infrastruktury rynków finansowych nie stosuje się przepisów ustawy dotyczących systemu zarządzania bezpieczeństwem informacji lub zgłaszania poważnych incydentów, z wyjątkiem konkretnych przepisów wymienionych w tym artykule.

Wyjątki obejmują m.in. art. 8 ust. 1 pkt 1 (szacowanie ryzyka) i art. 8 ust. 1 pkt 2 lit. j (cyberhigiena) — pozostałe 13 obszarów (lit. a–i oraz k–n) jest dla sektora finansowego pokryte przez DORA art. 5–14. Praktyczne mapowanie i konsekwencje omawiamy w odrębnym wpisie naszego cyklu o art. 8i KSC.

Dla podmiotów spoza sektora finansowego — wszystkie 14 obszarów art. 8 KSC obowiązuje wprost i bez wyłączeń, zgodnie z modelem „minimum harmonizacji" wynikającym z art. 21 dyrektywy NIS2.

Co konkretnie musisz mieć na dzień kontroli?

W praktyce wdrożeniowej widzimy, że pełna implementacja art. 8 KSC dla podmiotu kluczowego sprowadza się do następującego pakietu dokumentacyjno-technicznego:

Dokumentacja:

  • polityka bezpieczeństwa informacji zatwierdzona przez kierownika;
  • polityki tematyczne (kontroli dostępu, kryptografii, łańcucha dostaw, zarządzania incydentami, BCP/DRP);
  • rejestr aktywów ICT z klasyfikacją;
  • rejestr ryzyk i procedura szacowania ryzyka;
  • procedury operacyjne (incident response, change management, patch management);
  • program szkoleń cyber (dla personelu i zarządu);
  • zaświadczenia KRK personelu cybersec (art. 8f);
  • protokoły szkoleń zarządu (art. 8e ust. 3).

Wdrożenia techniczne:

  • system monitorowania w trybie ciągłym (SIEM lub równoważny);
  • zarządzanie podatnościami i patch management;
  • szyfrowanie (TLS w transmisji, AES w spoczynku);
  • segmentacja sieci;
  • backup i regularne testy odtworzenia;
  • testy penetracyjne lub skanowanie podatności;
  • IAM z MFA dla kont uprzywilejowanych.

To są minimalne dowody, których w trakcie kontroli z art. 53 ust. 2 pkt 1 KSC będzie domagał się organ właściwy do spraw cyberbezpieczeństwa. Brak dokumentacji = brak systemu w oczach regulatora — i podstawa do kary z art. 73 ust. 1 pkt 3 lub pkt 4 KSC.

Jak możemy Ci pomóc?

W Legal Geek wspieramy podmioty kluczowe i ważne we wdrażaniu wszystkich 14 obszarów art. 8 KSC — od projektu polityki bezpieczeństwa zatwierdzanej przez zarząd, przez gap analysis względem DORA dla sektora finansowego, mapowanie wymogów na konkretne dokumenty i wdrożenia, aż po przygotowanie organizacji do pierwszej kontroli organu właściwego. Jeżeli chcesz dowiedzieć się, jak wygląda mapa zgodności Twojej organizacji z art. 8 KSC — napisz do nas.

W kolejnym wpisie cyklu omawiamy procedurę zgłaszania incydentów poważnych z art. 11–12b KSC — w szczególności trzy terminy raportowania (24 godziny, 72 godziny, miesiąc) i ich praktyczne konsekwencje.

Co dalej w cyklu?