KRK w UoKSC

Każda większa regulacja ma ten moment, w którym ktoś w organizacji czyta nowy przepis i marszczy brwi. Potem zaczyna się ekwilibrystyka compliance z Excel, HR, prawnikiem, CISO, administratorzy, dostawcy, połową działu finansów i jeszcze wyjątkowymi userami, którzy mają dostęp do szczególnych kategorii informacji wewnętrznych. Tylko w tym wszystkim można przesadzić. W przypadku art. 8f ustawy o krajowym systemie cyberbezpieczeństwa taka nadgorliwość może szybko zrobić się organizacyjnie ciężka i prawnie niezbyt elegancka.

Nowelizacja KSC weszła w życie 3 kwietnia 2026 r. i dostosowuje polskie przepisy m.in. do NIS2. Wprowadza też nowy wymóg dotyczący niekaralności osób realizujących określone zadania z zakresu cyberbezpieczeństwa. Słowo „określone” nie jest tu ozdobą. Ono naprawdę ma znaczenie.

O co chodzi w art. 8f?

Art. 8f mówi, że przed rozpoczęciem realizacji zadań, o których mowa w art. 8 lub art. 11 UoKSC, osoba mająca wykonywać te zadania przedstawia podmiotowi kluczowemu albo ważnemu informację z Krajowego Rejestru Karnego. Informacja ma potwierdzać niekaralność za przestępstwa przeciwko ochronie informacji. Kierownik podmiotu dopuszcza taką osobę do realizacji tych zadań po otrzymaniu informacji z KRK. Przepis przewiduje również praktyczny wyjątek. Wymaganie uznaje się za spełnione, jeżeli osoba posiada ważne poświadczenie bezpieczeństwa upoważniające do dostępu do informacji niejawnych o klauzuli „poufne” lub wyższej.

Osoba prawomocnie skazana za przestępstwa przeciwko ochronie informacji nie może natomiast realizować zadań z art. 8 lub art. 11.

Art. 8 i art. 11 – czyli nie każdy, kto ma login do systemu

Kogo obejmie to w praktyce?

W pierwszej kolejności będą to osoby odpowiedzialne za SZBI. Do tej grupy można zaliczyć pełnomocnika ds. SZBI, Compliance Managera, osoby przygotowujące polityki, procedury, analizę ryzyka, dokumentację bezpieczeństwa i nadzór nad środkami bezpieczeństwa. W tym zakresie zwykle mieści się także CISO, Head of Cybersecurity, Security Officer albo osoba, której organizacja przypisała odpowiedzialność za zarządzanie ryzykiem cyber, podatnościami, incydentami, raportowaniem do CSIRT, kontrolą dostępu czy nadzorem nad środkami technicznymi.

Do zakresu art. 8f będą też najczęściej wchodzić osoby z SOC, wewnętrznego CSIRT, incident managerowie i analitycy bezpieczeństwa. Jeżeli ktoś klasyfikuje incydent, przygotowuje zgłoszenie, kontaktuje się z CSIRT, obsługuje materiał dowodowy, koordynuje działania naprawcze albo prowadzi komunikację incydentową, to trudno potem twierdzić, że art. 11 go nie dotyczy. A administratorzy? Często tak, ale nie z automatu.

Sam fakt, że ktoś administruje systemem, nie musi jeszcze oznaczać wykonywania zadań z art. 8 lub art. 11. Jeżeli jednak administrator odpowiada za IAM, PAM, EDR, SIEM, backup, DR, segmentację, monitoring, aktualizacje, podatności, logowanie, systemy krytyczne albo działania po incydencie, to w praktyce wchodzi w obszar środków bezpieczeństwa, ciągłości działania lub zarządzania incydentami.

W zakresie mogą znaleźć się również audytorzy wewnętrzni cyber/SZBI, osoby od ryzyka, zgodności i przygotowania do audytów KSC. Szczególnie wtedy, gdy nie są tylko obserwatorami, ale realnie oceniają, dokumentują, utrzymują albo nadzorują zgodność SZBI, środki bezpieczeństwa i ryzyka.

Osoby wskazane do kontaktu z CSIRT również mogą wejść w ten zakres, jeżeli faktycznie wykonują czynności z art. 11. Samo formalne wskazanie kontaktu nie powinno być traktowane automatycznie jako przesłanka do KRK. W praktyce jednak takie osoby bardzo często zgłaszają incydenty, uzupełniają informacje, koordynują odpowiedzi i przekazują dane. Wtedy nie jest to już ozdobna funkcja w tabelce.

Zarząd, dyrektorzy i cała święta hierarchia odpowiedzialności

Kierownik podmiotu ma odrębną odpowiedzialność za wykonywanie obowiązków cyberbezpieczeństwa przez podmiot kluczowy albo ważny. Ustawa wprost wskazuje odpowiedzialność kierownika za realizację obowiązków z zakresu cyberbezpieczeństwa, w tym m.in. art. 8 i art. 8f. To nadal nie oznacza, że każdy członek zarządu, dyrektor czy kierownik działu automatycznie musi przedstawić KRK tylko dlatego, że ma tytuł z PowerPointa i dostęp do raportów. Jeżeli zarząd podejmuje decyzje nadzorcze, zatwierdza budżet i przydziela odpowiedzialności, to jest to inny zakres niż operacyjne wykonywanie zadań z art. 8 lub art. 11.

Kogo nie obejmować?

Nie widzę dobrego uzasadnienia, aby rozszerzać ten obowiązek na zwykłych użytkowników systemów.

• Pracownik biurowy nie realizuje zadań z art. 8 lub art. 11 tylko dlatego, że korzysta z poczty.
• Osoba z HR, finansów, sprzedaży, administracji, produkcji czy operacji nie wchodzi w zakres przepisu tylko dlatego, że ma login.
• Pracownik biznesowy z dostępem do informacji wewnętrznych nie wykonuje automatycznie zadań SZBI albo zadań dot. incydentów.

Wyjątkiem będzie sytuacja, w której taka osoba pełni rolę właściciela aktywa, lokalnego koordynatora SZBI albo ma w procedurach przypisane konkretne zadania bezpieczeństwa. To ważne, bo w przeciwnym razie art. 8f łatwo zamienić w powszechny screening personelu. A przepis daje podstawę do weryfikacji osób wykonujących konkretne zadania ustawowe, nie do masowego zbierania zaświadczeń.

Dostawcy, MSSP, B2B i konsultanci

Forma współpracy nie powinna być decydująca. Jeżeli zewnętrzny MSSP, konsultant, specjalista B2B albo podwykonawca wykonuje zadania z art. 8 lub art. 11 na rzecz podmiotu kluczowego albo ważnego, organizacja powinna potraktować go funkcjonalnie tak samo jak osobę wewnętrzną.

Ustawa przewiduje możliwość powołania wewnętrznych struktur odpowiedzialnych za cyberbezpieczeństwo albo zawarcia umowy z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. Skoro więc zadania mogą być realizowane przez dostawcę, trzeba ocenić, kto po jego stronie faktycznie wykonuje czynności z art. 8 lub art. 11.

Nie oznacza to jednak, że KRK ma przedstawić każdy pracownik dostawcy, który tylko zobaczył nazwę klienta w systemie ticketowym.

Zakres powinien dotyczyć osób realnie przypisanych do zadań SZBI, monitoringu, obsługi incydentów, podatności, IAM, SIEM, EDR, backupu, DR, raportowania do CSIRT albo utrzymania środków bezpieczeństwa.

Jak to wdrożyć bez robienia z HR małego ABW?

Najpierw trzeba przejść przez obowiązki z art. 8 i art. 11, a następnie wskazać role, które te obowiązki wykonują. Dopiero potem można przypisać wymóg KRK do konkretnych ról lub funkcji. Nie odwrotnie.

W SZBI, procedurze HR/compliance albo procedurze zarządzania personelem cyberbezpieczeństwa warto opisać co najmniej trzy obszary.

Bezpieczna interpretacja?

Art. 8f nie powinien być czytany jako przepis o wszystkich pracownikach z dostępem do informacji. To przepis o osobach realizujących ustawowe zadania cyberbezpieczeństwa. KRK wymagamy więc od osób, które mają przypisane i faktycznie wykonują zadania z art. 8 lub art. 11 UoKSC. Nie od każdego, kto ma służbowego laptopa, skrzynkę pocztową czy dostęp folderu. Należy zrobić mapowanie ról, przypisać wymóg do konkretnych funkcji, opisać wyjątki, uwzględnić dostawców i zostawić dowód podjętych decyzji w ramach SZBI. Unikajmy nadmiarowego screeningu, ponieważ nie każdy użytkownik systemu jest personelem cyberbezpieczeństwa. Nie trzeba sobie dopisywać obowiązków, których przepis wprost nie wymaga.