Dyrektywa NIS2 i nowelizacja ustawy o KSC – jakie obowiązki mają firmy i kadra zarządzająca?

Czym są NIS2 i nowelizacja ustawy o KSC oraz dlaczego są ważne?

Cyberatak może zatrzymać produkcję, odciąć dostęp do usług lub zakłócić działalność wielu organizacji korzystających z tego samego dostawcy. Dlatego europejskie przepisy o cyberbezpieczeństwie koncentrują się nie tylko na ochronie systemów informatycznych, lecz także na odporności organizacji i ciągłości świadczenia usług istotnych dla gospodarki oraz społeczeństwa. Temu służą dyrektywa NIS2 i wdrażające ją zmiany w polskim prawie.

NIS2 to dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 dotycząca środków na rzecz wysokiego wspólnego poziomu cyberbezpieczeństwa w Unii. Zastąpiła wcześniejszą dyrektywę NIS, poszerzając zakres regulacji i wzmacniając wymagania dotyczące zarządzania cyberbezpieczeństwem oraz nadzoru nad ich przestrzeganiem. Jej celem jest ograniczenie różnic w poziomie ochrony między państwami członkowskimi — szczególnie tam, gdzie skutki incydentu mogą przekraczać granice jednej organizacji lub kraju.

Ustawa o krajowym systemie cyberbezpieczeństwa, czyli ustawa o KSC, stanowi krajowe ramy prawne tego systemu. Określa jego organizację, zadania uczestniczących w nim podmiotów oraz zasady współpracy z właściwymi instytucjami. Nowelizacja służąca wdrożeniu NIS2 dostosowuje polskie regulacje do wymagań unijnych. Nie jest więc odrębnym, konkurencyjnym standardem, lecz krajowym instrumentem realizacji celów dyrektywy.

Rozróżnienie tych aktów ma znaczenie praktyczne. NIS2 jest dyrektywą, a nie rozporządzeniem stosowanym bezpośrednio jak RODO. Państwa członkowskie miały obowiązek przyjąć i opublikować przepisy ją wdrażające do 17 października 2024 r. Sam ten termin nie oznacza jednak, że wszystkie obowiązki przedsiębiorstw zaczęły w Polsce obowiązywać tego dnia. Oceniając sytuację konkretnej firmy, trzeba uwzględnić aktualnie obowiązujące przepisy krajowe, daty ich wejścia w życie oraz okresy przejściowe.

Dla przedsiębiorstw i kadry zarządzającej najważniejsza jest zmiana perspektywy: cyberbezpieczeństwo nie może pozostawać wyłącznie zadaniem działu IT. Staje się elementem zarządzania organizacją, jej zależnościami i zdolnością do działania w sytuacji zakłóceń. Znaczenie nowych regulacji wykracza zatem poza formalną zgodność — dotyczy również stabilności operacyjnej, wiarygodności wobec kontrahentów i ograniczania skutków incydentów.

Kogo dotyczą przepisy NIS2 i ustawy o KSC? Sektory, kategorie podmiotów i progi

O objęciu organizacji przepisami nie przesądza sam fakt korzystania z systemów informatycznych ani posiadania działu IT. Punktem wyjścia jest rodzaj prowadzonej działalności, wielkość podmiotu oraz ewentualne wyjątki od kryterium wielkości. W Cognity często słyszymy pytania, jak w praktyce ustalić, czy firma podlega tym regulacjom — odpowiadamy na nie także na blogu. NIS2 wyznacza unijne ramy, natomiast sytuację konkretnej firmy w Polsce trzeba oceniać na podstawie obowiązujących przepisów ustawy o krajowym systemie cyberbezpieczeństwa oraz właściwych przepisów przejściowych. Zapowiedzi i projekty nowelizacji nie są jeszcze źródłem obowiązków.

Jakie sektory obejmuje NIS2?

Dyrektywa wyróżnia sektory kluczowe dla funkcjonowania gospodarki i społeczeństwa, dzieląc je między dwa załączniki. Zakres jest znacznie szerszy niż energetyka, bankowość czy ochrona zdrowia.

• Załącznik I — sektory wysoce krytyczne: energetyka, transport, bankowość, infrastruktura rynków finansowych, zdrowie, zaopatrzenie w wodę pitną, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT między przedsiębiorstwami, administracja publiczna i przestrzeń kosmiczna.
• Załącznik II — inne sektory krytyczne: usługi pocztowe i kurierskie, gospodarowanie odpadami, produkcja i dystrybucja chemikaliów, określone rodzaje działalności związanej z żywnością, wybrane gałęzie produkcji przemysłowej, dostawcy niektórych usług cyfrowych oraz organizacje badawcze.

Nazwa sektora to jednak dopiero wskazówka. W produkcji przemysłowej chodzi m.in. o wskazane w dyrektywie kategorie wyrobów medycznych, elektroniki, urządzeń elektrycznych, maszyn i środków transportu — nie o każdą fabrykę. W sektorze żywności zakres obejmuje przedsiębiorstwa zajmujące się dystrybucją hurtową oraz przemysłową produkcją i przetwarzaniem. Z kolei w usługach cyfrowych wymieniono m.in. internetowe platformy handlowe, wyszukiwarki i platformy społecznościowe. Kwalifikacja wymaga porównania faktycznej działalności z definicjami przepisów, a nie tylko sprawdzenia kodu PKD.

Progi wielkości: nie wystarczy policzyć pracowników

Co do zasady NIS2 obejmuje podmioty z wymienionych sektorów, które są co najmniej średnimi przedsiębiorstwami w rozumieniu unijnych zasad kwalifikacji MŚP. Próg ten osiąga się zasadniczo przy zatrudnieniu co najmniej 50 osób albo — przy mniejszym zatrudnieniu — gdy zarówno roczny obrót, jak i roczna suma bilansowa przekraczają 10 mln euro. Samo przekroczenie jednej wartości finansowej nie wystarcza.

Duży podmiot to zasadniczo taki, który zatrudnia co najmniej 250 osób albo jednocześnie przekracza 50 mln euro rocznego obrotu i 43 mln euro rocznej sumy bilansowej. Przy obliczeniach znaczenie mają zasady ustalania zatrudnienia oraz uwzględniania danych przedsiębiorstw partnerskich i powiązanych. Dlatego niewielka spółka należąca do grupy kapitałowej nie powinna oceniać swojego statusu wyłącznie na podstawie własnych danych.

Podmioty kluczowe i ważne — na czym polega różnica?

W podstawowym schemacie duże podmioty z załącznika I kwalifikują się jako podmioty kluczowe, a średnie podmioty z tego załącznika oraz średnie i duże podmioty z załącznika II — jako podmioty ważne. Nie jest to jednak reguła bez wyjątków. Obie kategorie podlegają wymaganiom cyberbezpieczeństwa; rozróżnienie wpływa przede wszystkim na model nadzoru i sankcje, a nie na to, czy bezpieczeństwem trzeba zarządzać.

W określonych przypadkach przepisy obejmują organizację niezależnie od wielkości. Dotyczy to m.in. dostawców usług DNS, rejestrów nazw domen najwyższego poziomu, dostawców usług zaufania oraz dostawców publicznych sieci lub publicznie dostępnych usług łączności elektronicznej. Odrębne zasady dotyczą administracji publicznej oraz podmiotów uznanych za krytyczne. Możliwe jest również objęcie mniejszych organizacji ze względu na szczególne znaczenie ich usług. Kategorię kluczową lub ważną trzeba w takich sytuacjach ustalić osobno.

Dostawcy: bezpośrednie objęcie przepisami a wymagania klientów

Dostawca może znaleźć się w zakresie regulacji bezpośrednio — przykładem są określeni dostawcy usług chmurowych, centrów danych, usług zarządzanych i zarządzanych usług bezpieczeństwa. Może też pozostawać poza zakresem podmiotowym, ale otrzymywać wymagania bezpieczeństwa od klientów objętych NIS2.

Sama współpraca z podmiotem kluczowym lub ważnym nie nadaje dostawcy takiego samego statusu. Tworzy natomiast pośredni wpływ regulacji: klient musi uwzględniać ryzyko związane z dostawcami, co może przekładać się na warunki współpracy. W ocenie sytuacji firmy trzeba więc oddzielić dwa pytania: czy podlega ona obowiązkom ustawowym oraz czy dotyczą jej wymagania kontraktowe wynikające z miejsca w łańcuchu dostaw.

Kluczowe obowiązki w zakresie cyberbezpieczeństwa: zarządzanie ryzykiem oraz środki techniczne i organizacyjne

NIS2 wymaga nie tylko wdrożenia zabezpieczeń, lecz także wykazania, że odpowiadają one rzeczywistemu ryzyku i działają w praktyce. Podstawowy katalog obowiązków określa art. 21 dyrektywy. Przy ocenie wymagań wynikających z nowelizacji ustawy o KSC trzeba uwzględnić ostateczne brzmienie polskich przepisów oraz terminy ich stosowania — samej dyrektywy nie należy utożsamiać z krajową ustawą.

Środki bezpieczeństwa mają być odpowiednie i proporcjonalne. Przy ich doborze znaczenie mają m.in. wielkość podmiotu, jego ekspozycja na zagrożenia, prawdopodobieństwo incydentu oraz skala potencjalnych skutków, również społecznych i gospodarczych. Należy uwzględnić także aktualny stan wiedzy technicznej, właściwe standardy i koszty wdrożenia. Proporcjonalność nie oznacza dowolności ani możliwości pominięcia podstawowych obszarów ochrony.

Zarządzanie ryzykiem jako podstawa decyzji

Punktem wyjścia jest ustalenie, które usługi, procesy, dane i systemy wymagają ochrony oraz jakie zależności decydują o ich dostępności. Bez tego łatwo przeznaczyć budżet na narzędzia, które ograniczają mniej istotne zagrożenia, pozostawiając kluczowe procesy bez wystarczającego zabezpieczenia.

Ocena ryzyka powinna łączyć analizę zagrożeń i podatności z oceną konsekwencji dla działalności. Podejście NIS2 obejmuje wszystkie rodzaje zagrożeń: nie tylko cyberataki, ale również błędy pracowników, awarie urządzeń, przerwy w zasilaniu czy zdarzenia zagrażające fizycznej infrastrukturze. Wyniki analizy powinny prowadzić do konkretnych decyzji: co zabezpieczyć, w jaki sposób, z jakim priorytetem i kto odpowiada za wykonanie działań.

Nie jest to zadanie jednorazowe. Ocenę trzeba aktualizować, gdy zmieniają się systemy, sposób świadczenia usług lub warunki zagrożenia. Uruchomienie nowej aplikacji, migracja do chmury albo poważna awaria mogą zmienić wcześniejsze założenia dotyczące bezpieczeństwa.

Środki techniczne i organizacyjne muszą się uzupełniać

Zabezpieczenia techniczne chronią systemy i dane, natomiast środki organizacyjne określają zasady ich stosowania, odpowiedzialność oraz sposób kontroli. Samo narzędzie nie zastąpi procesu: uwierzytelnianie wieloskładnikowe ogranicza ryzyko przejęcia konta, ale nie rozwiązuje problemu uprawnień pozostawionych osobie, która zakończyła współpracę.

Do podstawowych obszarów wymagających uporządkowania należą:

• Polityki bezpieczeństwa, zasoby i dostęp. Organizacja powinna znać swoje zasoby, przypisać odpowiedzialność za ich ochronę oraz ustalić zasady nadawania, przeglądania i odbierania uprawnień. Ochrona obejmuje również bezpieczeństwo związane z personelem.
• Bezpieczne pozyskiwanie, rozwijanie i utrzymywanie systemów. Potrzebne są zasady bezpiecznej konfiguracji, aktualizacji, wprowadzania zmian oraz postępowania z podatnościami, w tym ich ujawniania. Zakup rozwiązania nie kończy odpowiedzialności za jego bezpieczeństwo.
• Ciągłość działania i odtwarzanie po awarii. Kopie zapasowe powinny umożliwiać przywrócenie potrzebnych danych i usług. Ich wykonywanie należy uzupełnić testami odtwarzania, planami utrzymania działalności oraz przygotowaniem do zarządzania kryzysowego.
• Kryptografia i bezpieczna komunikacja. Należy określić zasady stosowania kryptografii, a w stosownych przypadkach szyfrowania. NIS2 przewiduje również, tam gdzie jest to właściwe, uwierzytelnianie wieloskładnikowe lub ciągłe oraz zabezpieczone kanały komunikacji.
• Cyberhigiena i szkolenia pracowników. Codzienne praktyki powinny ograniczać typowe błędy, takie jak ujawnianie danych logowania czy niebezpieczne obchodzenie się z informacjami. Zakres edukacji warto dopasować do zadań i dostępu danej grupy pracowników.

Sprawdzanie skuteczności zamiast pozornej zgodności

Wdrożenie procedury nie jest równoznaczne z osiągnięciem bezpieczeństwa. NIS2 wymaga polityk i procedur oceny skuteczności zastosowanych środków. W praktyce oznacza to sprawdzanie, czy zabezpieczenia realizują zakładany cel: czy można odtworzyć usługę, czy dostęp jest ograniczany zgodnie z przyjętymi zasadami i czy wykryte słabości są rzeczywiście usuwane.

Wyniki testów i przeglądów powinny prowadzić do korekt zabezpieczeń oraz aktualizacji oceny ryzyka. Standardy, takie jak ISO/IEC 27001, mogą pomóc uporządkować ten proces, ale sama NIS2 nie ustanawia powszechnego obowiązku uzyskania takiego certyfikatu. Certyfikat nie zastępuje też oceny spełnienia konkretnych wymagań prawnych.

Łańcuch dostaw w praktyce: wymagania wobec dostawców, umowy, ocena ryzyka i monitoring

Dostawca usług chmurowych, oprogramowania czy zdalnego serwisu może mieć istotny wpływ na bezpieczeństwo firmy, choć pozostaje poza jej strukturą organizacyjną. Dlatego art. 21 NIS2 obejmuje bezpieczeństwo łańcucha dostaw, w tym relacje z bezpośrednimi dostawcami i usługodawcami. Zlecenie obsługi systemu na zewnątrz nie zwalnia podmiotu objętego przepisami z obowiązków dotyczących zarządzania własnym ryzykiem.

W praktyce trzeba rozróżnić dwa poziomy wymagań: obowiązki prawne ciążące na danym podmiocie oraz wymagania umowne, które przekazuje on swoim dostawcom. Kontrahent może otrzymać ankietę bezpieczeństwa lub propozycję dodatkowych klauzul, nawet jeśli sam nie podlega przepisom wdrażającym NIS2. Nie oznacza to jednak, że automatycznie staje się adresatem wszystkich obowiązków ustawowych.

Ocena dostawcy powinna zależeć od jego znaczenia dla działalności

Punktem wyjścia jest ustalenie, co dostawca rzeczywiście robi: do jakich danych ma dostęp, z jakimi systemami się łączy i jakie byłyby skutki przerwania jego usług. Operator utrzymujący system niezbędny do realizacji zamówień wymaga innej oceny niż kontrahent, który nie ma dostępu do infrastruktury ani informacji wrażliwych. W Cognity omawiamy ocenę ryzyka dostawców zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

NIS2 wskazuje na potrzebę uwzględniania podatności charakterystycznych dla bezpośrednich dostawców oraz ogólnej jakości ich produktów i praktyk cyberbezpieczeństwa, w tym procedur bezpiecznego rozwoju oprogramowania. Ocenę warto więc oprzeć na konkretnych pytaniach: jak dostawca zarządza dostępem administracyjnym, usuwa podatności, utrzymuje wsparcie produktu i zapewnia ciągłość usługi? Znaczenie mają również zależności od podwykonawców, możliwość zastąpienia dostawcy oraz dostępność danych po zakończeniu współpracy.

Zakres weryfikacji powinien być proporcjonalny do ryzyka. Przy mniej istotnej usłudze może wystarczyć przegląd dokumentacji i odpowiedzi na wybrane pytania. W przypadku dostawcy krytycznego dla działalności zasadne mogą być dodatkowe dowody, rozmowa techniczna lub audyt. Certyfikat bezpieczeństwa jest pomocny, ale trzeba sprawdzić jego ważność i zakres — nie stanowi samodzielnej gwarancji bezpieczeństwa konkretnej usługi.

Umowa powinna przekładać wymagania na sprawdzalne zobowiązania

Ogólna deklaracja „zgodności z NIS2” nie zastępuje precyzyjnych ustaleń. Umowa powinna określać, kto odpowiada za poszczególne zabezpieczenia i w jaki sposób firma może zweryfikować ich utrzymanie. NIS2 nie ustanawia jednego obowiązkowego wzoru klauzul dla wszystkich relacji handlowych; ich treść należy dopasować do usługi, ryzyka i właściwych przepisów krajowych, w tym obowiązującego brzmienia ustawy o KSC.

W zależności od charakteru współpracy warto uregulować:

• Minimalne zabezpieczenia i podział odpowiedzialności — np. zasady dostępu zdalnego, aktualizacji, wykonywania kopii zapasowych oraz ochrony powierzonych danych.
• Informowanie o zdarzeniach i współpracę — kanały kontaktu, czas przekazania informacji oraz pomoc w analizie i ograniczaniu skutków zdarzenia, tak aby firma mogła wykonać własne obowiązki.
• Weryfikację i działania naprawcze — dostęp do uzgodnionych dowodów bezpieczeństwa, zasady audytu oraz terminy usuwania stwierdzonych niezgodności.
• Podwykonawstwo i zakończenie współpracy — informowanie o istotnych zmianach, odpowiednie wymagania wobec podwykonawców, zwrot lub usunięcie danych oraz odebranie dostępów.

Monitoring nie kończy się na podpisaniu umowy

Ocena wykonana przed zakupem szybko traci wartość, jeśli później zmieniają się usługa, uprawnienia dostawcy lub jego podwykonawcy. Dlatego warto przypisać osobę odpowiedzialną za daną relację i ustalić częstotliwość przeglądów zależną od ryzyka. Dodatkową ocenę powinny uruchamiać istotne zdarzenia, takie jak poważna podatność produktu, incydent u usługodawcy czy zakończenie wsparcia technicznego.

Monitoring powinien prowadzić do decyzji, a nie tylko do zbierania ankiet. Jeśli dostawca nie spełnia uzgodnionych wymagań, firma powinna określić działania naprawcze, ograniczyć narażenie albo rozważyć zmianę usługi. Najważniejszy jest udokumentowany związek między rozpoznanym ryzykiem, wymaganiami wobec dostawcy i reakcją na stwierdzone braki.

Obowiązki zarządu i kadry kierowniczej: nadzór, zatwierdzanie środków, odpowiedzialność i szkolenia

Zarząd nie może traktować cyberbezpieczeństwa wyłącznie jako zadania działu IT. Artykuł 20 dyrektywy NIS2 wymaga, aby organy zarządzające podmiotów kluczowych i ważnych zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie oraz nadzorowały ich wdrażanie. Specjaliści mogą przygotować rozwiązania i odpowiadać za ich realizację, ale kierownictwo musi rozumieć podejmowane decyzje oraz ich znaczenie dla działalności organizacji.

Zatwierdzanie środków: decyzja oparta na ryzyku, nie formalny podpis

Zatwierdzenie środków bezpieczeństwa powinno wynikać z oceny ryzyka przedstawionej w sposób zrozumiały dla osób zarządzających. Zarząd potrzebuje informacji o tym, które procesy biznesowe są zagrożone, jakie mogą być skutki zakłóceń oraz czy proponowane zabezpieczenia są proporcjonalne do ryzyka. Samo przyjęcie ogólnej polityki bezpieczeństwa nie wystarcza, jeżeli nie przekłada się na wdrożenie odpowiednich rozwiązań.

W praktyce decyzjom powinny towarzyszyć ustalenia dotyczące finansowania, odpowiedzialności za wykonanie i terminów realizacji. Jeżeli kierownictwo akceptuje ryzyko pozostające po zastosowaniu zabezpieczeń, warto udokumentować uzasadnienie oraz warunki ponownej oceny. Akceptacja ryzyka nie może jednak zastępować wykonania obowiązku wynikającego z prawa.

Nadzór: regularna weryfikacja zamiast jednorazowej akceptacji

Nadzór oznacza sprawdzanie, czy zatwierdzone środki rzeczywiście działają i czy organizacja usuwa stwierdzone braki. Dobrym rozwiązaniem jest stałe raportowanie do zarządu, obejmujące najważniejsze ryzyka, postęp prac naprawczych, istotne ustalenia audytowe oraz decyzje wymagające zaangażowania kierownictwa. Raport powinien wyjaśniać skutki biznesowe, a nie ograniczać się do technicznych wskaźników.

Warto również określić, jakie okoliczności wymagają pilnego przedstawienia sprawy zarządowi, bez oczekiwania na cykliczne spotkanie. NIS2 nie ustanawia jednego, uniwersalnego harmonogramu posiedzeń poświęconych cyberbezpieczeństwu. Częstotliwość przeglądów należy dostosować do ryzyka i sytuacji podmiotu, z uwzględnieniem właściwych przepisów krajowych.

Odpowiedzialność: delegowanie zadań nie usuwa obowiązku nadzoru

Wyznaczenie osoby odpowiedzialnej za bezpieczeństwo, powołanie zespołu lub zlecenie obsługi zewnętrznemu dostawcy nie zastępuje obowiązków organu zarządzającego. Potrzebny jest czytelny podział: kto przygotowuje rekomendacje, kto podejmuje decyzje, kto wdraża środki i kto kontroluje wykonanie. Kadra kierownicza poszczególnych obszarów powinna znać swoje zadania oraz granice uprawnień decyzyjnych.

NIS2 wymaga zapewnienia możliwości pociągnięcia organów zarządzających do odpowiedzialności za naruszenia obowiązków dotyczących środków zarządzania ryzykiem. Nie oznacza to automatycznie takiej samej osobistej odpowiedzialności każdego menedżera. Jej zakres, przesłanki i możliwe sankcje trzeba oceniać na podstawie właściwych przepisów krajowych. W Polsce punktem odniesienia jest obowiązujące brzmienie ustawy o KSC, wraz z przepisami dotyczącymi wejścia zmian w życie i okresów przejściowych — nie samo brzmienie projektu nowelizacji.

Szkolenia: kompetencje potrzebne do podejmowania decyzji

Artykuł 20 NIS2 przewiduje obowiązek udziału członków organów zarządzających w szkoleniach. Mają one umożliwiać rozpoznawanie ryzyka, ocenę praktyk zarządzania cyberbezpieczeństwem oraz zrozumienie ich wpływu na usługi świadczone przez organizację. Kierownictwo nie musi zdobywać kompetencji administratorów systemów, lecz powinno umieć ocenić rekomendację, zapytać o skutki zaniechania i rozpoznać sytuację wymagającą interwencji.

Program warto powiązać z rzeczywistymi procesami i ryzykiem organizacji. NIS2 nie określa uniwersalnej liczby godzin ani jednego obowiązkowego certyfikatu. Szkolenia nie należy zatem sprowadzać do uzyskania zaświadczenia: istotne jest przygotowanie osób zarządzających do świadomego zatwierdzania środków i sprawowania nadzoru.

Zgłaszanie incydentów: zasady, terminy, wymagane informacje i organizacja procesu

W przypadku poważnego incydentu nie można czekać z powiadomieniem do zakończenia analizy technicznej. NIS2 przewiduje zgłaszanie etapowe: najpierw wczesne ostrzeżenie, następnie zgłoszenie z dokładniejszą oceną zdarzenia, a na końcu sprawozdanie. Pozwala to szybko uruchomić współpracę z właściwymi organami, nawet gdy przyczyna i pełna skala incydentu nie są jeszcze znane.

Poniższe terminy wynikają z art. 23 dyrektywy NIS2. Przy stosowaniu ich w Polsce należy uwzględnić obowiązujące brzmienie ustawy o KSC, przepisy wdrażające oraz terminy ich stosowania. Sama dyrektywa nie zastępuje krajowych zasad wskazujących adresata zgłoszenia i sposób jego przekazania.

Które incydenty wymagają zgłoszenia?

Obowiązek przewidziany w NIS2 dotyczy incydentów mających istotny wpływ na świadczenie usług, określanych jako poważne incydenty. Incydent jest poważny, jeżeli spowodował lub może spowodować dotkliwe zakłócenia operacyjne usług albo straty finansowe danego podmiotu. Kryterium spełnia także zdarzenie, które wpłynęło lub może wpłynąć na inne osoby fizyczne lub prawne, powodując znaczne szkody majątkowe lub niemajątkowe.

Nie każdy alert z systemu bezpieczeństwa oznacza więc konieczność zgłoszenia. Potrzebna jest szybka, udokumentowana kwalifikacja zdarzenia, uwzględniająca również kryteria właściwe dla danego rodzaju podmiotu. Nie trzeba czekać na wystąpienie rzeczywistej szkody, jeżeli incydent już spełnia przesłanki związane z możliwymi skutkami.

Terminy i zakres informacji według NIS2

Terminy 24 i 72 godzin liczy się od powzięcia wiedzy o poważnym incydencie, a nie automatycznie od chwili rozpoczęcia ataku. Są to terminy maksymalne: dyrektywa wymaga działania bez zbędnej zwłoki.

Jeżeli obsługa incydentu nadal trwa w terminie przewidzianym na sprawozdanie końcowe, podmiot przekazuje sprawozdanie z postępu prac. Sprawozdanie końcowe składa następnie w ciągu miesiąca od zakończenia obsługi incydentu. Szczególna reguła dotyczy dostawców usług zaufania: zgłoszenie poważnego incydentu wpływającego na świadczenie tych usług należy przekazać nie później niż w ciągu 24 godzin od powzięcia o nim wiedzy.

Jak zorganizować proces zgłaszania?

Procedura powinna wskazywać właściwego odbiorcę i kanał zgłoszenia zgodnie z krajowymi przepisami. Nie należy zakładać, że wszystkie organizacje raportują do tego samego CSIRT. Warto wcześniej sprawdzić wymagania formularza, dostęp do systemu zgłoszeniowego oraz awaryjną ścieżkę kontaktu.

• Wyznacz osoby odpowiedzialne i ich zastępców. Musi być jasne, kto kwalifikuje zdarzenie, zbiera informacje i wysyła zgłoszenie, również poza godzinami pracy.
• Dokumentuj chronologię. Zapisuj czas wykrycia zdarzenia, moment powzięcia wiedzy o jego poważnym charakterze, ustalenia analityczne i daty przekazania kolejnych informacji.
• Oddziel fakty od hipotez. W zgłoszeniu zaznaczaj, które informacje są potwierdzone, które stanowią wstępną ocenę, a które wymagają dalszej weryfikacji. Brak pełnych danych nie uzasadnia opóźnienia zgłoszenia.
• Zachowuj potwierdzenia i wersje dokumentów. Rejestr zgłoszeń powinien pozwalać odtworzyć, co przekazano, komu i kiedy oraz jakie aktualizacje przygotowano.

Należy również ocenić potrzebę poinformowania odbiorców usług. NIS2 przewiduje, w stosownych przypadkach, powiadomienie ich bez zbędnej zwłoki o poważnych incydentach, które mogą niekorzystnie wpłynąć na świadczenie usług. Taka komunikacja nie zastępuje zgłoszenia do właściwego CSIRT lub organu.

Zgłoszenie w reżimie KSC nie zastępuje innych wymaganych zawiadomień. Jeżeli zdarzenie obejmuje naruszenie ochrony danych osobowych, trzeba odrębnie ocenić obowiązki wynikające z RODO. Wspólna dokumentacja incydentu może wspierać oba procesy, lecz przesłanki zgłoszenia, adresaci i sposób liczenia terminów wymagają osobnej weryfikacji.

Tabela zgodności: wymóg – co to oznacza w praktyce – przykłady dowodów zgodności

Zgodności z wymaganiami cyberbezpieczeństwa nie potwierdza sam komplet polityk. Organizacja powinna umieć wykazać, że przyjęte zasady są stosowane, podlegają ocenie i są aktualizowane po zmianach lub incydentach. Poniższe zestawienie porządkuje najważniejsze obszary NIS2 w układzie: wymóg, działanie, dowód. Służy jako punkt wyjścia do przeglądu zgodności; szczegółowy zakres obowiązków trzeba ustalić na podstawie właściwych, obowiązujących przepisów krajowych, z uwzględnieniem terminów ich stosowania oraz regulacji sektorowych.

• Wymóg: zarządzanie ryzykiem cyberbezpieczeństwa.
  Co to oznacza w praktyce: decyzje o zabezpieczeniach wynikają z rozpoznanych zagrożeń i ich możliwego wpływu na działalność, a każde istotne ryzyko ma przypisaną osobę odpowiedzialną.
  Przykłady dowodów zgodności: aktualna ocena ryzyka, rejestr ryzyk, plan postępowania z ryzykiem, udokumentowane decyzje o akceptacji ryzyka.

• Wymóg: zatwierdzanie środków zarządzania ryzykiem i nadzór nad ich wdrożeniem.
  Co to oznacza w praktyce: organ zarządzający podejmuje udokumentowane decyzje i otrzymuje informacje pozwalające ocenić realizację przyjętych działań.
  Przykłady dowodów zgodności: uchwały lub protokoły zatwierdzenia środków, raporty dla zarządu, przypisanie odpowiedzialności, potwierdzenia realizacji zaleceń.

• Wymóg: obsługa i zgłaszanie incydentów.
  Co to oznacza w praktyce: organizacja potrafi wykryć zdarzenie, ocenić jego znaczenie, uruchomić właściwą ścieżkę eskalacji i dokonać wymaganego zgłoszenia.
  Przykłady dowodów zgodności: rejestr incydentów, zapisy czasu wykrycia i kolejnych działań, uzasadnienia klasyfikacji, potwierdzenia zgłoszeń, raporty z ćwiczeń.

• Wymóg: ciągłość działania i odtwarzanie po awarii.
  Co to oznacza w praktyce: kluczowe usługi można przywrócić zgodnie z przyjętymi założeniami, a skuteczność odtwarzania jest sprawdzana.
  Przykłady dowodów zgodności: plany ciągłości i odtwarzania, raporty z wykonywania kopii zapasowych, protokoły testów przywracania danych, wykaz usuniętych nieprawidłowości.

• Wymóg: bezpieczeństwo łańcucha dostaw.
  Co to oznacza w praktyce: ryzyko związane z dostawcami jest oceniane, a wymagania bezpieczeństwa znajdują odzwierciedlenie w warunkach współpracy i jej okresowych przeglądach.
  Przykłady dowodów zgodności: oceny dostawców, klauzule umowne, wyniki przeglądów bezpieczeństwa, dokumentacja działań naprawczych.

• Wymóg: bezpieczne nabywanie, rozwój i utrzymanie systemów oraz zarządzanie podatnościami.
  Co to oznacza w praktyce: bezpieczeństwo jest uwzględniane przez cały cykl życia systemu, a wykryte słabości są obsługiwane według ustalonych priorytetów.
  Przykłady dowodów zgodności: wymagania bezpieczeństwa dla zakupów, wyniki testów, rejestr podatności, historia aktualizacji i zatwierdzonych zmian.

• Wymóg: kontrola dostępu i odpowiednia ochrona informacji.
  Co to oznacza w praktyce: dostęp odpowiada zadaniom użytkowników, jest weryfikowany i odbierany, gdy przestaje być potrzebny; zabezpieczenia uwierzytelniania i kryptograficzne są dobierane do ryzyka oraz mających zastosowanie wymagań.
  Przykłady dowodów zgodności: matryca uprawnień, protokoły przeglądów kont, potwierdzenia odebrania dostępów, zapisy konfiguracji zabezpieczeń.

• Wymóg: szkolenia i podstawowe praktyki cyberhigieny.
  Co to oznacza w praktyce: osoby zarządzające i pracownicy zdobywają wiedzę odpowiednią do swoich obowiązków, a organizacja sprawdza jej praktyczne wykorzystanie.
  Przykłady dowodów zgodności: programy i rejestry szkoleń, potwierdzenia uczestnictwa, wyniki sprawdzianów wiedzy, raporty z ćwiczeń.

• Wymóg: ocena skuteczności zabezpieczeń.
  Co to oznacza w praktyce: organizacja nie ogranicza się do wdrożenia środków, lecz regularnie sprawdza, czy osiągają zamierzony efekt.
  Przykłady dowodów zgodności: wyniki audytów i testów, raporty wskaźników bezpieczeństwa, plany naprawcze oraz potwierdzenia ponownej weryfikacji.

Każdy dowód powinien dać się powiązać z konkretnym wymaganiem, zakresem systemów, datą i osobą odpowiedzialną. Polityka opisuje przyjętą zasadę, zapis operacyjny potwierdza jej stosowanie, a wynik testu pomaga ocenić skuteczność. Dopiero taki zestaw pozwala rzetelnie ocenić stan zgodności — pojedynczy dokument lub certyfikat nie zastępuje tej oceny.

Plan działań na 3 miesiące: kroki wdrożenia i priorytety dla firmy

Pierwsze 90 dni warto przeznaczyć na ustalenie zakresu obowiązków, ograniczenie najpoważniejszych ryzyk i uruchomienie procesów, które firma będzie w stanie utrzymać. To harmonogram organizacyjny, a nie ustawowy termin wdrożenia ani gwarancja pełnej zgodności. Tempo prac trzeba dostosować do obowiązujących przepisów, terminów właściwych dla danego podmiotu oraz jego obecnego poziomu zabezpieczeń.

Miesiąc 1: ustal zakres i przygotuj plan oparty na faktach

Zacznij od sprawdzenia, jakie wymagania rzeczywiście dotyczą firmy. NIS2 wyznacza unijne ramy, natomiast przy planowaniu działań w Polsce trzeba uwzględnić aktualny stan ustawy o krajowym systemie cyberbezpieczeństwa, jej przepisów wykonawczych i regulacji przejściowych. Nie traktuj zapisów projektu nowelizacji jak obowiązującego prawa.

Wyznacz osobę koordynującą wdrożenie i zapewnij jej współpracę z IT, działem prawnym, zakupami oraz właścicielami procesów biznesowych. Zbierz istniejące procedury, wyniki audytów, informacje o systemach i umowach. Następnie przeprowadź analizę luk: oddziel rozwiązania, które już działają, od tych, które wymagają poprawy lub dopiero powstania.

Rezultatem pierwszego miesiąca powinien być zatwierdzony zakres projektu oraz lista działań zawierająca właścicieli, terminy, szacowane koszty i kryteria zakończenia. Priorytet nadaj brakom zagrażającym ciągłości kluczowych usług, a nie dokumentom, które najłatwiej przygotować.

Miesiąc 2: wdrażaj najpilniejsze zmiany i zbieraj dowody

Prace prowadź równolegle w trzech obszarach: zabezpieczeń, organizacji oraz współpracy z dostawcami. Wybierz zadania na podstawie analizy ryzyka. Mogą to być na przykład uporządkowanie uprawnień, zabezpieczenie dostępu administracyjnego lub sprawdzenie możliwości odtworzenia najważniejszego systemu. Nie każda firma potrzebuje na tym etapie nowego narzędzia — czasem większą poprawę przynosi prawidłowa konfiguracja tego, które już posiada.

Każde zadanie zamykaj potwierdzeniem wykonania i oceną skuteczności. Sama faktura za rozwiązanie albo opublikowana procedura nie dowodzi, że zabezpieczenie działa. Zachowuj wyniki testów, protokoły odbioru i zapisy decyzji. Kwestie wymagające większego budżetu lub dłuższych negocjacji umieść w odrębnym harmonogramie, ze wskazaniem rozwiązań tymczasowych.

Rezultatem drugiego miesiąca powinny być działające usprawnienia w obszarach najwyższego ryzyka oraz udokumentowany postęp pozostałych prac.

Miesiąc 3: przetestuj gotowość i zaplanuj utrzymanie

Sprawdź, czy przyjęte rozwiązania wytrzymują próbę praktyczną. Przeprowadź ćwiczenie oparte na realistycznym scenariuszu zakłócenia działalności i zweryfikuj wykonanie wybranych procedur. Oceń przede wszystkim, czy pracownicy wiedzą, kto podejmuje decyzje, gdzie znajdują się potrzebne informacje i jak postępować przy niedostępności kluczowych osób lub systemów. W Cognity łączymy teorię z praktyką — dlatego te zagadnienia rozwijamy także w formie ćwiczeń na szkoleniach.

Wyniki przedstaw kierownictwu w krótkim raporcie: co wdrożono, co sprawdzono, jakie ryzyka pozostają i które decyzje wymagają zatwierdzenia. Ustal cykl przeglądów oraz odpowiedzialność za aktualizację dokumentacji i kontrolę zabezpieczeń.

Po 90 dniach firma powinna dysponować nie tylko dokumentacją, lecz także sprawdzonym sposobem działania i realnym planem zamknięcia pozostałych luk. Miarą postępu jest ograniczenie ryzyka potwierdzone dowodami, nie liczba ukończonych dokumentów.

Claude Code w firmie – nie tylko dla programistów 14 października 2026

Szkolenie z Claude AI – czego warto nauczyć pracowników, żeby naprawdę korzystali z AI 12 października 2026