SZBI według ustawy o KSC i NIS2. Co zmienić w systemie, który firma już ma?

System zarządzania bezpieczeństwem informacjiSystem zarządzania bezpieczeństwem informacji Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów. (SZBI) to obowiązek z art. 8 ust. 1 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.): podmiot kluczowyPodmiot kluczowy Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. lub podmiot ważnyPodmiot ważny Podmiot z sektorów ustawy o KSC, który spełnia jej kryteria, ale nie jest podmiotem kluczowym. Wdraża SZBI i zgłasza incydenty poważne tak jak podmiot kluczowy. wdraża go w systemie informacyjnym, którego używa w procesach wpływających na świadczenie usługi. Ustawa nie wskazuje normy, według której ten system trzeba zbudować. Opisuje, co ma zapewniać.

Większość firm, z którymi rozmawiam, coś już ma: certyfikat ISO/IEC 27001, system zbudowany jeszcze pod dawny obowiązek operatora usługi kluczowej albo, w urzędzie, SZBI z rozporządzenia o Krajowych Ramach InteroperacyjnościKrajowe Ramy Interoperacyjności Rozporządzenie Rady Ministrów z 2024 r., które między innymi nakazuje podmiotom realizującym zadania publiczne prowadzić system zarządzania bezpieczeństwem informacji.. Każdy z tych systemów jest dobrym punktem wyjścia i żaden nie jest z automatu zgodny z ustawą o KSC po nowelizacji z 2026 r.Nowelizacja ustawy o KSC z 2026 r. Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw. Wdraża NIS2, obowiązuje od 3 kwietnia 2026 r.

Certyfikat ISO/IEC 27001 mówi, że system jest zgodny z normą w zakresie, który organizacja sama wybrała. Ustawa o KSC pyta o coś innego: czy system obejmuje usługę i daje to, co wymienia art. 8.

Ten tekst jest dla kierowników podmiotówKierownik podmiotu Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie. kluczowych i ważnych oraz osób, którym powierzyli cyberbezpieczeństwo. Opisuję, czego wymaga ustawa, co zmienia NIS2Dyrektywa NIS2 Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r., gdzie system zgodny z normą zwykle ma luki, jakie błędy widuję przy wdrożeniach i w czym pomaga pełnomocnik ds. cyberbezpieczeństwa.

Czego ustawa o KSC wymaga od SZBI?

Art. 8 ust. 1 ustawy o KSC wymienia pięć rzeczy, które system ma zapewnić: systematyczne szacowanie ryzyka wystąpienia incydentu i zarządzanie tym ryzykiem (pkt 1), środki techniczne i organizacyjne proporcjonalne do oszacowanego ryzyka (pkt 2), zbieranie informacji o cyberzagrożeniach i podatnościach (pkt 3), zarządzanie incydentami (pkt 4) oraz środki zapobiegające incydentom i ograniczające ich wpływ (pkt 5).

Najdłuższy jest pkt 2. Środki mają uwzględniać „najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka, skutki społeczne i gospodarcze”, a ustawa wylicza „w szczególności” 14 obszarów, od lit. a do lit. n. Są wśród nich polityki szacowania ryzyka i polityki tematyczne, bezpieczeństwo łańcucha dostaw ICT (lit. e), plany ciągłości działania (lit. f), objęcie systemu „systemem monitorowania w trybie ciągłym” (lit. g), polityki oceny skuteczności środków (lit. h), kryptografia (lit. k), uwierzytelnianie wieloskładnikowe „w stosownych przypadkach” (lit. l), zarządzanie aktywami (lit. m) i polityki kontroli dostępu (lit. n).

Wokół art. 8 są przepisy, które dopowiadają resztę:

• art. 8d pkt 1: to kierownik podmiotu „podejmuje decyzje w zakresie przygotowania, wdrażania, stosowania, przeglądu i nadzoru systemu zarządzania bezpieczeństwem informacji”, a art. 8e nakłada na niego coroczne, udokumentowane szkolenie;
• art. 10: dokumentacja normatywna i operacyjna, z nadzorem nad wersjami, dostępem i przechowywaniem przez co najmniej 2 lata od wycofania;
• art. 8b: dostawcy usług cyfrowych wymienieni w ust. 1 (między innymi chmura, centra danych, dostawcy usług zarządzanych) stosują w ramach SZBI środki z rozporządzenia wykonawczego Komisji (UE) 2024/2690;
• art. 15 ust. 1: podmiot kluczowy co najmniej raz na 3 lata przeprowadza audyt bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi.

Podmiot ważny, który jest podmiotem publicznym, nie stosuje art. 8 ust. 1 ustawy o KSC. Wdraża SZBI spełniający wymogi z załącznika nr 4 do ustawy (art. 8 ust. 3) i przegląda go co najmniej raz w roku. Ministerstwo Cyfryzacji pisze w swoim FAQ, że załącznik „był prezentowany jako uproszczony zestaw wymagań”, a podmioty kluczowe realizują pełny zakres wymagań z art. 8 ustawy o KSC (pytanie 3.39).

Termin jest wspólny dla SZBI i reszty rozdziału 3. Podmioty, które 3 kwietnia 2026 r. spełniały przesłanki podmiotu kluczowego lub ważnego, mają na to 12 miesięcy (art. 33 ust. 1 ustawy nowelizującej), czyli czas do 3 kwietnia 2027 r. Pierwszy audyt z art. 15 ustawy o KSC podmiot kluczowy przeprowadza w terminie 24 miesięcy (art. 33 ust. 2 ustawy nowelizującej).

Co do tego dokłada NIS2?

Art. 21 ust. 1 dyrektywy NIS2 wymaga, żeby podmioty wprowadzały „odpowiednie i proporcjonalne środki techniczne, operacyjne i organizacyjne”, przy uwzględnieniu najnowszego stanu wiedzy oraz, „w stosownych przypadkach, odpowiednich norm europejskich i międzynarodowych”. Art. 21 ust. 2 dyrektywy NIS2 dodaje, że środki bazują „na podejściu uwzględniającym wszystkie zagrożenia” i obejmują co najmniej dziesięć elementów, od polityki analizy ryzyka (lit. a) po uwierzytelnianie wieloskładnikowe (lit. j). Polski ustawodawca przeniósł ten katalog do art. 8 ust. 1 pkt 2 ustawy o KSC niemal jeden do jednego.

Druga rzecz to zarząd. Art. 20 ust. 1 dyrektywy NIS2 wymaga, żeby organy zarządzające zatwierdzały środki zarządzania ryzykiem, nadzorowały ich wdrażanie i mogły odpowiadać za naruszenia, a art. 20 ust. 2 dyrektywy NIS2 nakłada na członków tych organów regularne szkolenia. Ustawa o KSC realizuje to w art. 8c (odpowiedzialność kierownika, także po powierzeniu zadań innej osobie), art. 8d i art. 8e.

Wytyczne ENISA do rozporządzenia 2024/2690 odwzorowują każde wymaganie na ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST Cybersecurity Framework 2.0 i kilka innych dokumentów. ENISA od razu zastrzega, że to odwzorowanie „should not be interpreted as a measure of equivalency among different standards or frameworks” i nie ocenia, czy norma w pełni pokrywa wymagania rozporządzenia.

Tabela z ENISA pomaga znaleźć, gdzie w normie szukać odpowiednika, ale luk nie zamyka.

Tak samo czytają to organy w innych państwach. Niemiecki BSI (Federalny Urząd Bezpieczeństwa Informatycznego) na pytanie, czy certyfikat ISO/IEC 27001 wystarcza do zgodności z NIS2, odpowiada krótko: „Nein”. Podaje powody: zakres systemu organizacja wybiera sama, a niemiecka ustawa wymaga środków dla całej działalności objętej przepisami, ogólna akceptacja ryzyka jest wykluczona, a norma nie obejmuje obowiązków ustawowych, takich jak zgłaszanie incydentów czy odpowiedzialność i szkolenie kierownictwa. Zarazem nazywa certyfikat „ein gutes Fundament”, czyli dobrym fundamentem.

Belgia poszła dalej i daje podmiotom z certyfikatem ISO/IEC 27001 domniemanie zgodności, ale tylko wtedy, gdy zakres certyfikatu obejmuje wszystkie sieci i systemy informacyjne podmiotu („with the scope in line with NIS2 - i.e. all networks and information systems”), a certyfikat wydała akredytowana jednostka zatwierdzona przez belgijskie Centrum Cyberbezpieczeństwa (CCB). Polska ustawa o KSC takiego mechanizmu nie ma.

We wrześniu 2026 r. Minister Cyfryzacji opublikował zestawienie dokumentów normalizacyjnych z art. 45 ust. 3 ustawy o KSC: według ministerstwa „blisko 125 pozycji”, czyli norm, wytycznych i frameworków przypisanych do sześciu obszarów SZBI. PN-EN ISO/IEC 27001:2023 jest w nim normą certyfikowalną przypisaną do dwóch obszarów, zarządzania ryzykiem i bezpieczeństwa systemów. Zestawienie „ma charakter referencyjny, pomocniczy i informacyjny”, a w raporcie z konsultacji minister zastrzega, że certyfikat odnoszący się „wyłącznie do części obowiązków wynikających z uKSC nie zwalnia podmiotu z obowiązku realizacji pozostałych wymagań”. Czytam je więc jako mapę do analizy luk, bo domniemanie zgodności, takie jak w Belgii, z niego nie wynika.

Mamy SZBI zgodny z ISO/IEC 27001. Co trzeba zmienić?

Ministerstwo Cyfryzacji odpowiada na to pytanie wprost: organizacje, które wdrożyły SZBI według dostępnych standardów, „mogą wykorzystać i dostosować już istniejącą dokumentację”, ale „sama dokumentacja to za mało, zapewnienie cyberbezpieczeństwa musi być realne, a nie papierowe” (FAQ, pytanie 3.6). Nie zaczynałbym więc od pisania nowego systemu, tylko od analizy luk między tym, co jest, a art. 8 ustawy o KSC. Luki, które znajduję najczęściej, są poniżej.

Jeśli certyfikat wciąż odwołuje się do wydania normy z 2013 r., nie jest już ważny: według dokumentu IAF MD 26 okres przejściowy na wydanie z 2022 r. skończył się 31 października 2025 r., a certyfikaty według starego wydania wygasły albo zostały wycofane.

Zakres systemu

Norma pozwala organizacji samej określić granice systemu (pkt 4.3 normy PN-EN ISO/IEC 27001:2023-08). W praktyce certyfikat często obejmuje centrum danych, dział IT albo jedną linię biznesową, bo taki zakres łatwiej przeprowadzić przez audyt. Ustawa o KSC wyznacza zakres inaczej: SZBI obejmuje system informacyjny wykorzystywany w procesach wpływających na świadczenie usługi (art. 8 ust. 1).

Ministerstwo radzi zacząć od procesów świadczenia usługi, a w nich szukać systemów, bez których usługi nie da się świadczyć albo których awaria może ją zatrzymać. Podaje też przykład systemów księgowych, które w podmiocie publicznym bywają niezbędne do realizacji świadczeń (FAQ, pytanie 3.4). Dla firmy z certyfikatem pierwsze ćwiczenie jest proste: położyć zakres z certyfikatu obok listy usług z wykazu i listy systemów, od których te usługi zależą, łącznie z OT, chmurą i systemami dostawców.

Szacowanie ryzyka

Norma wymaga identyfikowania ryzyk związanych z utratą poufności, integralności i dostępności informacji w zakresie systemu (pkt 6.1.2 normy). Ustawa mówi o ryzyku wystąpienia incydentu (art. 8 ust. 1 pkt 1 ustawy o KSC), a proporcjonalność środków mierzy także skutkami społecznymi i gospodarczymi. Metodyka, która liczy wyłącznie stratę dla firmy, nie zobaczy szpitala bez wyników badań ani gminy bez wody.

Dopisuję więc do skali skutków wpływ na usługę: liczbę odbiorców, czas przerwy i obszar. To te same wielkości, od których zależą progi incydentu poważnego (art. 11 ust. 4 ustawy o KSC), więc szacowanie ryzyka i klasyfikacja incydentów korzystają z tej samej skali.

Deklaracja stosowania

Norma wymaga, żeby deklaracja stosowania uzasadniała pominięcie każdego zabezpieczenia z załącznika A (pkt 6.1.3 lit. d normy). Organizacja może więc wyłączyć zabezpieczenie, jeśli jej szacowanie ryzyka to uzasadnia. Obszarów z art. 8 ust. 1 pkt 2 ustawy o KSC nie wyłącza się w ten sposób: ustawa wymienia je jako elementy systemu, a proporcjonalność dotyczy tego, jak głęboko je wdrożyć. Część ma własne zastrzeżenie, jak „w stosownych przypadkach” przy szyfrowaniu i uwierzytelnianiu wieloskładnikowym.

W praktyce dopisuję do deklaracji stosowania kolumnę z odesłaniem do litery art. 8 ust. 1 pkt 2 i sprawdzam, czy każda litera ma przypisane zabezpieczenie, dowód i właściciela. Litery, przy których zostaje puste pole, są listą luk dla zarządu.

Incydenty

Zabezpieczenia z grupy 5.24 do 5.28 załącznika A normy opisują zarządzanie incydentami, ale nie znają terminów. Ustawa zna: wczesne ostrzeżenie o incydencie poważnym do CSIRT sektorowego w ciągu 24 godzin od wykrycia (art. 11 ust. 1 pkt 4 ustawy o KSC), zgłoszenie w ciągu 72 godzin (pkt 4a) i sprawozdanie końcowe w ciągu miesiąca (pkt 4c), wszystko przez system S46, czyli system teleinformatyczny z art. 46 ust. 1. Procedura z systemu zgodnego z normą zwykle kończy się na „powiadom zespół bezpieczeństwa”. Trzeba ją uzupełnić o klasyfikację według progów, osobę, która wysyła zgłoszenie, i zastępstwo na noc i weekend.

Kierownik i przegląd zarządzania

Norma wymaga przywództwa najwyższego kierownictwa (pkt 5.1 normy) i przeglądu zarządzania w zaplanowanych odstępach czasu (pkt 9.3 normy). Ustawa idzie dalej, bo przypisuje kierownikowi decyzje o systemie (art. 8d pkt 1 ustawy o KSC), osobistą odpowiedzialność, która nie przechodzi na osobę, której powierzył zadania (art. 8c ust. 3), i coroczne szkolenie (art. 8e). W wielu systemach, które widziałem, przegląd zarządzania to prezentacja pełnomocnika i podpis prezesa pod protokołem. Po nowelizacji protokół powinien pokazywać decyzje kierownika: jakie ryzyko akceptuje, na co daje pieniądze, czego nie finansuje i dlaczego.

Dokumentacja i ludzie

Art. 10 ust. 3 ustawy o KSC wymienia dokumentację normatywną, której norma nie wymaga w tej postaci: dokumentację ochrony infrastruktury, dokumentację systemu zarządzania ciągłością działania i dokumentację techniczną systemu informacyjnego. Art. 10 ust. 4 zalicza do dokumentacji operacyjnej także automatycznie generowane zapisy w dziennikach systemów. Do tego dochodzi warunek z art. 8f ust. 1: osoba, która realizuje zadania z art. 8 lub art. 11, przed ich rozpoczęciem przedstawia informację z Krajowego Rejestru Karnego o niekaralności za przestępstwa przeciwko ochronie informacji. Dotyczy to także administratorów i zewnętrznego dostawcy, jeśli wykonują te zadania.

Audyt

Audyt certyfikacyjny sprawdza zgodność z normą w zakresie certyfikatu. Audyt z art. 15 ustawy o KSC dotyczy systemu informacyjnego wykorzystywanego w procesie świadczenia usługi i ma swoje wymagania co do audytorów (art. 15 ust. 2). Moim zdaniem oba da się zaplanować razem, jeśli audytorzy spełniają warunki ustawy, a raport odpowiada na jej wymagania, ale jeden nie zastępuje drugiego z samego faktu, że się odbył. Audytu z art. 15 nie przeprowadzi osoba, która w podmiocie realizuje zadania z art. 8 lub art. 9 do 13, ani taka, która robiła to w ciągu roku przed audytem (art. 15 ust. 2a ustawy o KSC).

Numery w drugiej kolumnie to punkty i zabezpieczenia normy PN-EN ISO/IEC 27001:2023-08, polskiego wydania ISO/IEC 27001:2022. Tabela jest moim skrótem, nie wykładnią: przy każdej pozycji sprawdź brzmienie przepisu i normy.

Firmy, które przed nowelizacją były operatorami usług kluczowych, mają przepis przejściowy. Do czasu wdrożenia systemu zgodnego z nowym art. 8 ustawy o KSC stosują SZBI zgodny z art. 8 ustawy o KSC w dotychczasowym brzmieniu (art. 33 ust. 6 ustawy nowelizującej). Stary system nie przestaje więc obowiązywać z dnia na dzień, ale to też nie jest powód, żeby czekać z analizą luk do 2027 r.

A co z urzędem, który ma SZBI z KRI?

Podmioty realizujące zadania publiczne mają SZBI od lat, z § 19 rozporządzenia w sprawie Krajowych Ram Interoperacyjności. Ten przepis wymaga między innymi okresowych analiz ryzyka, aktualnej inwentaryzacji sprzętu i oprogramowania oraz audytu wewnętrznego „nie rzadziej niż raz na rok”, a system oparty na Polskiej Normie PN-ISO/IEC 27001 uznaje za spełniający te wymagania (§ 19 ust. 3).

Takiego domniemania nie ma w ustawie o KSC. Urząd, który jest podmiotem kluczowym, realizuje pełny art. 8 ust. 1 ustawy o KSC, a urząd, który jest podmiotem ważnym, załącznik nr 4. Oba reżimy działają obok siebie i nie widzę powodu, żeby budować dwa systemy. Jeden SZBI z jednym rejestrem ryzyka może spełniać § 19 KRI i ustawę o KSC jednocześnie, pod warunkiem że w dokumentacji widać, który element odpowiada na który przepis.

Gdzie w SZBI są dane osobowe?

RODO nie używa słowa SZBI, ale wymaga tego samego mechanizmu. Art. 32 ust. 1 RODO nakazuje środki, które zapewnią „stopień bezpieczeństwa odpowiadający temu ryzyku”, w tym „regularne testowanie, mierzenie i ocenianie skuteczności środków technicznych i organizacyjnych”. Art. 24 ust. 1 RODO wymaga, żeby administrator mógł zgodność wykazać, a środki były w razie potrzeby przeglądane i uaktualniane.

Różnica leży w tym, czyje ryzyko się liczy. RODO wymaga patrzenia na ryzyko naruszenia praw lub wolności osób fizycznych, norma na ryzyko dla informacji organizacji, ustawa o KSC na ryzyko incydentu i jego wpływ na usługę. Prowadzę jeden rejestr ryzyka z trzema kolumnami skutków, zamiast trzech rejestrów, które po roku opisują trzy różne firmy.

To samo zdarzenie bywa incydentem poważnym i naruszeniem ochrony danych osobowych. Wtedy biegną dwa terminy: 24 i 72 godziny od wykrycia do CSIRT sektorowego (art. 11 ust. 1 pkt 4 i 4a ustawy o KSC) oraz 72 godziny od stwierdzenia naruszenia do Prezesa UODO (art. 33 ust. 1 RODO). Procedura obsługi incydentów w SZBI powinna prowadzić obie ścieżki od pierwszej godziny i mieć w obiegu inspektora ochrony danych (IOD). Tematy RODO opisuję szerzej na pawel.rosol.pl.

Jakie błędy widzę przy wdrażaniu SZBI?

Te same wzorce wracają w firmach prywatnych, spółkach komunalnych i urzędach. Opisuję je z własnej praktyki, bez nazw, ale nie jest to tylko moja obserwacja. NIK skontrolowała 24 jednostki samorządu terytorialnego (raport z lutego 2025 r.): osiem nie opracowało i nie wdrożyło SZBI, w trzech kolejnych nie przeglądano go pod względem adekwatności i skuteczności, a w dziewięciu urzędach w 2023 r. nie przeprowadzono obowiązkowego audytu albo prowadzono go „nierzetelnie, bądź z naruszeniem zasady niezależności i obiektywizmu audytu”.

1. Kupiona dokumentacja. Komplet polityk z szablonu, z nazwą firmy wstawioną w stopkę. Ministerstwo Cyfryzacji pisze o tym bez ogródek: „Kupiona dokumentacja, podpisana przez zarząd i schowana w »szafie NIS2« nie zapewni realnego cyberbezpieczeństwa w organizacji” (FAQ, pytanie 3.7). Szablon zdradza się szybko: procedura nakazuje zgłaszać incydenty do działu, którego w firmie nie ma.
2. Zakres dobrany pod certyfikat. System obejmuje serwerownię, a usługa zależy od systemu w chmurze, sterowników na obiektach i firmy, która zdalnie utrzymuje aplikację.
3. Szacowanie ryzyka zrobione raz. Arkusz przygotowany przed pierwszym audytem, z pożarem, powodzią i „atakiem hakerskim” w pierwszych wierszach, nigdy potem nieotwarty. Ustawa wymaga szacowania „systematycznego” (art. 8 ust. 1 pkt 1 ustawy o KSC), a norma ponownego szacowania w zaplanowanych odstępach i przy istotnych zmianach (pkt 8.2 normy).
4. Deklaracja stosowania, w której wszystko jest wdrożone. 93 razy „tak” bez odesłania do dowodu. Audytor prosi o log z monitorowania albo o wynik testu odtworzenia kopii i rozmowa się kończy.
5. SZBI jako projekt działu IT. Zarząd podpisuje politykę, a potem o systemie nie słyszy do następnego audytu. Po nowelizacji to się nie broni, bo decyzje o systemie należą do kierownika (art. 8d pkt 1 ustawy o KSC).
6. Audyt wewnętrzny, który robi autor systemu. Norma wymaga doboru audytorów tak, żeby zapewnić obiektywność i bezstronność (pkt 9.2.2 normy), a ustawa zakazuje audytu z art. 15 osobie, która realizuje zadania z art. 8 (art. 15 ust. 2a ustawy o KSC). W małej firmie jedyną osobą, która zna system, bywa jego autor, i to jest prawdziwy problem.
7. Procedury, których nikt nie ćwiczył. Plan ciągłości działania, którego nikt nie testował, i kopia zapasowa, której nikt nie odtworzył. O tym, jak to sprawdzić, pisałem w tekście o planie ciągłości działania.
8. Brak miar. Ustawa wymaga polityk i procedur oceny skuteczności środków (art. 8 ust. 1 pkt 2 lit. h ustawy o KSC). Bez kilku liczb, które wracają na każdy przegląd, nie da się powiedzieć, czy system działa, więc przegląd kończy się stwierdzeniem, że działa.
9. Dostawcy poza systemem. Firma zewnętrzna ma dostęp administracyjny, a umowa nie mówi nic o incydentach, logach ani terminie powiadomienia. Przy łańcuchu dostaw art. 8 ust. 2 ustawy o KSC wymaga uwzględnienia podatności dostawcy i ogólnej jakości jego produktów i usług.

Przy każdym z tych błędów system istnieje na papierze, a nikt z zarządu nie potrafi powiedzieć, jakie ryzyko zaakceptował i dlaczego.

Po co w tym pełnomocnik ds. cyberbezpieczeństwa?

Pełnomocnik ds. cyberbezpieczeństwa to nazwa praktyki, a nie funkcja z ustawy. Ustawa o KSC nakłada obowiązki na kierownika (art. 8d) i na podmiot (art. 8), a wykonanie zadań z art. 8 i art. 9 do 13 pozwala powierzyć wewnętrznym strukturom albo dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa (art. 14). W normie ta sama rola to zwykle osoba, której najwyższe kierownictwo przypisało odpowiedzialność i uprawnienia za system (pkt 5.3 normy).

W SZBI pełnomocnik robi to, czego nie zrobi ani zarząd, ani dział IT. Szacowanie ryzyka prowadzi z ludźmi z biznesu, a nie tylko z informatykami, i pilnuje, żeby deklaracja stosowania, polityki i dowody zgadzały się z tym, co się dzieje w firmie. Kierownikowi przygotowuje decyzje w formie, którą da się podpisać i obronić przed organem: warianty, koszty i ryzyko, które zostaje.

Przy incydencie koordynuje klasyfikację i zgłoszenia w terminach z art. 11 ustawy o KSC i spina tę ścieżkę z IOD. Przegląd zarządzania prowadzi tak, żeby kończył się decyzjami. Ma też przewagę, której nie ma administrator: nie ocenia własnej konfiguracji.

Pełnomocnik, który nie administruje systemami, może zapytać o dowód bez konfliktu interesów i przynieść kierownikowi odpowiedź, której ten potrzebuje.

Są dwie granice, które trzeba znać. Odpowiedzialność zostaje przy kierowniku także po powierzeniu zadań (art. 8c ust. 3 ustawy o KSC), więc pełnomocnik nie „załatwia tematu”, tylko sprawia, że kierownik ma na czym oprzeć decyzje. Pełnomocnik, który wykonuje zadania z art. 8, nie przeprowadzi też w tym podmiocie audytu z art. 15 (art. 15 ust. 2a). Co dokładnie można mu powierzyć, a co kierownik robi sam, opisałem w tekście Co kierownik podmiotu może powierzyć pełnomocnikowi, a zakres, w którym pracuję, jest na stronie Usługi.

Od czego zacząć?

Firmie, która ma system zgodny z ISO/IEC 27001 i podlega ustawie o KSC, zaproponowałbym pięć kroków w tej kolejności:

1. porównanie zakresu certyfikatu z listą usług i systemów, od których te usługi zależą;
2. dopisanie do deklaracji stosowania kolumny z literami art. 8 ust. 1 pkt 2 ustawy o KSC i wskazanie pustych pól;
3. uzupełnienie metodyki szacowania ryzyka o wpływ na usługę i o skutki dla osób, których dane są przetwarzane;
4. przepisanie procedury obsługi incydentów pod terminy 24 i 72 godzin, progi i system S46, z ćwiczeniem przy udziale zarządu;
5. protokół z decyzją kierownika: plan usunięcia luk, budżet i osoba odpowiedzialna.

Podmiot, który wyrobi się z tym przed 3 kwietnia 2027 r., będzie miał jeszcze rok zapasu przed pierwszym audytem z art. 15, jeśli jest podmiotem kluczowym. Ten rok warto przeznaczyć na to, żeby system zebrał dowody działania, bo audytor będzie o nie pytał.

Stan prawny sprawdzony: 30.09.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).