Jakie kompetencje powinien mieć pełnomocnik ds. cyberbezpieczeństwa?
Ustawa o KSC nie stawia pełnomocnikowi ds. cyberbezpieczeństwa żadnych wymagań kwalifikacyjnych. Jedyny punkt odniesienia w ustawie to poprzeczka dla audytora z art. 15. Co z tego wynika dla zarządu, który szuka kogoś do wdrożenia NIS2: jakie akty prawne i normy ISO trzeba znać, co przenosi się z praktyki IOD i o co zapytać kandydata.
W skrócie: ustawa o KSC nie stawia pełnomocnikowi ds. cyberbezpieczeństwa żadnych wymagań kwalifikacyjnych, bo w ogóle nie zna takiej funkcji. Osobie realizującej zadania z art. 8 lub art. 11 stawia jeden warunek: informację z KRK o niekaralności za przestępstwa przeciwko ochronie informacji (art. 8f). Jedyna poprzeczka kompetencyjna zapisana w ustawie dotyczy audytora z art. 15 i wymienia trzy normy: PN-EN ISO/IEC 27001, PN-EN ISO 22301 oraz ISA/IEC 62443. Zarząd, który szuka kogoś do wdrożenia wymagań NIS2, może użyć tej poprzeczki jako punktu odniesienia, pamiętając, że ta sama osoba nie przeprowadzi potem audytu (art. 15 ust. 2a). Reszta kompetencji nie jest nigdzie spisana, więc trzeba ją sprawdzić samodzielnie.
Zaczęło się od pytania, które dostałem od prezesa spółki komunalnej: „widziałem czterodniowe szkolenie na pełnomocnika ds. cyberbezpieczeństwa, wysłać kogoś od nas, czy szukać na zewnątrz?”. Chodziło o program DEKRA, cztery dni po siedem godzin, dziesięć modułów od wymagań prawnych NIS2 i ustawy o KSC, przez rolę pełnomocnika, interpretację norm ISO/IEC 27001 i ISO 22301, zabezpieczenia organizacyjne, fizyczne i technologiczne, nadzór nad dostawcami, cykl PDCA, aż po egzamin.
Program jest sensowny i widać w nim, skąd wzięła się sama nazwa roli. Najciekawszy jest jednak jego wymóg wstępny: „przynajmniej podstawowa znajomość wymagań norm ISO 27001 oraz ISO 22301, a także przepisów RODO”. Szkolenie zaczyna się tam, gdzie kompetencje już są. Poniżej piszę o tym, czego ono nie da, bo o to naprawdę pytał prezes.
Podstawa prawna: ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (dalej „uksc”, tekst jednolity Dz.U. 2026 poz. 20 ze zmianami), znowelizowana ustawą z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252), obowiązującą od 3 kwietnia 2026 r., która wdraża dyrektywę (UE) 2022/2555.
Czy ustawa stawia pełnomocnikowi jakiekolwiek wymagania?
Nie, i to jest punkt wyjścia do całej reszty. Ustawa o KSC nie zna funkcji pełnomocnika ds. cyberbezpieczeństwa, więc nie określa dla niej ani wykształcenia, ani certyfikatów, ani stażu. Osoby wykonującej te zadania dotyczą tylko trzy przepisy i żaden z nich nie mówi o kompetencjach.
Art. 8f ust. 1 uksc wymaga, by osoba, która ma realizować zadania z art. 8 lub art. 11, przed ich rozpoczęciem przedstawiła podmiotowi informację z Krajowego Rejestru Karnego o niekaralności za przestępstwa przeciwko ochronie informacji, a kierownik dopuszcza ją do zadań dopiero po jej otrzymaniu. Ust. 3 pozwala zastąpić to ważnym poświadczeniem bezpieczeństwa do klauzuli „poufne” lub wyższej, a ust. 4 zamyka drogę osobie skazanej prawomocnym wyrokiem. To warunek czystej kartoteki, a nie wiedzy.
Art. 8e uksc nakłada obowiązek corocznego, udokumentowanego szkolenia, ale na kierownika podmiotu i na osobę, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa. Zakres tego szkolenia ustawa opisuje przez odesłanie do przepisów, których ma dotyczyć (art. 8e ust. 2). Nie ma tu ani programu, ani wymagań wobec prowadzącego.
Art. 8c ust. 3 przesądza, że powierzenie obowiązków innej osobie za jej zgodą nie zdejmuje odpowiedzialności z kierownika podmiotu. Skoro odpowiedzialność zostaje przy zarządzie, to zarząd ponosi też konsekwencje złego wyboru doradcy i nie może się zasłonić tym, że ktoś przedstawił certyfikat.
Jaką poprzeczkę ustawa stawia audytorowi z art. 15?
To jedyne miejsce, w którym ustawodawca powiedział wprost, jakie kompetencje uważa za wystarczające w obszarze bezpieczeństwa systemów informacyjnych. Dotyczy audytu, nie pełnomocnika, ale zarząd nie ma lepszego punktu odniesienia.
Zgodnie z art. 15 ust. 2 uksc audyt może przeprowadzić jednostka oceniająca zgodność akredytowana w zakresie właściwym do ocen bezpieczeństwa systemów informacyjnych, co najmniej dwóch audytorów, albo CSIRT sektorowy, o ile jego audytorzy spełniają warunki dla audytorów. Audytor spełnia warunek, jeżeli ma:
- certyfikat z wykazu wydanego na podstawie art. 15 ust. 8, albo
- co najmniej trzyletnią praktykę w zakresie audytu bezpieczeństwa systemów informacyjnych, albo
- co najmniej dwuletnią praktykę i dyplom studiów podyplomowych w tym zakresie, wydany przez jednostkę uprawnioną do nadawania stopnia doktora nauk ekonomicznych, technicznych lub prawnych.
Art. 15 ust. 3 doprecyzowuje, co liczy się jako praktyka: udokumentowane wykonanie w ciągu ostatnich trzech lat trzech audytów w zakresie bezpieczeństwa systemów informacyjnych lub ciągłości działania albo wykonywanie takich audytów w wymiarze nie mniejszym niż pół etatu. Nowelizacja zmieniła tu jedną rzecz: uchyliła pkt 3 tego ustępu, czyli ścieżka audytu wewnętrznego w zakresie bezpieczeństwa informacji prowadzonego na podstawie przepisów wydanych na podstawie art. 18 ustawy o informatyzacji. Doświadczenie z corocznych audytów KRI w urzędzie samo w sobie już tej praktyki nie tworzy.
Wykaz certyfikatów nadal określa rozporządzenie Ministra Cyfryzacji z 12 października 2018 r. (Dz.U. 2018 poz. 1999). Nowelizacja nie zmieniła delegacji z art. 15 ust. 8 ani tego rozporządzenia nie uchyliła. W załączniku wymieniono jedenaście pozycji: CIA, CISA, certyfikat audytora wiodącego SZBI według normy PN-EN ISO/IEC 27001 wydany przez akredytowaną jednostkę certyfikującą osoby, certyfikat audytora wiodącego systemu zarządzania ciągłością działania PN-EN ISO 22301, CISM, CRISC, CGEIT, CISSP, SSCP, Certified Reliability Professional oraz certyfikaty uprawniające do tytułu ISA/IEC 62443 Cybersecurity Expert.
Ta lista jest najbliższa odpowiedzi na pytanie „czego właściwie ma dowieść kandydat”. Wskazuje trzy obszary: system zarządzania bezpieczeństwem informacji, ciągłość działania i bezpieczeństwo automatyki przemysłowej.
Jest jednak haczyk, o którym trzeba wiedzieć przed podpisaniem umowy. Art. 15 ust. 2a, dodany nowelizacją, stanowi, że audytu nie może przeprowadzić osoba realizująca w podmiocie audytowanym zadania z art. 8 oraz art. 9-13 ani osoba, która realizowała je w ciągu roku przed dniem rozpoczęcia audytu. Pełnomocnik, który zbudował SZBI, jest przez rok wyłączony z audytowania tej organizacji. Kupując „wdrożenie i audyt w pakiecie” od jednego wykonawcy, kupujesz coś, czego ustawa nie dopuszcza.
Skąd wzięła się nazwa „pełnomocnik” i co na ten temat mówią normy?
Z systemów zarządzania, a dokładniej z roli przedstawiciela kierownictwa. Wcześniejsze wydania ISO 9001 wymagały wyznaczenia takiej osoby i to od niej wzięli nazwę pełnomocnicy ds. jakości, a potem ds. zintegrowanego systemu zarządzania. Wydanie z 2015 r. tego wymagania już nie zawiera: odpowiedzialność za system przypisano najwyższemu kierownictwu, bez obowiązku obsadzania jednego stanowiska.
ISO/IEC 27001 w wydaniu z 2022 r. idzie tą samą drogą. Punkt 5.3 wymaga, żeby najwyższe kierownictwo przypisało i zakomunikowało odpowiedzialności i uprawnienia dla ról istotnych dla bezpieczeństwa informacji, w tym odpowiedzialność za zgodność systemu z normą i za raportowanie o jego funkcjonowaniu. Nazwa roli nie pada. Nazwa „pełnomocnik” jest więc wygodnym skrótem, a nie wymaganiem, i to samo zastrzeżenie dotyczy ustawy o KSC.
Ciekawszy dla zarządu jest punkt 7.2 normy. Organizacja ma określić, jakie kompetencje są niezbędne dla osób wykonujących pracę wpływającą na skuteczność systemu, zapewnić te kompetencje na podstawie wykształcenia, szkolenia lub doświadczenia i zachować udokumentowaną informację jako dowód. To jest realne wymaganie, które audytor sprawdzi. Jeżeli pełnomocnik przychodzi z zewnątrz, dowodem jest jego CV, lista wykonanych prac i certyfikaty w aktach, a nie sama umowa.
Jakie akty prawne musi znać pełnomocnik ds. cyberbezpieczeństwa?
Szkolenia zwykle kończą się na ustawie o KSC i dyrektywie NIS2. W praktyce rola dotyka co najmniej sześciu obszarów, a w sektorze publicznym siedmiu.
Ustawa o KSC po nowelizacji jest trzonem. Kandydat powinien czytać ją z tekstu, a nie z omówień. Minimum to art. 5 (kwalifikacja podmiotu, wraz z ust. 3 wyłączającym regułę o kontroli publicznej przy badaniu wielkości), art. 7-7m (wykaz), art. 8 ust. 1 (czternaście środków wymienionych w pkt 2 lit. a-n), art. 8 ust. 3 i załącznik nr 4 dla podmiotów publicznych, art. 9-13 (osoby kontaktowe, dokumentacja, incydenty), art. 14 (realizacja zadań własnymi strukturami albo umową) i art. 15 (audyt). Rozpisywałem wcześniej te obowiązki na przykładzie sektora wod-kan we wpisie o wdrożeniu wymagań NIS2 w przedsiębiorstwie wodociągowo-kanalizacyjnym.
Dyrektywa 2022/2555 przydaje się jako narzędzie wykładni. Polskie przepisy są jej transpozycją, więc przy wątpliwości co do zakresu obowiązku motywy dyrektywy i jej art. 20-23 mówią, o co chodziło. Tam też szuka się kontekstu dla wytycznych Komisji i ENISA.
RODO wchodzi w grę w każdym incydencie dotyczącym danych osobowych i w każdej umowie z pełnomocnikiem, który zobaczy rejestry incydentów i listy szkoleń. Osobno trzeba znać art. 38 ust. 6 RODO, jeżeli w organizacji ta sama osoba ma być IOD i pełnomocnikiem.
Ustawa o informatyzacji i rozporządzenie o Krajowych Ramach Interoperacyjności obowiązują podmioty realizujące zadania publiczne równolegle z ustawą o KSC. W urzędzie oznacza to dwa reżimy dokumentacyjne, które trzeba pogodzić, a nie prowadzić obok siebie.
Prawo zamówień publicznych to obszar, o którym prawie nikt nie mówi, a który nowelizacja ruszyła wprost. Zmieniony art. 226 ust. 1 pkt 17 Pzp nakazuje odrzucić ofertę obejmującą produkt, usługę lub proces ICT wskazany w rekomendacji Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa stwierdzającej ich negatywny wpływ na podstawowy interes bezpieczeństwa państwa. Dodany pkt 19 nakazuje odrzucić ofertę obejmującą produkt, usługę lub proces ICT określone w decyzji o uznaniu dostawcy za dostawcę wysokiego ryzyka (art. 67b ust. 15 uksc). Jeżeli pełnomocnik opiniuje postępowania na sprzęt i oprogramowanie, a zwykle opiniuje, musi te przepisy znać.
Ustawa o zarządzaniu kryzysowym po nowelizacji z 29 maja 2026 r. (Dz.U. 2026 poz. 815), wdrażającej dyrektywę CER, uruchomiła identyfikację podmiotów krytycznych. Podmiot uznany za krytyczny staje się podmiotem kluczowym niezależnie od wielkości, z obowiązkowym audytem. Dla spółki komunalnej, która dziś jest podmiotem ważnym, to najbardziej realna droga do zmiany statusu.
Do tego dochodzą przepisy sektorowe: prawo bankowe i DORA w finansach, ustawa o działalności leczniczej i przepisy o dokumentacji medycznej w ochronie zdrowia, ustawa o zbiorowym zaopatrzeniu w wodę w wod-kan. Pełnomocnik, który nie zna sektora klienta, będzie pisał dokumentację obok procesu.
Które normy ISO są w tej roli naprawdę używane?
Żadna norma nie jest w Polsce obowiązkowa i nowelizacja tego nie zmieniła. Art. 45 ust. 3 uksc pozwala ministrowi właściwemu do spraw informatyzacji opublikować w BIP zestawienie wymogów dokumentów normalizacyjnych, których wykonywanie realizuje obowiązki wynikające z ustawy i z rozporządzenia wydanego na podstawie art. 8a. Projekt takiego zestawienia idzie na trzydzieści dni konsultacji publicznych, z raportem z uwag (art. 45 ust. 4 i 5). To jest most między ustawą a normami, ale most dobrowolny: zestawienie ułatwia wykazanie zgodności, nie tworzy nowego obowiązku.
Poniżej normy, po które sięgam najczęściej, z odniesieniem do konkretnego przepisu.
ISO/IEC 27001:2022 daje wymagania dla systemu zarządzania bezpieczeństwem informacji: kontekst, przywództwo, planowanie, wsparcie, działanie, ocena i doskonalenie (rozdziały 4-10) plus załącznik A z 93 zabezpieczeniami w czterech grupach - organizacyjnych, dotyczących ludzi, fizycznych i technologicznych. Poprawka z 2024 r. dołożyła obowiązek rozważenia, czy zmiany klimatu są istotną kwestią dla systemu, i nie zmieniła liczby zabezpieczeń. Rozdziały 4-10 pokrywają się z tym, czego art. 8 ust. 1 pkt 1 i 2 lit. a oraz h wymaga od SZBI, a załącznik A jest najwygodniejszą listą kontrolną do art. 8 ust. 1 pkt 2 lit. b-n.
ISO/IEC 27002:2022 opisuje te 93 zabezpieczenia szczegółowo i to z niej, a nie z samej 27001, korzysta się przy pisaniu polityk tematycznych.
ISO/IEC 27005:2022 i ISO 31000:2018 obsługują art. 8 ust. 1 pkt 1, czyli systematyczne szacowanie ryzyka wystąpienia incydentu i zarządzanie nim. ISO 31000 daje ramy i słownik, ISO/IEC 27005 przekłada je na bezpieczeństwo informacji: identyfikacja, analiza, ocena i postępowanie z ryzykiem, w tym kryteria akceptacji. Żadnej z nich nie można się certyfikować i to dobrze, bo chodzi o metodę, a nie o papier.
ISO 22301:2019 obsługuje ciągłość działania, której ustawa wymaga w dwóch miejscach: art. 8 ust. 1 pkt 2 lit. f (plany ciągłości działania, plany awaryjne i plany odtworzenia działalności, wdrażane, dokumentowane, testowane i utrzymywane) oraz art. 10 ust. 3 pkt 3, który wymienia dokumentację systemu zarządzania ciągłością działania jako odrębny element dokumentacji normatywnej. Tu tkwi powód, dla którego programy szkoleń łączą 27001 z 22301: ustawa wymaga obu systemów, choć nazywa je po swojemu.
ISO/IEC 27035-1:2023 porządkuje obsługę incydentów: wykrywanie, raportowanie, ocena, reagowanie, wnioski. Art. 11 uksc dokłada do tego terminy wobec CSIRT i formę zgłoszenia, których norma nie zna.
ISO/IEC 27036-2:2022 dotyczy bezpieczeństwa w relacjach z dostawcami i odpowiada art. 8 ust. 1 pkt 2 lit. e oraz art. 8 ust. 2, gdzie ustawa każe uwzględnić podatności dostawcy, ogólną jakość jego produktów i usług, wyniki skoordynowanej oceny bezpieczeństwa Grupy Współpracy oraz wyniki postępowania w sprawie dostawcy wysokiego ryzyka.
ISA/IEC 62443 to seria norm dla systemów automatyki przemysłowej i sterowania. Znalazła się w wykazie certyfikatów z 2018 r. nieprzypadkowo: w wodociągach, ciepłownictwie, energetyce i transporcie usługa działa na sterownikach, telemetrii i panelach HMI, a nie na serwerze plików. Pełnomocnik, który zna tylko biurowe IT, nie zobaczy najpoważniejszego ryzyka w takiej organizacji.
Proporcja między jednym a drugim jest przy tym stała. Norma jest narzędziem do wykazania, że obowiązek został wykonany. Obowiązek płynie z ustawy i to jej brzmienie rozstrzyga, gdy oba teksty mówią co innego.
Czy certyfikat ISO 27001 wystarczy do zgodności z ustawą o KSC?
Nie i to jest jedno z najczęstszych nieporozumień w rozmowach z zarządami. Certyfikat potwierdza, że w zadeklarowanym zakresie system spełnia wymagania normy w dniu audytu certyfikującego. Zakres bywa wąski, czasem obejmuje jeden proces albo jedną lokalizację, a ustawa dotyczy systemu informacyjnego wykorzystywanego w procesach wpływających na świadczenie usługi.
Ustawa dokłada obowiązki, których norma nie zna: wpis do wykazu podmiotów kluczowych i ważnych oraz zgłaszanie zmian danych w czternaście dni, wyznaczenie osób kontaktowych i korzystanie z Systemu S46, zgłoszenie incydentu poważnego do właściwego CSIRT w reżimie 24 godzin, 72 godzin i miesiąca, informacja z KRK dla osób realizujących zadania z art. 8 i art. 11, coroczne udokumentowane szkolenie kierownika oraz audyt z art. 15 przeprowadzony przez podmiot spełniający warunki z ust. 2. Struktura dokumentacji z art. 10 też jest własna: podział na dokumentację normatywną i operacyjną, z wymienionymi elementami, nie odpowiada wprost wykazowi udokumentowanych informacji z normy.
W drugą stronę zależność jest mocna i dlatego warto mieć w zespole kogoś, kto normę zna. Organizacja z działającym SZBI ma już szacowanie ryzyka, politykę, przegląd zarządzania, zarządzanie aktywami i kontrolę dostępu, więc wdrożenie ustawy sprowadza się do uzupełnienia luk i zmiany zakresu. Organizacja bez tego zaczyna od zera i różnica w nakładzie jest kilkukrotna.
Co z praktyki inspektora ochrony danych przenosi się na KSC?
Pracuję w obu rolach i kolejność ma znaczenie: więcej przenosi się z RODO do ustawy o KSC niż odwrotnie, bo RODO działa w Polsce od 2018 r. i wymusiło metodykę tam, gdzie wcześniej jej nie było.
Najmocniej przenosi się szacowanie ryzyka. Art. 24 i 32 RODO każą dobierać środki odpowiednie do ryzyka, a art. 35 dokłada ocenę skutków przy wysokim ryzyku. Art. 8 ust. 1 pkt 1 uksc wymaga systematycznego szacowania ryzyka wystąpienia incydentu i zarządzania nim, a pkt 2 środków odpowiednich i proporcjonalnych do oszacowanego ryzyka, z uwzględnieniem najnowszego stanu wiedzy, kosztów wdrożenia, wielkości podmiotu i skutków społeczno-gospodarczych. Metoda jest ta sama: identyfikacja aktywów, scenariusze, podatności, prawdopodobieństwo i skutek, kryteria akceptacji, plan postępowania. Pokazywałem ją krok po kroku na przykładzie poczty elektronicznej we wpisie o ryzyku dla danych osobowych w poczcie e-mail.
Zmienia się przedmiot ochrony i to jest miejsce, w którym IOD wchodzący w rolę pełnomocnika najczęściej się potyka. RODO chroni prawa i wolności osób, których dane dotyczą, więc skutek mierzy się krzywdą człowieka. Ustawa o KSC chroni ciągłość świadczenia usługi, więc skutek mierzy się niedostępnością usługi dla odbiorców. Awaria sterownika w oczyszczalni jest ryzykiem niemal zerowym po stronie RODO i bardzo wysokim po stronie ustawy, a wyciek akt kadrowych odwrotnie. Analizy z RODO nie da się przepisać, można przenieść tylko metodę i warsztat.
Rejestr czynności przetwarzania z art. 30 RODO opisuje procesy i systemy, więc jest najlepszym punktem startu dla zarządzania aktywami z art. 8 ust. 1 pkt 2 lit. m. Trzeba go tylko uzupełnić o to, czego RODO nie widzi: systemy sterowania, urządzenia sieciowe, łącza, integracje.
Art. 28 RODO nauczył administratorów, że dostawcę trzeba wybrać, umową związać i skontrolować. Art. 8 ust. 1 pkt 2 lit. e i art. 8 ust. 2 uksc żądają tego samego wobec łańcucha dostaw ICT, tyle że bez ograniczenia do danych osobowych i z uwzględnieniem jakości produktów dostawcy. Umowa powierzenia, która już jest, nie wystarczy, ale procedura oceny dostawcy nadaje się do rozszerzenia.
Przy incydentach IOD zna już reżim 72 godzin z art. 33 RODO i wie, że zegar rusza od stwierdzenia naruszenia, a nie od ustalenia wszystkich okoliczności. Pisałem o tym przy okazji poradnika UODO dotyczącego naruszeń. W ustawie o KSC zegary są dwa: wczesne ostrzeżenie w 24 godziny, zgłoszenie w 72 godziny, sprawozdanie końcowe w miesiąc. Jeżeli incydent dotyczy danych osobowych, oba reżimy biegną równolegle i trzeba je prowadzić jedną procedurą z dwiema ścieżkami, bo inaczej któraś zostanie przegapiona. Jak to wygląda w praktyce spółki komunalnej, opisywałem przy ataku na MPK Kraków.
Art. 5 ust. 2 RODO wymaga wykazania zgodności, a art. 10 ust. 4 uksc mówi o dokumentacji operacyjnej, czyli zapisach poświadczających wykonanie czynności wymaganych przez dokumentację normatywną, łącznie z logami. To jest ta sama idea i ten sam nawyk: jeżeli czegoś nie ma w zapisie, to z punktu widzenia kontroli się nie wydarzyło.
Zostaje niezależność. IOD zna art. 38 ust. 6 RODO i zakaz konfliktu interesów. Ustawa o KSC ma swój odpowiednik w art. 15 ust. 2a. Osoba, która przeszła przez spór o to, czy IOD może zarządzać działem IT, rozumie od razu, dlaczego pełnomocnik nie może audytować własnej pracy.
Czego z RODO nie przeniesiesz: konfiguracji urządzeń sieciowych, segmentacji sieci, sterowania przemysłowego, testów odtworzenia kopii i rozmowy z serwisem automatyki. To jest warstwa, w której IOD bez zaplecza technicznego potrzebuje kogoś obok siebie.
Czego nie nauczy żadne czterodniowe szkolenie?
Cztery dni wystarczą, żeby poznać strukturę normy i mapę obowiązków. Nie wystarczą na to, co decyduje o wartości tej roli.
Pierwsze to czytanie stanu faktycznego zamiast dokumentu. Kandydat, który potrafi opisać wymaganie art. 8 ust. 1 pkt 2 lit. l, a nie potrafi sprawdzić, czy na styku sieci rzeczywiście działa uwierzytelnianie wieloskładnikowe i dla których kont, napisze politykę zgodną z ustawą i niezgodną z rzeczywistością. Takich polityk widziałem więcej niż dobrych.
Drugie to technologia operacyjna. W spółce wodociągowej albo ciepłowniczej usługa stoi na sterownikach, telemetrii i zdalnym dostępie serwisowym firmy automatyki, często przez modem GSM, o którym nie wie nikt poza automatykiem. Szablony tego nie widzą, a IEC 62443 jest w tym miejscu przydatniejsza niż załącznik A do 27001.
Trzecie to prowadzenie incydentu pod presją. Różnicę między osobą, która obsłużyła incydent, a osobą, która o nim czytała, widać w pierwszej godzinie: w tym, czy ktoś pyta o zakres, zanim zacznie odtwarzać, czy pilnuje zabezpieczenia dowodów, czy notuje godziny i czy ktoś patrzy na drugi zegar, ten z RODO.
Czwarte to rozmowa z zarządem. Art. 8d uksc wymaga od kierownika decyzji i zaplanowania adekwatnych środków finansowych. Decyzja zapada wtedy, gdy ktoś przedstawi dwa albo trzy warianty z kosztem, skutkiem i ryzykiem rezydualnym. Jeżeli pełnomocnik potrafi mówić tylko językiem normy, decyzji nie będzie, a kara z art. 73a spadnie na kierownika.
Piąte to gotowość do powiedzenia „nie wiem, sprawdzę w tekście ustawy”. Sam pomyliłem się przy kwalifikacji spółki komunalnej i poprawiłem dopiero po przeczytaniu art. 5 ust. 3 w ustawie zamiast w omówieniu. Doradca, który na każde pytanie ma natychmiastową odpowiedź, jest w tej dziedzinie ryzykiem, a nie zaletą.
O co zapytać kandydata na pełnomocnika?
Osiem pytań, które zadaję sobie sam, gdy oceniam, czy potrafię obsłużyć daną organizację. Odpowiedzi sprawdzają wiedzę, której nie da się zmyślić.
- Jaki jest status naszego podmiotu i z czego to wynika? Dobra odpowiedź odsyła do art. 5 i załącznika nr 1 lub 2, pyta o dane ze sprawozdania finansowego i sama z siebie wspomina o art. 5 ust. 3, czyli o tym, że kontrola gminy nad spółką nie czyni jej dużym przedsiębiorcą.
- Czy jesteśmy już w wykazie i co się dzieje, jeżeli jesteśmy tam wpisani z urzędu? Kandydat powinien znać różnicę między samodzielnym wnioskiem a wezwaniem do uzupełnienia danych i wiedzieć, że wpis z urzędu może nie obejmować całej działalności.
- Jaką metodyką szacuje pan ryzyko i na czym ją pan opiera? Odpowiedź „na ISO 27005” jest dopiero początkiem. Chcesz usłyszeć, jak wyglądają kryteria akceptacji ryzyka, kto je zatwierdza i jak wynik analizy przekłada się na plan postępowania i budżet.
- Kto przeprowadzi u nas audyt z art. 15 i dlaczego nie pan? Kandydat, który nie zna art. 15 ust. 2a, właśnie pokazał, gdzie kończy się jego znajomość ustawy.
- Czy przedstawi pan informację z KRK przed rozpoczęciem pracy? Powinna paść odpowiedź twierdząca z odwołaniem do art. 8f ust. 1 i bez zdziwienia.
- Czy pana firma jest podmiotem kluczowym jako dostawca usług zarządzanych w zakresie cyberbezpieczeństwa? Zależy to od jej wielkości, ale samo pytanie sprawdza, czy wykonawca rozumie własny status i czy wie, że informacja o umowie z nim trafi do wykazu.
- Proszę pokazać zanonimizowany dokument, który pan napisał. Analiza ryzyka albo procedura incydentowa mówi o kompetencjach więcej niż certyfikat. Szukaj metryki, dat przeglądu, konkretnych nazw systemów i tego, czy dokument da się wykonać.
- Co pan zrobi w pierwszych trzydziestu dniach? Sensowna odpowiedź zaczyna się od ustalenia statusu i terminów, a nie od pisania polityk.
Jeżeli organizacja pracuje na infrastrukturze przemysłowej, dołóż dziewiąte pytanie o doświadczenie z OT i poproś o przykład. Jeżeli ta sama osoba ma być IOD, dziesiąte: jak rozdzieli obie role i kto oceni skuteczność środków, które sama zarekomenduje.
Czy pełnomocnik musi być jedną osobą?
Nie musi i w większości przypadków nie powinien. Ustawa wymaga wykonania zadań, a art. 14 uksc dopuszcza realizację przez wewnętrzne struktury odpowiedzialne za cyberbezpieczeństwo albo umowę z dostawcą usług zarządzanych w zakresie cyberbezpieczeństwa. Nazwa stanowiska nie interesuje ani organu właściwego, ani audytora.
Potrzebne kompetencje układają się w trzy wiązki, które rzadko spotyka jedna osoba: znajomość ustawy, RODO i przepisów sektorowych, znajomość konkretnej infrastruktury IT i OT wraz z umiejętnością weryfikacji konfiguracji oraz warsztat audytorski, czyli szacowanie ryzyka, dowodzenie i dokumentowanie. W mniejszym podmiocie wygląda to zwykle tak, że pierwsza i trzecia wiązka są u pełnomocnika, a druga u informatyka albo u dostawcy IT, którego trzeba włączyć do procesu i związać umową.
Modelu, którego unikam, jest jeden: zakup „wdrożenia NIS2” jako pakietu dokumentów. Dostaje się wtedy komplet polityk zgodnych z ustawą i niezgodnych z organizacją, bez analizy ryzyka, bez inwentaryzacji i bez nikogo, kto odpowiada za ich utrzymanie. Audytor z art. 15 znajdzie to w pierwszej godzinie, a kontrola po incydencie jeszcze szybciej.
Wybór kandydata jest decyzją kierownika podmiotu i to on zostaje z jej skutkami, bo art. 8c ust. 3 nie pozwala przenieść odpowiedzialności razem z zadaniami. Traktowałbym ją tak samo poważnie jak wybór biegłego rewidenta i poświęcić na rozmowę tyle czasu, ile trwa jedno z tych czterodniowych szkoleń.
Najczęściej zadawane pytania
Jakie kwalifikacje musi mieć pełnomocnik ds. cyberbezpieczeństwa?
Czy certyfikat ISO 27001 oznacza zgodność z ustawą o KSC?
Czy pełnomocnik ds. cyberbezpieczeństwa może przeprowadzić audyt z art. 15?
Jakie normy ISO są przydatne w roli pełnomocnika ds. cyberbezpieczeństwa?
Czy doświadczenie inspektora ochrony danych przydaje się przy wdrożeniu NIS2?
Czy pełnomocnikiem ds. cyberbezpieczeństwa musi być jedna osoba?
Źródła
- Ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa
- Obwieszczenie Marszałka Sejmu z 29 grudnia 2025 r. - tekst jednolity ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 20)
- Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252)
- Rozporządzenie Ministra Cyfryzacji z 12 października 2018 r. w sprawie wykazu certyfikatów uprawniających do przeprowadzenia audytu (Dz.U. 2018 poz. 1999)
- Rozporządzenie Rady Ministrów z 21 maja 2024 r. w sprawie Krajowych Ram Interoperacyjności (Dz.U. 2024 poz. 773)
- Dyrektywa (UE) 2022/2555 (NIS2)
- Rozporządzenie (UE) 2016/679 (RODO)
- Ustawa z 11 września 2019 r. - Prawo zamówień publicznych (tekst jednolity Dz.U. 2026 poz. 793)
- Ustawa z 29 maja 2026 r. o zmianie ustawy o zarządzaniu kryzysowym oraz niektórych innych ustaw (Dz.U. 2026 poz. 815)
- ISO/IEC 27001:2022 - Information security management systems. Requirements
- ISO/IEC 27002:2022 - Information security controls
- ISO/IEC 27005:2022 - Guidance on managing information security risks
- ISO 31000:2018 - Risk management. Guidelines
- ISO 22301:2019 - Business continuity management systems. Requirements
- ISO/IEC 27035-1:2023 - Information security incident management. Principles and process
- ISO/IEC 27036-2:2022 - Supplier relationships. Requirements
- ISA/IEC 62443 Series of Standards
Stan prawny sprawdzony: . Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).