Nowelizacja KSC wdrażająca NIS2 w praktyce – dlaczego kierownictwo musi znać nowe obowiązki?

KSC i NIS2 – co się zmienia i dlaczego to ważne dla biznesu

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (KSC) wdrażająca NIS2 oznacza dla biznesu znacznie więcej niż zmianę wymagań dotyczących zabezpieczeń informatycznych. Jej znaczenie polega na szerszym objęciu organizacji regulacjami oraz silniejszym powiązaniu cyberbezpieczeństwa z zarządzaniem ryzykiem i ciągłością działalności. Dla kierownictwa punktem odniesienia staje się odporność całej organizacji: zdolność do świadczenia usług, realizacji zobowiązań i ograniczania skutków zakłóceń, a nie wyłącznie sprawność infrastruktury IT.

KSC i NIS2 nie są dwiema równoległymi regulacjami o takim samym charakterze. Ustawa o KSC określa krajowe ramy cyberbezpieczeństwa, w tym zadania uczestników systemu i zasady współpracy przy obsłudze incydentów. Z kolei dyrektywa NIS2, czyli dyrektywa (UE) 2022/2555, wyznacza wspólne wymagania dla państw członkowskich i zastępuje wcześniejszą dyrektywę NIS. Nowelizacja KSC służy przeniesieniu tych wymagań do polskiego porządku prawnego. Przy ustalaniu konkretnych obowiązków i terminów dla przedsiębiorstwa rozstrzygające znaczenie ma zatem obowiązujące brzmienie przepisów krajowych, z uwzględnieniem regulacji przejściowych.

Jedną z najważniejszych różnic jest rozszerzenie zakresu regulacji. Dotychczasowy model KSC, oparty na pierwszej dyrektywie NIS, obejmował między innymi operatorów usług kluczowych oraz dostawców usług cyfrowych. NIS2 wprowadza podział na podmioty kluczowe i podmioty ważne oraz obejmuje więcej sektorów. Obok energetyki, transportu czy ochrony zdrowia uwzględnia między innymi określone rodzaje produkcji przemysłowej, usługi pocztowe i kurierskie oraz gospodarowanie odpadami. O objęciu regulacją decydują zasadniczo rodzaj działalności i wielkość podmiotu, przy czym przewidziano również wyjątki. Sama przynależność do szeroko rozumianej branży nie wystarcza więc do przesądzenia statusu firmy.

Określenie „podmiot ważny” nie oznacza, że cyberbezpieczeństwo ma w takiej organizacji drugorzędne znaczenie. Obie kategorie podlegają wymaganiom dotyczącym zarządzania ryzykiem cyberbezpieczeństwa, natomiast różnice dotyczą między innymi modelu nadzoru. Sens zmian można sprowadzić do odejścia od wąskiego spojrzenia na bezpieczeństwo pojedynczych systemów na rzecz ochrony usług i procesów, od których zależą inni uczestnicy gospodarki. Taki kontekst przedstawiają również materiały Ministerstwa Cyfryzacji poświęcone cyberbezpieczeństwu.

Znaczenie biznesowe zmian wynika z zależności między organizacjami. Awaria lub atak u dostawcy technologii może zakłócić produkcję, logistykę albo obsługę klientów w wielu przedsiębiorstwach jednocześnie. Dlatego wpływ NIS2 może sięgać także firm, które same nie uzyskają statusu podmiotu kluczowego lub ważnego: ich kontrahenci mogą oczekiwać potwierdzenia określonego poziomu bezpieczeństwa w ramach zarządzania ryzykiem łańcucha dostaw. Takie oczekiwania umowne należy odróżniać od bezpośrednich obowiązków ustawowych.

Z perspektywy zarządu cyberbezpieczeństwo staje się więc zagadnieniem dotyczącym stabilności operacyjnej, relacji z kontrahentami i ochrony przychodów. Zabezpieczenia techniczne pozostają niezbędne, ale nie rozstrzygają samodzielnie o akceptowalnym poziomie ryzyka, priorytetach inwestycyjnych czy zależności od dostawców. To właśnie ten organizacyjny wymiar zmian sprawia, że wdrożenia NIS2 nie można traktować wyłącznie jako projektu działu IT.

Nowe obowiązki podmiotów kluczowych i ważnych w ujęciu praktycznym

Obowiązki wynikające z NIS2 obejmują znacznie więcej niż zakup zabezpieczeń informatycznych. Ich istotą jest stałe zarządzanie ryzykiem cyberbezpieczeństwa oraz zdolność do utrzymania i odtworzenia usług po incydencie. Dotyczy to zarówno podmiotów kluczowych, jak i ważnych — druga z tych kategorii nie oznacza zwolnienia z podstawowych wymagań bezpieczeństwa. Środki ochrony powinny być odpowiednie i proporcjonalne m.in. do wielkości organizacji, jej narażenia na ryzyko oraz prawdopodobieństwa i skutków incydentów.

Punktem odniesienia dla tych obowiązków są przede wszystkim art. 21 i 23 dyrektywy NIS2. Przy ustalaniu szczegółowych wymagań krajowych i terminów ich stosowania należy korzystać z obowiązującego brzmienia KSC; komunikaty publikowane przez Ministerstwo Cyfryzacji stanowią kontekst informacyjny, ale nie zastępują przepisów.

Zarządzanie ryzykiem musi przekładać się na konkretne zabezpieczenia. Organizacja powinna rozpoznawać zagrożenia dla systemów wykorzystywanych w działalności i oceniać ich możliwe konsekwencje. W praktyce oznacza to powiązanie ochrony technologii z procesami biznesowymi: awaria systemu obsługi zamówień, utrata dostępu do dokumentacji czy zatrzymanie produkcji wymagają odmiennego podejścia. Zakres środków przewidzianych w NIS2 obejmuje m.in. kontrolę dostępu, zarządzanie aktywami, bezpieczeństwo personelu, stosowanie kryptografii oraz — tam, gdzie jest to właściwe — uwierzytelnianie wieloskładnikowe. Obowiązek nie sprowadza się więc do posiadania polityki bezpieczeństwa, lecz obejmuje jej rzeczywiste stosowanie.

Obsługa incydentów obejmuje zarówno reakcję wewnętrzną, jak i zgłoszenia na zewnątrz. NIS2 przewiduje etapowe raportowanie incydentów poważnych: co do zasady wczesne ostrzeżenie w ciągu 24 godzin od uzyskania wiedzy o incydencie, zgłoszenie w ciągu 72 godzin oraz sprawozdanie końcowe nie później niż miesiąc po przekazaniu zgłoszenia. Dla incydentów nadal trwających przewidziano odrębny tryb sprawozdawczy. Nie każde zdarzenie techniczne podlega takiemu raportowaniu — znaczenie mają przesłanki powagi incydentu, w tym zakłócenia świadczenia usług, straty finansowe lub szkody dla innych osób i podmiotów. Praktyczną konsekwencją jest konieczność szybkiego zbierania informacji i oceny zdarzenia, zanim znane będą wszystkie jego przyczyny.

Ciągłość działania wymaga czegoś więcej niż wykonywania kopii zapasowych. Wymagania obejmują również odtwarzanie po awarii i zarządzanie kryzysowe. Organizacja musi uwzględniać sytuacje, w których podstawowe systemy, dane lub kanały komunikacji stają się niedostępne. Kopia zapasowa ma wartość operacyjną dopiero wtedy, gdy można ją wykorzystać do przywrócenia potrzebnych zasobów; dlatego istotnym elementem oceny skuteczności zabezpieczeń jest sprawdzanie możliwości odtworzenia działania.

Bezpieczeństwo obejmuje także relacje z dostawcami. Korzystanie z zewnętrznej obsługi IT, usług chmurowych czy oprogramowania nie usuwa ryzyka po stronie organizacji. NIS2 wymaga uwzględnienia bezpieczeństwa łańcucha dostaw, w tym relacji z bezpośrednimi dostawcami i usługodawcami. W praktyce oznacza to ocenę, jak ich podatności i praktyki bezpieczeństwa wpływają na świadczone usługi. Równolegle wymagania dotyczą bezpiecznego nabywania, rozwijania i utrzymywania systemów oraz postępowania z podatnościami.

Skuteczność przyjętych rozwiązań powinna być regularnie oceniana. NIS2 obejmuje również podstawowe praktyki cyberhigieny i szkolenia z cyberbezpieczeństwa. Dokumentacja ryzyka, wyniki testów, zapisy obsługi incydentów czy potwierdzenia przeglądów uprawnień pomagają wykazać, że zabezpieczenia rzeczywiście funkcjonują. Nie chodzi o tworzenie dokumentów dla samej formalności, lecz o możliwość sprawdzenia, czy przyjęte środki odpowiadają aktualnym zagrożeniom i potrzebom organizacji.

Odpowiedzialność kierownictwa: zakres, konsekwencje i nadzór

Odpowiedzialność kierownictwa nie kończy się na powierzeniu cyberbezpieczeństwa działowi 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. Państwa członkowskie mają również zapewnić możliwość pociągnięcia tych organów do odpowiedzialności za naruszenia obowiązków dotyczących tych środków. To istotna różnica między zleceniem prac technicznych a odpowiedzialnością za decyzje i nadzór nad ich wykonaniem.

W praktyce zatwierdzenie polityki bezpieczeństwa nie powinno być wyłącznie formalnością. Kierownictwo potrzebuje informacji pozwalających ocenić, czy przyjęte zabezpieczenia odpowiadają rozpoznanemu ryzyku, czy organizacja zapewnia zasoby na ich wdrożenie oraz czy ujawnione nieprawidłowości są usuwane. Nie oznacza to konieczności samodzielnej oceny konfiguracji systemów. Oznacza natomiast obowiązek sprawowania rzeczywistego nadzoru, a nie jedynie przyjmowania zapewnień, że bezpieczeństwo zostało zapewnione.

Delegowanie zadań nie jest równoznaczne z przeniesieniem odpowiedzialności za nadzór. Wyznaczenie osoby odpowiedzialnej za bezpieczeństwo lub zawarcie umowy z dostawcą zewnętrznym porządkuje wykonanie obowiązków, ale nie zastępuje roli organu zarządzającego. Jednocześnie nie należy automatycznie utożsamiać każdego dyrektora czy menedżera z osobą ponoszącą ustawową odpowiedzialność kierowniczą. Ustalenie kręgu osób odpowiedzialnych wymaga odniesienia do właściwych przepisów KSC, formy prawnej podmiotu i pełnionej funkcji.

Konsekwencje naruszeń należy rozpatrywać oddzielnie dla organizacji i dla osób nią zarządzających. NIS2 wymaga, aby maksymalny poziom administracyjnych kar pieniężnych za określone naruszenia wynosił co najmniej 10 mln euro lub 2% całkowitego światowego rocznego obrotu przedsiębiorstwa w przypadku podmiotów kluczowych oraz 7 mln euro lub 1,4% takiego obrotu w przypadku podmiotów ważnych — zależnie od tego, która kwota jest wyższa. Nie są to minimalne kary za pojedyncze naruszenie ani stawki osobistych kar dla członków zarządu. Szczegółowe podstawy odpowiedzialności, krajowe limity sankcji i zasady ich nakładania trzeba ustalać na podstawie obowiązujących przepisów wdrażających dyrektywę.

Samo wystąpienie cyberataku nie przesądza o naruszeniu obowiązków ani o osobistej odpowiedzialności kierownictwa. Znaczenie ma to, czy organizacja stosowała wymagane, proporcjonalne środki oraz jak wykonywała obowiązki objęte oceną organu nadzorczego. Dokumentacja decyzji, raportów i reakcji na stwierdzone braki może pomóc wykazać sposób sprawowania nadzoru, jednak nie zastąpi faktycznych działań.

NIS2 różnicuje również model nadzoru. Wobec podmiotów kluczowych przewiduje nadzór uprzedni i następczy, natomiast wobec podmiotów ważnych — zasadniczo następczy, uruchamiany po uzyskaniu dowodów, wskazówek lub informacji o możliwym naruszeniu. Uprawnienia właściwych organów obejmują między innymi żądanie informacji, kontrole, audyty oraz nakazy usunięcia nieprawidłowości. Status podmiotu ważnego nie oznacza zatem zwolnienia z wymagań, lecz odmienny sposób weryfikowania ich przestrzegania.

Przy ocenie odpowiedzialności należy oddzielać wymagania dyrektywy od konkretnych rozwiązań krajowych. Komunikaty Ministerstwa Cyfryzacji stanowią pomocny kontekst zmian w KSC, ale o zakresie obowiązków, terminach ich stosowania i podstawach sankcji rozstrzyga treść opublikowanych przepisów, w tym regulacji przejściowych.

4. Dlaczego kierownictwo musi rozumieć cyberbezpieczeństwo (nie tylko IT)

Cyberbezpieczeństwo jest zagadnieniem zarządczym, ponieważ dotyczy zdolności organizacji do świadczenia usług, realizowania zobowiązań i utrzymania ciągłości działania. Dział IT może ocenić podatność systemu i zaproponować zabezpieczenia, ale nie powinien samodzielnie rozstrzygać, jak długo firma może działać bez obsługi zamówień ani które procesy mają pierwszeństwo przy odtwarzaniu pracy. Takie decyzje wymagają znajomości modelu biznesowego, zobowiązań wobec klientów i skutków finansowych przestoju.

To szersze spojrzenie jest istotne dla zrozumienia nowelizacji KSC wdrażającej NIS2. Rządowy kontekst zmian przedstawiają materiały publikowane w serwisie poświęconym cyberbezpieczeństwu. Samą potrzebę rozwijania kompetencji kierownictwa wyraźnie wskazuje art. 20 dyrektywy NIS2: przewiduje szkolenia członków organów zarządzających, służące zdobywaniu wiedzy i umiejętności potrzebnych do rozpoznawania ryzyka oraz oceny praktyk zarządzania nim i ich wpływu na świadczone usługi. Nie chodzi zatem o przygotowanie zarządu do administrowania systemami, lecz do świadomej oceny informacji otrzymywanych od specjalistów.

Punktem wyjścia jest rozumienie trzech wymiarów bezpieczeństwa informacji: poufności, integralności i dostępności. Naruszenie poufności oznacza dostęp do informacji przez osoby nieuprawnione. Utrata integralności może oznaczać nieautoryzowaną zmianę danych, na podstawie których organizacja podejmuje decyzje. Brak dostępności uniemożliwia korzystanie z informacji lub systemu wtedy, gdy są potrzebne. Cyberbezpieczeństwo nie ogranicza się więc do zapobiegania wyciekom — obejmuje również wiarygodność danych i możliwość wykonywania codziennych zadań.

Równie ważne jest odróżnienie zagrożenia od ryzyka. Zagrożeniem może być atak blokujący dostęp do systemów. Ocena ryzyka wymaga dodatkowo uwzględnienia prawdopodobieństwa takiego zdarzenia oraz jego skutków dla konkretnej organizacji. Ta sama niedostępność aplikacji może oznaczać niewielkie opóźnienie pracy albo zatrzymanie kluczowej usługi. Kierownictwo potrzebuje tej perspektywy, aby oceniać zasadność wydatków na zabezpieczenia, a nie jedynie porównywać ich ceny.

Przykładowo informacja „wykonujemy kopie zapasowe” nie wyjaśnia jeszcze, czy organizacja potrafi sprawnie wznowić działalność. Z perspektywy zarządczej istotne jest również, czy sprawdzono możliwość odtworzenia danych, ile może ono potrwać i jakie konsekwencje będzie miała przerwa. Podstawowa wiedza pozwala zadawać pytania o skuteczność zabezpieczeń, zamiast poprzestawać na potwierdzeniu ich istnienia.

Delegowanie zadań technicznych pozostaje niezbędne. Nie zastępuje jednak kompetencji potrzebnych do wyboru priorytetów, oceny kompromisów i rozumienia skutków decyzji. Kierownictwo nie musi znać konfiguracji narzędzi bezpieczeństwa; powinno rozumieć, co chronią, jakie mają ograniczenia i jakie ryzyko pozostaje mimo ich zastosowania.

Jak przygotować organizację: priorytety, plan działań i harmonogram

Przygotowanie do wymagań KSC wdrażających NIS2 należy rozpocząć od ustalenia zakresu obowiązków i oceny obecnego poziomu zabezpieczeń, a nie od zakupu narzędzi. Kierownictwo potrzebuje przede wszystkim odpowiedzi na trzy pytania: które usługi organizacji podlegają ochronie, gdzie występują najistotniejsze braki oraz jakie decyzje i nakłady są potrzebne do ich usunięcia. Plan dostosowania powinien łączyć wymagania prawne z ryzykiem dla ciągłości działalności — sama kompletność dokumentacji nie potwierdza jeszcze skuteczności zabezpieczeń.

Punkt wyjścia: kwalifikacja podmiotu i kalendarz prawny. Najpierw należy zweryfikować, czy i na jakiej podstawie organizacja jest objęta regulacją, jakie obowiązki jej dotyczą oraz od kiedy musi je wykonywać. Wynik tej analizy warto udokumentować wraz z przyjętymi założeniami. Kontekst zmian można śledzić w materiałach Ministerstwa Cyfryzacji dotyczących cyberbezpieczeństwa, jednak podstawą ustalania terminów musi być opublikowane brzmienie przepisów, w tym regulacje przejściowe. Komunikatu o projekcie ustawy nie należy traktować jak obowiązującego prawa.

Pierwsze 30 dni: diagnoza i działania pilne. Praktycznym początkiem jest inwentaryzacja krytycznych usług, wspierających je systemów, danych oraz zależności od dostawców. Następnie należy przeprowadzić analizę luk, czyli porównać istniejące rozwiązania z wymaganiami dotyczącymi organizacji. Nie trzeba przy tym tworzyć wszystkiego od nowa: warto wykorzystać aktualne analizy ryzyka, procedury ciągłości działania i wyniki wcześniejszych audytów, sprawdzając ich zakres oraz przydatność. Zidentyfikowane zagrożenia wymagające natychmiastowej reakcji, np. niekontrolowany dostęp administracyjny lub brak sprawdzonych kopii zapasowych, powinny być ograniczane równolegle z diagnozą.

Dni 31–60: zatwierdzenie planu i uruchomienie wdrożeń. Dla każdej istotnej luki należy określić działanie naprawcze, osobę odpowiedzialną za jego realizację, budżet, termin oraz kryterium odbioru. Priorytet powinny otrzymać zadania wynikające z najbliższych terminów prawnych oraz te, które ograniczają największe ryzyko dla usług. Harmonogram musi uwzględniać zależności: test odtworzenia systemu wymaga przygotowanego środowiska, a usprawnienie współpracy z dostawcą może wymagać negocjacji umowy. Kierownictwo powinno zatwierdzić nie tylko wydatki, lecz także dostępność pracowników niezbędnych do wykonania tych zadań.

Dni 61–90: sprawdzenie skuteczności i korekta planu. Wdrożone rozwiązania należy zweryfikować w praktyce. Przydatne są testy odtwarzania danych, przeglądy uprawnień oraz ćwiczenie scenariuszowe incydentu, podczas którego uczestnicy sprawdzają obieg informacji, podejmowanie decyzji i możliwość terminowego przygotowania zgłoszenia. Rozwój kompetencji kierownictwa warto zaplanować już na początku programu, a następnie utrwalić wiedzę podczas takiego ćwiczenia. Jego rezultatem powinny być konkretne ustalenia: co zadziałało, co wymaga poprawy i kiedy poprawki zostaną ponownie sprawdzone.

Układ 30–60–90 dni jest propozycją organizacji prac, a nie terminem ustawowym ani gwarancją osiągnięcia zgodności. Należy go dostosować do obowiązujących przepisów, skali organizacji i stanu zabezpieczeń. Większe zmiany infrastrukturalne lub kontraktowe mogą wymagać dłuższego programu. W takich przypadkach potrzebne są działania przejściowe ograniczające ryzyko; samo wpisanie zadania do harmonogramu nie oznacza spełnienia obowiązku.

Postęp warto oceniać na podstawie rezultatów, a nie liczby przygotowanych dokumentów. Raport dla kierownictwa powinien pokazywać zadania opóźnione, nierozwiązane ryzyka i decyzje wymagające zatwierdzenia, a także wyniki testów najważniejszych zabezpieczeń. Dowody wykonania prac — protokoły testów, zatwierdzenia procedur czy potwierdzenia usunięcia luk — należy gromadzić na bieżąco. Po zakończeniu pierwszego etapu potrzebny jest stały kalendarz przeglądów, ćwiczeń i aktualizacji, uwzględniający również zmiany usług, systemów oraz dostawców.

6. Rola compliance, bezpieczeństwa i działów operacyjnych w spełnieniu wymagań

Spełnienie wymagań KSC i NIS2 wymaga współpracy zespołów, które patrzą na te same procesy z różnych perspektyw. Compliance ocenia zgodność z przepisami, zespół bezpieczeństwa analizuje zagrożenia i skuteczność zabezpieczeń, a działy operacyjne określają konsekwencje zakłóceń dla świadczonych usług. Podział zadań powinien łączyć te perspektywy, a nie tworzyć trzy niezależne obiegi dokumentów i decyzji. Nie oznacza to konieczności powołania trzech osobnych jednostek — istotne jest jednoznaczne przypisanie funkcji i zasad współpracy, odpowiednio do skali organizacji.

Compliance, przy wsparciu obsługi prawnej, przekłada wymagania regulacyjne na obowiązki wewnętrzne. Do jego roli należy ustalenie, które przepisy dotyczą organizacji, monitorowanie zmian oraz weryfikowanie, czy procedury i dokumentacja odpowiadają wymaganiom. Komunikaty i materiały Ministerstwa Cyfryzacji stanowią pomocny kontekst interpretacyjny, ale nie zastępują analizy obowiązującego brzmienia ustawy. Compliance wspiera również określenie, jakie dowody realizacji obowiązków należy gromadzić; samo istnienie polityki bezpieczeństwa nie potwierdza jeszcze jej stosowania.

Zespół bezpieczeństwa odpowiada za merytoryczną ocenę ryzyka i dobór zabezpieczeń, współpracując z IT oraz właścicielami procesów. Powinien wyjaśniać znaczenie ustaleń technicznych w kategoriach biznesowych: dostępności usług, poufności informacji czy możliwości odtworzenia działania. IT wdraża i utrzymuje rozwiązania techniczne, lecz nie powinno samodzielnie rozstrzygać, jak długo organizacja może tolerować przerwę w konkretnej usłudze.

Działy operacyjne dostarczają wiedzy o rzeczywistym przebiegu procesów i ich zależnościach. To ich przedstawiciele wskazują, które czynności są krytyczne, z jakich systemów i usług dostawców korzystają oraz czy proponowane procedury awaryjne da się zastosować w praktyce. Zakupy wspierają uwzględnianie wymagań bezpieczeństwa w relacjach z dostawcami, a HR — organizację działań edukacyjnych i obieg informacji o zmianach kadrowych istotnych dla uprawnień dostępu.

Znaczenie takiej współpracy najlepiej widać podczas incydentu. Zespół bezpieczeństwa ustala jego charakter i zakres techniczny, operacje oceniają wpływ na realizację usług, a compliance wspiera ocenę obowiązków zgłoszeniowych. Organizacja powinna z góry ustalić, kto koordynuje ten proces, kto przekazuje zgłoszenie i kto podejmuje decyzje wymagające udziału kierownictwa. Uzgodniony obieg informacji ogranicza ryzyko opóźnień wynikających ze sporów kompetencyjnych.

Praktycznym rozwiązaniem jest wspólny rejestr obowiązków, przypisanych osób odpowiedzialnych i dowodów wykonania. Dzięki niemu kierownictwo otrzymuje spójny obraz: które wymagania są realizowane, gdzie pozostają luki i jakie decyzje są potrzebne. Koordynacja compliance, bezpieczeństwa i operacji wspiera nadzór kierownictwa — nie zastępuje go.

7. Najczęstsze pytania zarządów i krótkie odpowiedzi (FAQ)

Czy nowe wymagania dotyczą wyłącznie dużych firm i infrastruktury krytycznej?

Nie. Zakres NIS2 jest szerszy i obejmuje również część średnich przedsiębiorstw oraz określone podmioty niezależnie od ich wielkości. O kwalifikacji decydują m.in. sektor, rodzaj działalności i wielkość organizacji, z uwzględnieniem wyjątków przewidzianych w przepisach. Sam brak statusu operatora infrastruktury krytycznej nie wyłącza firmy z zakresu regulacji.

Czy podmiot ważny ma mniej obowiązków niż podmiot kluczowy?

Nie należy utożsamiać statusu podmiotu ważnego z ograniczeniem wymagań do minimum. NIS2 przewiduje dla obu kategorii obowiązki dotyczące zarządzania ryzykiem cyberbezpieczeństwa i zgłaszania poważnych incydentów. Różnice dotyczą przede wszystkim modelu nadzoru i sankcji, natomiast stosowane zabezpieczenia powinny być proporcjonalne do ryzyka oraz specyfiki działalności.

Czy zarząd może przekazać całą odpowiedzialność dyrektorowi IT lub zewnętrznemu dostawcy?

Nie. Można powierzyć specjalistom realizację zadań, ale nie zastępuje to obowiązków kierownictwa. NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem cyberbezpieczeństwa i nadzorowały ich wdrażanie. Outsourcing może wspierać wykonanie tych zadań, lecz nie usuwa potrzeby podejmowania decyzji, zapewnienia zasobów i kontroli rezultatów.

Czy członkowie zarządu muszą mieć wiedzę techniczną?

Nie muszą samodzielnie konfigurować zabezpieczeń ani analizować złośliwego oprogramowania. Powinni jednak rozumieć ryzyka, możliwe skutki zakłóceń oraz znaczenie proponowanych środków ochrony. NIS2 przewiduje szkolenia członków organów zarządzających — ich celem jest zdolność do świadomej oceny ryzyka i praktyk zarządzania cyberbezpieczeństwem, a nie zastąpienie zespołu IT.

Czy certyfikat ISO 27001 lub zgodność z RODO wystarczą?

Nie. Mogą stanowić wartościową podstawę, ale nie potwierdzają automatycznie spełnienia wszystkich wymagań KSC. RODO koncentruje się na ochronie danych osobowych, a zakres certyfikacji ISO 27001 może nie obejmować całej działalności objętej obowiązkami. Potrzebne jest porównanie istniejących rozwiązań z konkretnymi wymaganiami ustawowymi.

Czy każdy incydent trzeba zgłaszać w ciągu 24 godzin?

Nie każdy. NIS2 przewiduje wczesne ostrzeżenie dotyczące poważnego incydentu bez zbędnej zwłoki, nie później niż w ciągu 24 godzin od uzyskania wiedzy o nim. Nie jest to jeszcze pełne zgłoszenie ani raport końcowy. Organizacja powinna ustalić zasady kwalifikowania incydentów, właściwy kanał zgłoszeń i kolejne terminy zgodnie z mającymi do niej zastosowanie przepisami.

Czy sam cyberatak oznacza odpowiedzialność kierownictwa?

Nie automatycznie. Wystąpienie ataku nie przesądza o naruszeniu obowiązków. Znaczenie ma m.in. to, czy organizacja zastosowała wymagane środki, sprawowała nadzór i prawidłowo zareagowała. Zakres odpowiedzialności oraz sankcji należy oceniać na podstawie przepisów krajowych i okoliczności konkretnej sprawy.

Skąd zarząd powinien czerpać informacje o terminach i ostatecznym zakresie obowiązków?

Podstawą jest opublikowany tekst nowelizacji KSC, w tym przepisy o wejściu w życie i okresach przejściowych. Komunikaty Ministerstwa Cyfryzacji pomagają śledzić zmiany, ale nie zastępują ustawy. Warto odróżniać obowiązujące przepisy od projektów i zapowiedzi; sama data wskazana w materiale dotyczącym NIS2 nie musi oznaczać terminu wykonania obowiązku przez konkretny podmiot.

Jak przygotować zarząd i kadrę kierowniczą do nowych obowiązków KSC i NIS2? 04 października 2026

Jak przygotować zarząd i kadrę kierowniczą do nowych obowiązków KSC i NIS2? 04 października 2026