NIS2 po wpisie do Wykazu KSC. Co firma musi wdrożyć do 3 kwietnia 2027 r.?

Wpis do Wykazu KSC nie oznacza, że przedsiębiorstwo spełniło już wymagania NIS2. To dopiero pierwszy etap. Do 3 kwietnia 2027 r. podmioty kluczowe i ważne, które były objęte nowymi przepisami od 3 kwietnia 2026 r., muszą zasadniczo wdrożyć system zarządzania bezpieczeństwem informacji (SZBI), odpowiednie zabezpieczenia techniczne i organizacyjne, procedury obsługi incydentów oraz przygotować się do korzystania z Systemu S46.

Dla zarządów oznacza to konieczność podjęcia konkretnych decyzji dotyczących bezpieczeństwa, budżetu, odpowiedzialności pracowników i współpracy z dostawcami IT.

Samo zakupienie oprogramowania antywirusowego, zlecenie audytu informatycznego czy przygotowanie polityki bezpieczeństwa nie wystarczy.

Przedsiębiorstwo musi być w stanie wykazać, że rzeczywiście zna swoje ryzyka, podejmuje działania służące ich ograniczeniu oraz potrafi odpowiednio zareagować na cyberatak.

W praktyce pojawia się kilka pytań. Od czego rozpocząć wdrożenie NIS2? Czy trzeba zatrudnić specjalistę ds. cyberbezpieczeństwa? Jakie dokumenty będą potrzebne podczas kontroli? Czy posiadanie certyfikatu ISO 27001 zwalnia z części obowiązków? I wreszcie: kto odpowiada, jeżeli system bezpieczeństwa zawiedzie?

Poniżej przedstawiamy praktyczny plan przygotowania przedsiębiorstwa do nowych wymagań, z uwzględnieniem obowiązków zarządu, dokumentacji, incydentów oraz terminów wynikających z polskiej ustawy o krajowym systemie cyberbezpieczeństwa.

Stan prawny: 26 października 2026 r.

1. Firma została wpisana do Wykazu KSC. Co powinna zrobić w pierwszej kolejności?

Czy wpis do Wykazu KSC oznacza zgodność z NIS2?

Nie. Wpis potwierdza ujęcie przedsiębiorstwa w wykazie podmiotów kluczowych lub ważnych, ale nie zastępuje realizacji obowiązków z zakresu cyberbezpieczeństwa.

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, wdrażająca dyrektywę NIS2, weszła w życie 3 kwietnia 2026 r.

Podmioty spełniające ustawowe kryteria już w tej dacie zostały objęte harmonogramem, zgodnie z którym:

Termin	Co powinno nastąpić?
3 października 2026 r.	Upływ terminu na złożenie wniosku o wpis do Wykazu KSC dla podmiotów podlegających samorejestracji
3 kwietnia 2027 r.	Wdrożenie nowych obowiązków w zakresie cyberbezpieczeństwa oraz rozpoczęcie korzystania z Systemu S46
3 kwietnia 2028 r.	Termin pierwszego obowiązkowego audytu dla określonych podmiotów kluczowych, które nie były wcześniej operatorami usług kluczowych, oraz początek stosowania przepisów o karach pieniężnych według harmonogramu nowelizacji

Terminy te odnoszą się do podmiotów, które spełniały odpowiednie przesłanki już 3 kwietnia 2026 r. W przypadku przedsiębiorstw, które zostały objęte ustawą później, poszczególne terminy należy ustalić indywidualnie.

Co ważne, termin 3 kwietnia 2027 r. nie oznacza wyłącznie obowiązku rozpoczęcia prac nad cyberbezpieczeństwem.

Do tego czasu wymagane rozwiązania powinny zostać wdrożone i funkcjonować w organizacji.

Nie wystarczy więc przygotować harmonogramu, zgodnie z którym wdrożenie rozpocznie się dopiero w kwietniu.

O tym, które przedsiębiorstwa podlegają ustawie, pisaliśmy w artykule „NIS2 w Polsce 2026 – czy Twoja firma podlega KSC?”.

Pierwsza decyzja zarządu: kto odpowiada za wdrożenie?

Załóżmy, że spółka produkcyjna została wpisana do Wykazu KSC w październiku 2026 r.

Zarząd przekazuje informację dyrektorowi IT, który odpowiada, że firma posiada firewall, kopie zapasowe oraz oprogramowanie antywirusowe. Jego zdaniem zabezpieczenia są wystarczające.

Czy w takiej sytuacji przedsiębiorstwo może uznać wdrożenie NIS2 za zakończone?

Nie.

Dyrektor IT może odpowiadać za techniczne zabezpieczenia, ale niekoniecznie za ocenę ryzyka prawnego, przygotowanie polityk, organizację obowiązków sprawozdawczych, kontrolę dostawców lub zapewnienie ciągłości działania całej organizacji.

NIS2 wymaga połączenia tych obszarów.

Dlatego jedną z pierwszych decyzji powinno być formalne ustalenie osób odpowiedzialnych za poszczególne zadania.

W dobrze zaprojektowanym modelu organizacyjnym należy wskazać przynajmniej:

osobę odpowiedzialną za koordynowanie wdrożenia;
osoby odpowiedzialne za bezpieczeństwo systemów oraz zarządzanie ryzykiem;
osobę odpowiedzialną za zgodność z wymaganiami prawnymi;
osoby odpowiedzialne za obsługę i zgłaszanie incydentów;
członka zarządu nadzorującego realizację projektu.

Nie oznacza to, że każda organizacja musi utworzyć pięć nowych stanowisk.

Zakres obowiązków może zostać odpowiednio podzielony pomiędzy istniejący personel, a część zadań można powierzyć podmiotom zewnętrznym. Trzeba jednak zapewnić rzeczywistą możliwość ich wykonywania.

Komentarz ekspercki Pasternak Business Law

Wdrożenia NIS2 nie warto rozpoczynać od zamawiania obszernego pakietu dokumentacji. Pierwszym zadaniem powinno być ustalenie, kto podejmuje decyzje dotyczące cyberbezpieczeństwa, kto ma dostęp do informacji o zagrożeniach i kto może uruchomić procedury awaryjne.

Jeżeli przedsiębiorstwo nie potrafi odpowiedzieć na te pytania, same dokumenty nie zapewnią zgodności z ustawą.

Osoby kontaktowe, niekaralność i aktualizacja danych w KSC

Po dokonaniu wpisu należy również sprawdzić, czy organizacja prawidłowo wyznaczyła osoby odpowiedzialne za kontakt w ramach krajowego systemu cyberbezpieczeństwa.

Co do zasady powinny być to co najmniej dwie osoby. W przypadku mikroprzedsiębiorców i małych przedsiębiorców ustawodawca przewidział możliwość wskazania co najmniej jednej osoby, zgodnie z właściwymi przepisami.

Nie wystarczy przy tym wskazać nazwiska osoby, która nie zna swojej roli.

Osoby kontaktowe powinny wiedzieć, jakie informacje będą do nich kierowane, kto zastępuje je podczas nieobecności i komu przekazują komunikaty wymagające reakcji.

Istotna jest także weryfikacja niekaralności osób realizujących określone zadania z zakresu zarządzania cyberbezpieczeństwem i obsługi incydentów, zgodnie z zakresem wymaganym przez ustawę.

Warto pamiętać o jeszcze jednym obowiązku, często pomijanym po zakończeniu rejestracji.

Zmiany określonych danych w Wykazie KSC należy zgłaszać w terminie 14 dni od ich wystąpienia. Wynika to z art. 7c ust. 3 ustawy o KSC i dotyczy danych wskazanych w art. 7 ust. 2 pkt 1–18.

Zmiana osób kontaktowych, istotnych danych organizacyjnych czy informacji objętych ustawowym obowiązkiem aktualizacji powinna więc uruchamiać odpowiednią procedurę.

System S46 – czy trzeba z niego korzystać już po wpisie?

System S46 jest narzędziem wspierającym wymianę informacji i realizację zadań w ramach krajowego systemu cyberbezpieczeństwa.

W przypadku podmiotów objętych harmonogramem przejściowym obowiązek rozpoczęcia korzystania z systemu przypada zasadniczo na 3 kwietnia 2027 r. Dostęp do S46 może być jednak możliwy już po uzyskaniu wpisu do wykazu.

Nie warto zostawiać konfiguracji systemu na ostatni tydzień przed upływem terminu.

Organizacja powinna wcześniej wyznaczyć administratora, zweryfikować uprawnienia użytkowników, ustalić sposób odbierania komunikatów oraz przeszkolić osoby odpowiedzialne za zgłaszanie incydentów.

Oficjalne informacje i dostęp do odpowiednich usług można znaleźć poprzez System S46 oraz Wykaz KSC.

Jeżeli firma w ogóle nie złożyła wymaganego wniosku w terminie, powinna odrębnie uporządkować tę sytuację. Brak rejestracji nie oznacza bowiem, że przedsiębiorca przestaje podlegać pozostałym obowiązkom wynikającym z ustawy.

2. Jakie dokumenty, procedury i zabezpieczenia trzeba wdrożyć zgodnie z NIS2?

SZBI, czyli system zarządzania bezpieczeństwem informacji

Podstawowym obowiązkiem podmiotów kluczowych i ważnych jest wdrożenie systemu zarządzania bezpieczeństwem informacji (SZBI).

Wynika on przede wszystkim z art. 8 ustawy o krajowym systemie cyberbezpieczeństwa.

W praktyce SZBI to sposób organizacji bezpieczeństwa w przedsiębiorstwie. Obejmuje identyfikowanie zagrożeń, ocenę ryzyka, wdrażanie odpowiednich zabezpieczeń, przypisywanie odpowiedzialności oraz regularne sprawdzanie skuteczności przyjętych rozwiązań.

Nie powinien być traktowany wyłącznie jako zbiór procedur.

Dobrze przygotowany SZBI musi uwzględniać rzeczywisty sposób działania firmy, jej systemy, pracowników, dostawców i znaczenie poszczególnych procesów dla ciągłości świadczenia usług.

Inaczej będzie wyglądać system bezpieczeństwa przedsiębiorstwa prowadzącego zakład przetwarzania odpadów, a inaczej dostawcy usług chmurowych.

Pierwsza organizacja może wykorzystywać automatykę przemysłową, systemy sterowania urządzeniami oraz oprogramowanie produkcyjne. Druga może być w znacznie większym stopniu zależna od infrastruktury serwerowej, dostępu do danych i ciągłości usług świadczonych klientom.

W obu przypadkach istotne jest to samo pytanie: co się stanie, jeżeli określony system przestanie działać?

Analiza ryzyka NIS2 – dokument, od którego warto zacząć

Zanim przedsiębiorstwo kupi kolejne zabezpieczenia, powinno wiedzieć, jakie zagrożenia są dla niego najistotniejsze.

Analiza ryzyka powinna obejmować m.in. identyfikację systemów, urządzeń, danych i procesów wykorzystywanych do świadczenia usług.

Następnie należy ocenić prawdopodobieństwo wystąpienia zagrożeń oraz ich możliwe skutki.

Przykładowo:

Firma wykorzystuje zewnętrzny system ERP do zarządzania produkcją i realizacją zamówień.

Awaria systemu przez dwie godziny powoduje opóźnienia administracyjne.

Niedostępność przez trzy dni może natomiast uniemożliwić realizację dostaw, rozliczenie kontrahentów oraz prawidłowe funkcjonowanie całego przedsiębiorstwa.

Jeżeli dodatkowo system jest zintegrowany z urządzeniami produkcyjnymi, skutki ataku mogą wykraczać poza obszar finansowy i obejmować bezpieczeństwo operacyjne.

W analizie ryzyka należy więc uwzględnić nie tylko możliwość utraty danych, ale również wpływ na wykonywanie usług, bezpieczeństwo ludzi, zobowiązania kontraktowe i współpracę z innymi podmiotami.

Wynikiem analizy powinien być plan postępowania z ryzykiem.

Dla każdego istotnego zagrożenia przedsiębiorstwo powinno określić sposób jego ograniczenia, osobę odpowiedzialną, przewidziane działania i termin realizacji.

Samo stwierdzenie, że ryzyko jest „średnie” albo „wysokie”, nie rozwiązuje jeszcze żadnego problemu.

Dokumentacja NIS2 – co powinna zawierać?

Zakres dokumentacji zależy od wielkości organizacji, jej statusu, rodzaju usług i rzeczywistych zagrożeń.

Nie istnieje jeden uniwersalny pakiet dokumentów, który w niezmienionej postaci będzie odpowiedni dla każdego podmiotu kluczowego i ważnego.

Można jednak wskazać podstawowe obszary, które przedsiębiorstwo powinno objąć dokumentacją oraz faktycznymi procesami zarządzania bezpieczeństwem.

Poniższa tabela przedstawia autorską matrycę przygotowawczą Pasternak Business Law.

Dokument lub obszar	Co powinien regulować?	Jak wykazać jego stosowanie?
Polityka bezpieczeństwa informacji	Zasady ochrony informacji, odpowiedzialność i cele bezpieczeństwa	Zatwierdzona polityka, komunikacja z personelem, przeglądy
Analiza ryzyka	Identyfikacja zagrożeń, ocena skutków i plan działań	Rejestr ryzyk, decyzje o postępowaniu z ryzykiem
Rejestr aktywów	Systemy, urządzenia, dane i osoby odpowiedzialne	Aktualna inwentaryzacja ICT i OT
Zarządzanie dostępem	Nadawanie, zmiana i odbieranie uprawnień	Rejestr uprawnień, okresowe przeglądy
Zarządzanie podatnościami	Wykrywanie, ocena i usuwanie luk bezpieczeństwa	Wyniki skanów, rejestr podatności, historia napraw
Procedura incydentowa	Wykrywanie, klasyfikacja, eskalacja i zgłoszenia do CSIRT	Rejestr incydentów, testy, dokumentacja reakcji
Ciągłość działania i odtwarzanie	Postępowanie podczas awarii i sposób przywrócenia usług	Plany BCP/DR, wyniki testów odtworzeniowych
Bezpieczeństwo dostawców	Ocena ryzyka kontrahentów i wymagania umowne	Oceny dostawców, umowy, przeglądy
Szkolenia i świadomość	Zasady postępowania personelu oraz obowiązki kierownictwa	Program szkoleń, potwierdzenia uczestnictwa
Kontrola skuteczności SZBI	Przeglądy, ocena zabezpieczeń, działania korygujące	Protokoły przeglądów, testy, raporty i decyzje

Tabela ma charakter praktycznej propozycji organizacji dokumentacji. Nie oznacza, że ustawa wymaga dokładnie dziesięciu osobnych dokumentów o wskazanych nazwach.

W części przedsiębiorstw niektóre obszary mogą zostać połączone w jednym dokumencie, a w większych organizacjach będą wymagały rozbudowanych procedur i szczegółowych instrukcji.

Najważniejsze, aby wszystkie wymagane kwestie zostały rzeczywiście uregulowane i były odpowiednio dokumentowane.

Czy do zgodności z NIS2 potrzebny jest certyfikat ISO 27001?

Nie. Samo objęcie przedsiębiorstwa wymaganiami NIS2 nie oznacza automatycznego obowiązku posiadania certyfikatu ISO/IEC 27001.

Norma może jednak stanowić wartościowy punkt odniesienia przy budowaniu systemu zarządzania bezpieczeństwem informacji.

Ministerstwo Cyfryzacji opublikowało również zestawienie dokumentów normalizacyjnych, które pomagają powiązać wymagania ustawy KSC z odpowiednimi normami i standardami.

Warto przy tym odróżnić dwie sytuacje.

Przedsiębiorstwo może posiadać certyfikat ISO 27001, ale nadal nie realizować wszystkich szczególnych obowiązków wynikających z KSC, np. dotyczących zgłaszania incydentów czy organizacji kontaktów z właściwymi podmiotami.

Z drugiej strony organizacja może spełniać wymagania ustawy bez formalnego certyfikatu, o ile jest w stanie wykazać rzeczywiste wdrożenie odpowiedniego systemu bezpieczeństwa.

Certyfikat może być dowodem wspierającym ocenę zgodności, ale nie stanowi automatycznego zwolnienia z obowiązków ustawowych.

Bezpieczeństwo dostawców IT – czy za ich błędy odpowiada firma?

To jeden z najbardziej praktycznych problemów związanych z NIS2.

Przedsiębiorstwa coraz częściej korzystają z zewnętrznych firm informatycznych, dostawców usług chmurowych, operatorów centrów danych, integratorów systemów oraz podmiotów odpowiedzialnych za utrzymanie infrastruktury.

Zlecenie obsługi informatycznej na zewnątrz nie oznacza jednak, że można całkowicie przenieść na dostawcę własne obowiązki wynikające z KSC.

Organizacja powinna odpowiednio oceniać ryzyka występujące w łańcuchu dostaw.

W praktyce oznacza to konieczność sprawdzenia, czy umowy z dostawcami przewidują odpowiednie zasady:

zgłaszania incydentów i informowania o podatnościach;
współpracy przy analizie cyberataków;
stosowania zabezpieczeń i zarządzania dostępem;
zapewnienia ciągłości działania;
wykonywania kopii zapasowych i odtwarzania danych;
współpracy przy kontroli i dokumentowaniu zgodności.

Szczególnie niebezpieczne są umowy, w których dostawca zobowiązuje się jedynie do „zapewnienia wsparcia technicznego”, bez określenia czasu reakcji, odpowiedzialności za incydenty i obowiązku przekazywania informacji.

Jeżeli zewnętrzna firma obsługująca serwery poinformuje o poważnym naruszeniu dopiero po trzech dniach, przedsiębiorca może nie być w stanie dotrzymać ustawowych terminów raportowania.

Dlatego wymagania KSC warto uwzględniać również podczas zawierania i renegocjowania umów technologicznych.

Więcej informacji o zabezpieczaniu takich relacji można znaleźć w obszarze naszej praktyki „Umowy IT”.

Procedura zgłaszania incydentów. Co oznaczają terminy 24 godziny, 72 godziny i jeden miesiąc?

Przedsiębiorstwo objęte KSC musi potrafić rozpoznać incydent, określić jego znaczenie i w odpowiednich przypadkach przekazać wymagane informacje do właściwego zespołu CSIRT.

Zgodnie z art. 11 ustawy o KSC dla typowego podmiotu kluczowego lub ważnego przy incydencie poważnym przewidziano następującą sekwencję:

24 godziny – wczesne ostrzeżenie

Wczesne ostrzeżenie o incydencie poważnym należy przekazać niezwłocznie, nie później niż w ciągu 24 godzin od jego wykrycia.

72 godziny – zgłoszenie incydentu poważnego

W terminie nieprzekraczającym 72 godzin od wykrycia trzeba przekazać zgłoszenie zawierające odpowiednie informacje o zdarzeniu, jego skutkach i podejmowanych działaniach.

Jeden miesiąc – sprawozdanie końcowe

Co do zasady sprawozdanie końcowe należy przekazać nie później niż w ciągu miesiąca od zgłoszenia incydentu. Jeżeli jego obsługa jeszcze się nie zakończyła, zastosowanie znajdują szczególne zasady dotyczące sprawozdania z postępu oraz końcowego rozliczenia incydentu.

Niektóre kategorie podmiotów, w tym dostawcy usług zaufania, podlegają szczególnym zasadom raportowania. Trzeba też uwzględniać właściwy zespół CSIRT i aktualny sposób dokonywania zgłoszeń.

W praktyce największy problem często nie dotyczy jednak samego wysłania formularza.

Problem polega na ustaleniu, kiedy organizacja wykryła incydent, czy jest on poważny i kto ma prawo podjąć decyzję o jego zgłoszeniu.

Wyobraźmy sobie, że pracownik zauważa nietypowe działanie systemu o godzinie 8:00. Administrator otrzymuje informację dopiero o 13:00, a zarząd dowiaduje się o sprawie następnego dnia.

Nawet dobra procedura może okazać się nieskuteczna, jeżeli informacja o incydencie nie jest odpowiednio szybko przekazywana wewnątrz organizacji.

Dlatego należy ustalić jasną ścieżkę eskalacji, dyżury, zastępstwa oraz sposób dokumentowania momentu wykrycia i przebiegu zdarzenia.

Warto także pamiętać, że incydent może jednocześnie powodować obowiązki wynikające z RODO, umów z kontrahentami lub przepisów sektorowych. Zgłoszenie na podstawie KSC nie zastępuje automatycznie innych wymaganych zawiadomień.

Szkolenia pracowników i zarządu – kto musi je przechodzić?

Cyberbezpieczeństwo nie kończy się na wdrożeniu zabezpieczeń technicznych.

Pracownik, który otrzyma fałszywą wiadomość od rzekomego kontrahenta, powinien wiedzieć, jak ją rozpoznać i gdzie zgłosić podejrzenie.

Osoba odpowiedzialna za płatności powinna znać zasady dodatkowej weryfikacji zmiany rachunku bankowego dostawcy.

Administrator systemu powinien wiedzieć, w jaki sposób eskalować wykrytą podatność.

Z kolei zarząd musi rozumieć ryzyka, które mogą zagrozić ciągłości działalności przedsiębiorstwa.

Art. 8d ustawy o KSC określa zadania kierownika podmiotu dotyczące m.in. organizowania, finansowania i nadzorowania realizacji obowiązków z zakresu cyberbezpieczeństwa.

Art. 8e przewiduje natomiast coroczne szkolenie kierownika podmiotu oraz osoby, której powierzono jego obowiązki w zakresie cyberbezpieczeństwa. Udział w takim szkoleniu powinien zostać udokumentowany.

W praktyce warto opracować dwa oddzielne programy:

Dla pracowników: cyberhigiena, phishing, ochrona informacji, hasła, dostęp do systemów, postępowanie w przypadku podejrzanego zdarzenia.

Dla kierownictwa: odpowiedzialność wynikająca z KSC, nadzór nad ryzykiem, finansowanie zabezpieczeń, incydenty, ciągłość działania i zasady kontroli realizacji obowiązków.

Nie chodzi o to, żeby każdy członek zarządu stał się ekspertem od infrastruktury sieciowej.

Chodzi o to, żeby potrafił podejmować świadome decyzje dotyczące bezpieczeństwa firmy.

3. NIS2 w praktyce – przykład firmy, która musi przygotować się do nowych wymagań

Przykład: przedsiębiorstwo zajmujące się gospodarką odpadami

Przeanalizujmy hipotetyczną spółkę działającą w sektorze gospodarowania odpadami.

Przedsiębiorstwo zatrudnia 120 pracowników, prowadzi trzy zakłady sortowania i przetwarzania odpadów oraz świadczy usługi na rzecz klientów biznesowych i samorządowych.

Spółka korzysta z:

systemu ERP obsługującego zamówienia i rozliczenia;
systemów sterowania maszynami i liniami technologicznymi;
zewnętrznej infrastruktury chmurowej;
oprogramowania wykorzystywanego w logistyce i ewidencji;
firmy informatycznej odpowiedzialnej za część utrzymania systemów.

Załóżmy, że na podstawie analizy ustawowych przesłanek została prawidłowo zakwalifikowana jako podmiot ważny i wpisana do Wykazu KSC.

W pierwszej chwili zarząd może uznać, że największym ryzykiem jest utrata danych klientów.

Po przeprowadzeniu dokładniejszej analizy okazuje się jednak, że poważniejszym zagrożeniem może być zatrzymanie systemu sterowania linią sortowniczą.

Taki incydent może uniemożliwić wykonywanie usług, spowodować zaległości w odbiorze i przetwarzaniu odpadów oraz narazić firmę na roszczenia kontrahentów.

Dodatkowo zewnętrzny dostawca IT posiada zdalny dostęp do części infrastruktury. Jeżeli jego konto zostanie przejęte, atak może zostać przeprowadzony również przez ten kanał.

Jak w takim przypadku podejść do NIS2?

Pięć zagadnień wymagających rozstrzygnięcia

1. Co jest rzeczywiście krytyczne dla funkcjonowania spółki?

Nie każda aplikacja ma takie samo znaczenie.

Niedostępność firmowego intranetu może być uciążliwa, ale zatrzymanie systemu sterowania produkcją może uniemożliwić realizację podstawowych usług.

Analiza ryzyka musi odzwierciedlać te różnice.

2. Kto odpowiada za systemy IT i OT?

W przedsiębiorstwach przemysłowych często występuje podział pomiędzy klasycznymi systemami informatycznymi (IT) i technologią operacyjną (OT), służącą np. do sterowania urządzeniami.

Nie zawsze obie części infrastruktury są zarządzane przez tę samą osobę.

Trzeba więc ustalić odpowiedzialność, zasady współpracy i sposób reagowania na zagrożenia obejmujące obydwa obszary.

3. Czy kopie zapasowe rzeczywiście pozwalają odtworzyć działalność?

Posiadanie kopii danych nie oznacza automatycznie zdolności do przywrócenia usług.

Warto wykonać test odtworzeniowy i sprawdzić, czy przedsiębiorstwo potrafi przywrócić wymagane funkcje w czasie akceptowalnym dla prowadzonej działalności.

W tym miejscu szczególne znaczenie mają cele RTO i RPO, czyli dopuszczalny czas przywrócenia działania oraz akceptowalny zakres utraty danych.

4. Co przewiduje umowa z zewnętrzną firmą IT?

Jeżeli dostawca odpowiada za określone systemy, powinien mieć jasno określone obowiązki dotyczące bezpieczeństwa, informowania o incydentach, zarządzania dostępem i współpracy podczas awarii.

Ogólna klauzula o świadczeniu usług informatycznych może nie wystarczyć.

5. Czy spółka potrafi wykazać, że rzeczywiście zarządza ryzykiem?

W przypadku kontroli znaczenie mogą mieć nie tylko polityki, ale także rejestry ryzyk, potwierdzenia szkoleń, wyniki testów, dokumenty dotyczące usuwania podatności, oceny dostawców i protokoły decyzji zarządu.

Na potrzeby takiego przedsiębiorstwa można przygotować następującą uproszczoną mapę:

Ryzyko	Możliwy skutek	Przykładowe działanie
Ransomware w systemie ERP	Brak możliwości rozliczania i obsługi zamówień	Segmentacja, kopie zapasowe, test odtwarzania
Przejęcie dostępu do OT	Zatrzymanie linii technologicznej	Kontrola dostępu, segmentacja sieci, monitoring
Awaria zewnętrznej chmury	Niedostępność usług i danych	Plan ciągłości, ocena dostawcy, procedura awaryjna
Błąd pracownika	Ujawnienie danych lub uzyskanie nieautoryzowanego dostępu	Szkolenia, MFA, ograniczanie uprawnień
Opóźnione zgłoszenie incydentu przez dostawcę	Ryzyko niedotrzymania terminów KSC	Wymagania umowne, procedura eskalacji
Brak dokumentacji decyzji	Trudność wykazania należytego nadzoru	Rejestry, protokoły, cykliczne raportowanie zarządowi

To oczywiście tylko przykładowy model analityczny, a nie kompletna ocena ryzyka. Rzeczywista dokumentacja powinna uwzględniać szczegółowy charakter działalności, wykorzystywane technologie oraz konkretne wymagania ustawowe.

Wniosek z analizy

Najważniejszą korzyścią z prawidłowego wdrożenia NIS2 nie jest samo posiadanie kompletu procedur.

Jest nią zdolność przedsiębiorstwa do zachowania ciągłości działania, ograniczania skutków cyberataków oraz podejmowania decyzji na podstawie rzeczywistych informacji o ryzyku.

Właśnie dlatego prawidłowe wdrożenie KSC powinno łączyć zagadnienia prawne, techniczne, operacyjne i organizacyjne.

4. Jak przygotować firmę do 3 kwietnia 2027 r.? Harmonogram, audyt i odpowiedzialność zarządu

Plan wdrożenia NIS2 od listopada 2026 r. do kwietnia 2027 r.

Od publikacji niniejszego artykułu do głównego terminu wdrożenia pozostało nieco ponad pięć miesięcy.

To wystarczający czas, aby zaplanować i przeprowadzić wiele działań, ale w przypadku rozbudowanych organizacji nie powinien być traktowany jako duży zapas.

Proponujemy następującą kolejność prac:

Termin	Rekomendowane działania	Rezultat
Listopad 2026	Audyt stanu obecnego, identyfikacja procesów i zasobów, ustalenie odpowiedzialności	Mapa luk i plan wdrożenia
Grudzień 2026	Analiza ryzyka, ocena dostawców, ustalenie zabezpieczeń i budżetu	Rejestr ryzyk, plan postępowania z ryzykiem
Styczeń 2027	Przygotowanie i wdrożenie SZBI, procedur oraz wymaganych zmian umownych	Obowiązujące dokumenty i przypisane obowiązki
Luty 2027	Wdrożenie zabezpieczeń, konfiguracja S46, szkolenia i przygotowanie procedur incydentowych	Funkcjonujące mechanizmy techniczne i organizacyjne
Marzec 2027	Testy, ćwiczenia incydentowe, kontrola dokumentacji i usunięcie istotnych braków	Potwierdzenie gotowości organizacji
Do 3 kwietnia 2027	Weryfikacja spełnienia obowiązków objętych terminem dostosowawczym	Udokumentowane wdrożenie wymaganych rozwiązań

Jest to autorski harmonogram organizacyjny, nie ustawowy podział projektu na etapy.

W niektórych przedsiębiorstwach prace nad dokumentacją i zabezpieczeniami będą musiały toczyć się równolegle.

Jeżeli analiza wykaże istotne luki, takie jak brak możliwości odtworzenia krytycznych systemów, niewłaściwie zabezpieczony dostęp zdalny lub brak osoby odpowiedzialnej za incydenty, ich usunięcie nie powinno czekać do marca.

Co powinien otrzymać zarząd przed zatwierdzeniem wdrożenia?

W ocenie Pasternak Business Law jednym z najbardziej użytecznych narzędzi nadzoru jest krótki raport gotowości przedstawiany zarządowi.

Nie musi mieć kilkudziesięciu stron.

Powinien jednak umożliwiać podjęcie świadomej decyzji, czy organizacja jest odpowiednio przygotowana i które ryzyka pozostają nierozwiązane.

Przed zakończeniem wdrożenia zarząd powinien uzyskać odpowiedzi na następujące pytania:

Czy znamy wszystkie systemy i procesy istotne dla świadczenia naszych usług?
Czy przeprowadziliśmy ocenę ryzyka i zatwierdziliśmy sposób postępowania z najważniejszymi zagrożeniami?
Czy dokumentacja bezpieczeństwa została formalnie przyjęta i jest stosowana?
Czy nasi pracownicy wiedzą, co robić w przypadku incydentu?
Czy możemy odtworzyć krytyczne systemy w czasie wymaganym dla prowadzenia działalności?
Czy dostawcy IT są objęci odpowiednimi wymaganiami bezpieczeństwa?
Czy mamy zapewniony dostęp do S46 i ustaloną procedurę zgłoszeń?
Czy mamy dokumenty potwierdzające wdrożenie oraz wykonywanie obowiązków?

Odpowiedź „dział IT potwierdził, że wszystko działa” może być niewystarczająca.

W szczególności w przypadku wykrycia poważnych nieprawidłowości zarząd powinien wiedzieć, jakie ryzyko zaakceptował, dlaczego podjął taką decyzję i jakie działania naprawcze zostały zaplanowane.

Kiedy trzeba przeprowadzić pierwszy audyt NIS2?

Warto odróżnić audyt służący przygotowaniu organizacji do nowych wymagań od ustawowego audytu cyberbezpieczeństwa.

Podmioty kluczowe, które nie były wcześniej operatorami usług kluczowych, mają zasadniczo czas do 3 kwietnia 2028 r. na przeprowadzenie pierwszego obowiązkowego audytu.

W przypadku dotychczasowych operatorów usług kluczowych zastosowanie mają odrębne zasady kontynuowania cyklu audytowego.

Kolejne obowiązkowe audyty przeprowadza się co najmniej raz na trzy lata, zgodnie z właściwymi przepisami.

Co ważne, nie należy automatycznie przenosić tego obowiązku na wszystkie podmioty ważne.

Ustawa różnicuje zakres i mechanizmy nadzoru nad poszczególnymi kategoriami podmiotów.

Czy w takim razie przedsiębiorstwo może poczekać z oceną stanu bezpieczeństwa do 2028 r.?

Nie jest to rozsądne podejście.

Jeżeli organizacja ma wdrożyć wymagania do kwietnia 2027 r., wcześniejszy audyt luk lub niezależny przegląd gotowości może pomóc wykryć problemy jeszcze przed upływem terminu.

Taki przegląd nie musi być tożsamy z obowiązkowym audytem ustawowym.

Jakie kary grożą za niewdrożenie NIS2?

Nowelizacja KSC przewiduje administracyjne kary pieniężne oraz szereg środków nadzorczych.

W odniesieniu do najpoważniejszych naruszeń przepisy przewidują wysokie maksymalne kary, zależne od kategorii podmiotu.

Dla podmiotów kluczowych zasadnicze górne granice mogą odpowiadać kwocie 10 mln euro albo 2% właściwych przychodów, a dla podmiotów ważnych 7 mln euro albo 1,4% przychodów, z zastosowaniem ustawowych zasad obliczania kary.

Nie oznacza to, że za każde uchybienie przedsiębiorca otrzyma karę w takiej wysokości.

Organ powinien brać pod uwagę charakter naruszenia, jego wagę, okoliczności sprawy oraz reguły przewidziane w ustawie.

Według harmonogramu Ministerstwa Cyfryzacji przepisy o administracyjnych karach pieniężnych zaczną być stosowane zasadniczo od 3 kwietnia 2028 r.

Nie oznacza to jednak, że do tej daty można ignorować obowiązki KSC.

Po pierwsze, część obowiązków należy wykonać wcześniej.

Po drugie, organy właściwe dysponują również kompetencjami nadzorczymi, których nie należy utożsamiać wyłącznie z nakładaniem kar pieniężnych.

Po trzecie, cyberatak może wywołać konsekwencje niezależnie od samej ustawy KSC: roszczenia kontrahentów, odpowiedzialność związaną z ochroną danych osobowych, straty operacyjne czy problemy z realizacją zawartych umów.

Istotne jest również to, że nowelizacja przewiduje osobną odpowiedzialność kierowników podmiotów w określonych okolicznościach.

Dlatego bezpieczeństwo informacji powinno być przedmiotem rzeczywistego nadzoru zarządu.

Komentarz eksperta: największy błąd przy wdrażaniu NIS2

Bartosz Pasternak – Pasternak Business Law

Największym błędem jest sprowadzenie NIS2 do projektu informatycznego i przyjęcie, że za zgodność z ustawą odpowiada wyłącznie administrator systemów.

Z prawnego punktu widzenia konieczne jest zapewnienie odpowiedniej organizacji, odpowiedzialności, nadzoru i dokumentowania decyzji.

Można posiadać zaawansowane zabezpieczenia technologiczne, a jednocześnie nie mieć ustalonej procedury zgłaszania incydentów, zasad nadzoru nad dostawcami czy właściwej analizy ryzyka.

Możliwa jest również sytuacja odwrotna: spółka posiada obszerną dokumentację, ale procedury nie są faktycznie wykonywane.

Najważniejsze pytanie nie brzmi więc „czy mamy dokumenty NIS2?”, ale „czy potrafimy wykazać, że organizacja rzeczywiście działa zgodnie z przyjętym systemem bezpieczeństwa?”.

Właśnie to rozróżnienie powinno stanowić punkt wyjścia dla zarządu przygotowującego firmę do kwietnia 2027 r.

5. NIS2 po wpisie do KSC – najczęstsze pytania przedsiębiorców

Czy po wpisie do Wykazu KSC trzeba od razu mieć gotowe wszystkie procedury?

Dla podmiotów objętych okresem dostosowawczym główny termin wdrożenia nowych wymagań przypada zasadniczo na 3 kwietnia 2027 r.

Nie oznacza to jednak odroczenia wszystkich obowiązków wynikających z ustawy, w szczególności tych dotyczących wpisu, danych kontaktowych czy ich aktualizacji.

Przedsiębiorstwo powinno przeanalizować właściwy harmonogram i rozpocząć prace odpowiednio wcześniej.

Ile dokumentów NIS2 musi posiadać firma?

Nie ma jednej, ustawowej liczby dokumentów właściwej dla wszystkich przedsiębiorstw.

Organizacja musi wdrożyć wymagane rozwiązania i odpowiednio je udokumentować. Zakres oraz szczegółowość dokumentacji powinny odpowiadać działalności, skali przedsiębiorstwa i występującym ryzykom.

Czy podmiot ważny musi wdrożyć SZBI?

Tak. Obowiązek wdrożenia systemu zarządzania bezpieczeństwem informacji dotyczy zarówno podmiotów kluczowych, jak i podmiotów ważnych objętych odpowiednimi przepisami KSC.

Różnice między tymi kategoriami dotyczą m.in. określonych mechanizmów nadzoru, audytów i sankcji, a nie całkowitego zwolnienia podmiotów ważnych z zarządzania cyberbezpieczeństwem.

Czy posiadanie ISO 27001 wystarczy do spełnienia NIS2?

Nie automatycznie. System zgodny z ISO 27001 może znacząco ułatwić realizację obowiązków, ale trzeba zweryfikować wymagania szczególne wynikające z ustawy KSC.

Samo posiadanie certyfikatu nie zastępuje wszystkich obowiązków dotyczących m.in. zgłaszania incydentów, relacji z właściwymi podmiotami i dokumentacji organizacyjnej.

Czy NIS2 wymaga zatrudnienia osobnego specjalisty ds. cyberbezpieczeństwa?

Nie istnieje jeden uniwersalny obowiązek zatrudnienia odrębnego pracownika na stanowisku CISO w każdej organizacji.

Podmiot musi jednak zapewnić odpowiednie zasoby, kompetencje, odpowiedzialność i realizację wymaganych funkcji.

Odpowiedni model zależy od wielkości organizacji, kategorii podmiotu i charakteru świadczonych usług.

Czy outsourcing IT zwalnia zarząd z odpowiedzialności?

Nie. Korzystanie z zewnętrznego dostawcy nie oznacza automatycznego przeniesienia na niego odpowiedzialności przedsiębiorstwa za wykonanie własnych obowiązków regulacyjnych.

Konieczne jest odpowiednie zarządzanie ryzykiem dostawcy, ustalenie wymagań umownych oraz zapewnienie mechanizmów kontroli i nadzoru.

Czy każda firma wpisana do KSC musi przeprowadzić audyt do 3 kwietnia 2028 r.?

Nie. Termin ten dotyczy określonych podmiotów kluczowych, które nie były wcześniej operatorami usług kluczowych.

Inne kategorie podmiotów mogą podlegać odmiennym obowiązkom i zasadom nadzoru. Należy również odróżniać audyt obowiązkowy od dobrowolnego przeglądu zgodności i bezpieczeństwa.

Czy NIS2 i RODO wymagają dwóch osobnych zgłoszeń incydentu?

Mogą wystąpić dwa niezależne obowiązki.

Jeżeli incydent jest poważny w rozumieniu KSC i jednocześnie stanowi naruszenie ochrony danych osobowych podlegające zgłoszeniu na podstawie RODO, przedsiębiorstwo musi przeanalizować oba reżimy.

Zawiadomienie właściwego CSIRT nie oznacza automatycznie wykonania obowiązku zgłoszenia naruszenia ochrony danych osobowych do Prezesa UODO.

Jak sprawdzić, czy przedsiębiorstwo jest gotowe na NIS2?

Najlepszym rozwiązaniem jest przeprowadzenie analizy zgodności obejmującej status regulacyjny, ryzyka, dokumentację, systemy, dostawców, procedury incydentowe i nadzór zarządu.

Wynikiem takiej analizy powinna być lista stwierdzonych luk oraz plan ich usunięcia z przypisanymi odpowiedzialnościami i terminami.

Jak Pasternak Business Law może pomóc we wdrożeniu NIS2?

Pasternak Business Law wspiera przedsiębiorców w zagadnieniach prawa gospodarczego, technologii, cyberbezpieczeństwa i compliance.

Przygotowanie do wymagań KSC wymaga współpracy prawników, osób odpowiedzialnych za bezpieczeństwo informacji, działów IT oraz kierownictwa przedsiębiorstwa.

Pomoc prawna może obejmować analizę statusu podmiotu, identyfikację obowiązków regulacyjnych, przygotowanie dokumentacji organizacyjnej, przegląd umów z dostawcami technologii, ustalenie zasad odpowiedzialności oraz wsparcie we wdrażaniu procedur i obowiązków sprawozdawczych.

W zależności od potrzeb przedsiębiorstwa prace prawne mogą być uzupełniane odpowiednimi analizami technicznymi specjalistów ds. cyberbezpieczeństwa.

Jeżeli Twoja firma została wpisana do Wykazu KSC i przygotowuje się do terminu 3 kwietnia 2027 r., warto rozpocząć od sprawdzenia, które obowiązki są już wykonywane, a które wymagają wdrożenia.

Pozwala to określić zakres prac, uniknąć niepotrzebnych kosztów i skoncentrować zasoby na zagrożeniach mających rzeczywisty wpływ na działalność.

Skontaktuj się z Pasternak Business Law, aby omówić sytuację swojej firmy i zaplanować odpowiednie działania.

Podstawy prawne i źródła

Autor: Bartosz Pasternak, Pasternak Business Law

Prawnik zajmujący się prawem gospodarczym, obsługą przedsiębiorców, projektami technologicznymi oraz zagadnieniami regulacyjnymi i compliance.

Poznaj autora i kancelarię Pasternak Business Law.

Artykuł ma charakter informacyjny i nie stanowi indywidualnej porady prawnej. Zakres obowiązków KSC zależy od statusu podmiotu, rodzaju działalności oraz innych właściwych przepisów, w tym regulacji sektorowych.