Nowelizacja KSC i NIS2 w praktyce – za co odpowiada zarząd i kierownictwo organizacji?

KSC po nowelizacji i NIS2: zakres wymagań oraz na kogo nakładają obowiązki

NIS2 wyznacza unijne ramy cyberbezpieczeństwa, a ustawa o krajowym systemie cyberbezpieczeństwa (KSC) jest podstawowym instrumentem ich wdrożenia w Polsce. Nie są to dwa zamienne określenia tego samego aktu. NIS2, czyli dyrektywa (UE) 2022/2555, zobowiązuje państwa członkowskie do wprowadzenia określonych rozwiązań. KSC określa krajowy system obowiązków, właściwe organy oraz zasady nadzoru i egzekwowania przepisów. Dla organizacji istotne jest więc nie tylko poznanie dyrektywy, lecz przede wszystkim ustalenie, jakie przepisy krajowe mają do niej zastosowanie i od kiedy.

Ocenę zgodności trzeba opierać na obowiązującym brzmieniu KSC i przepisach przejściowych, a nie na zapowiedziach lub projektach nowelizacji. Termin wdrożenia dyrektywy przez państwo nie jest automatycznie terminem wykonania każdego obowiązku przez przedsiębiorcę. Również szczegółowe rozwiązania proponowane w toku prac legislacyjnych nie powinny być traktowane jako ostateczne wymagania.

Od wybranych operatorów do szerszego katalogu podmiotów

W porównaniu z modelem opartym na pierwszej dyrektywie NIS, kojarzonym przede wszystkim z operatorami usług kluczowych i dostawcami usług cyfrowych, NIS2 znacząco poszerza zakres regulacji. Obejmuje nie tylko energetykę, transport, ochronę zdrowia czy infrastrukturę cyfrową, lecz także m.in. usługi pocztowe i kurierskie, gospodarowanie odpadami, określone rodzaje produkcji, wybrane podmioty sektora żywnościowego oraz dostawców usług zarządzanych i zarządzanych usług bezpieczeństwa.

Nie oznacza to jednak, że każda firma działająca w szeroko rozumianej branży technologicznej lub przemysłowej podlega identycznym wymaganiom. Kwalifikacja wymaga sprawdzenia rzeczywiście prowadzonej działalności, rodzaju świadczonych usług, wielkości podmiotu oraz wyjątków przewidzianych w przepisach. Sam kod PKD nie rozstrzyga o objęciu regulacją.

• Sektor i rodzaj działalności: znaczenie mają konkretne kategorie podmiotów wskazane w przepisach, a nie wyłącznie ogólna przynależność do branży.
• Wielkość organizacji: zasadniczo NIS2 obejmuje podmioty średnie i większe z wymienionych kategorii. Przy ustalaniu wielkości należy uwzględnić właściwe reguły dotyczące zatrudnienia, danych finansowych i powiązań z innymi przedsiębiorstwami.
• Wyjątki: niektóre podmioty mogą podlegać regulacji niezależnie od wielkości, np. ze względu na rodzaj usługi lub szczególne znaczenie dla państwa i społeczeństwa.

Podmioty kluczowe i ważne — co oznacza ten podział?

NIS2 wyróżnia podmioty kluczowe i podmioty ważne. Przypisanie do kategorii wynika z kryteriów prawnych, a nie z własnej oceny znaczenia organizacji. Obie grupy obejmuje zasadniczy katalog wymagań dotyczących zarządzania ryzykiem cyberbezpieczeństwa i zgłaszania poważnych incydentów. Różnice dotyczą przede wszystkim sposobu sprawowania nadzoru i reżimu sankcji. Status podmiotu ważnego nie oznacza zatem, że bezpieczeństwo staje się dobrowolne.

Zakres wymagań wykracza poza ochronę infrastruktury informatycznej: obejmuje również organizację bezpieczeństwa, odporność operacyjną i bezpieczeństwo łańcucha dostaw. Obowiązki dotyczą podmiotu jako organizacji, a NIS2 przewiduje także zadania dla jej organów zarządzających. Powierzenie obsługi IT zewnętrznemu dostawcy nie przenosi samo w sobie odpowiedzialności regulacyjnej na tego dostawcę.

Warto przy tym odróżnić bezpośrednie objęcie przepisami od wymagań kontraktowych. Firma pozostająca poza zakresem KSC może otrzymywać od klientów wymagania bezpieczeństwa wynikające z ich obowiązków wobec łańcucha dostaw. Nie czyni jej to automatycznie podmiotem kluczowym lub ważnym, ale może realnie wpływać na warunki współpracy.

Governance cyberbezpieczeństwa: rola zarządu i kierownictwa, model nadzoru i odpowiedzialności

Zarząd nie musi samodzielnie zarządzać zabezpieczeniami technicznymi, ale powinien wiedzieć, czy organizacja właściwie zarządza cyberbezpieczeństwem — i mieć podstawy do tej oceny. Na tym polega governance: na ustaleniu, kto podejmuje decyzje, kto je wykonuje, kto ocenia skuteczność działań i jakie informacje docierają do osób odpowiedzialnych za organizację. W Cognity często słyszymy pytania, jak w praktyce rozdzielić te role i zapewnić skuteczny nadzór — odpowiadamy na nie także na blogu.

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. Przewiduje również możliwość pociągnięcia tych organów do odpowiedzialności za naruszenia obowiązków dotyczących tych środków. Konkretne podstawy, zakres i tryb odpowiedzialności należy jednak ustalać na podstawie przepisów krajowych wdrażających dyrektywę, w Polsce — KSC w brzmieniu obowiązującym w danym czasie. Nie należy utożsamiać samego wystąpienia cyberataku z automatyczną odpowiedzialnością członka zarządu.

Zarząd wyznacza ramy, kierownictwo zapewnia wykonanie

Rolą zarządu jest zapewnienie, że cyberbezpieczeństwo stanowi element zarządzania organizacją, a nie odizolowane zadanie działu IT. Obejmuje to ustalenie kompetencji decyzyjnych, oczekiwań wobec osób odpowiedzialnych za bezpieczeństwo oraz zasad sprawowania nadzoru. Kierownictwo poszczególnych obszarów przekłada te ustalenia na sposób działania podległych zespołów i procesów. Odpowiedzialność operacyjna nie kończy się więc na IT: dotyczy również obszarów biznesowych, których decyzje wpływają na bezpieczeństwo usług, informacji i współpracy z dostawcami.

Ten podział ma praktyczne znaczenie. Osoba odpowiedzialna za bezpieczeństwo może wskazać problem i zaproponować rozwiązanie, ale nie zawsze ma uprawnienia do zmiany procesu biznesowego. Model governance powinien określać, kto rozstrzyga taką sprawę i kiedy wymaga ona decyzji wyższego szczebla. Przekazanie zadań specjalistom lub zewnętrznemu usługodawcy nie oznacza samo w sobie przeniesienia ustawowych obowiązków organu zarządzającego.

Model nadzoru: wykonanie, weryfikacja i decyzja

Przejrzysty model nadzoru rozdziela trzy funkcje:

• Wykonanie — właściciele procesów i zespoły operacyjne realizują przypisane zadania oraz odpowiadają za ich przebieg.
• Monitorowanie i wsparcie — funkcje bezpieczeństwa, ryzyka i zgodności oceniają sposób realizacji wymagań, wskazują nieprawidłowości i wspierają osoby podejmujące decyzje.
• Niezależna ocena — pozwala sprawdzić, czy przyjęte rozwiązania rzeczywiście działają, zamiast opierać nadzór wyłącznie na deklaracjach wykonawców.

To użyteczny wzorzec organizacyjny, a nie narzucony przez NIS2 schemat trzech odrębnych działów. Sposób jego zastosowania powinien odpowiadać wielkości i złożoności podmiotu, z uwzględnieniem potencjalnych konfliktów interesów. Jeżeli w organizacji działa rada nadzorcza lub inny organ nadzorczy, jego kompetencje trzeba odróżnić od obowiązków organu zarządzającego.

Nadzór powinien być możliwy do wykazania. Samo przypisanie odpowiedzialności w regulaminie nie wystarcza: potrzebne są czytelne uprawnienia, dostęp do rzetelnych informacji oraz udokumentowane rozstrzygnięcia. Dzięki temu można ustalić nie tylko, kto formalnie odpowiadał za dany obszar, lecz także czy otrzymał informację o problemie i jak na nią zareagował.

Polityki, SZBI i zgodność: zatwierdzanie, przeglądy, audyty oraz zapewnienie zasobów

Zatwierdzona polityka bezpieczeństwa nie jest jeszcze dowodem, że organizacja spełnia wymagania cyberbezpieczeństwa. Potrzebne są również działające procedury, potwierdzenie ich stosowania i mechanizm usuwania wykrytych braków. NIS2 wymaga, aby organy zarządzające zatwierdzały środki zarządzania ryzykiem w cyberbezpieczeństwie i nadzorowały ich wdrażanie. W praktyce oznacza to konieczność powiązania dokumentacji z rzeczywistym sposobem działania organizacji, a nie wyłącznie z formalnym obiegiem akceptacji.

Polityki, procedury i SZBI — różne funkcje, jeden system

Polityka określa zasady i wymagania, procedura opisuje sposób ich wykonania, natomiast system zarządzania bezpieczeństwem informacji (SZBI) łączy je z odpowiedzialnością, oceną skuteczności i doskonaleniem. Rozróżnienie to pomaga uniknąć sytuacji, w której organizacja ma rozbudowaną dokumentację, lecz nie potrafi wykazać, kto odpowiada za jej stosowanie ani czy przyjęte zabezpieczenia działają.

ISO/IEC 27001 może służyć jako podstawa uporządkowania SZBI. Sama NIS2 nie ustanawia jednak powszechnego obowiązku certyfikacji według tej normy, a certyfikat nie zastępuje oceny zgodności z prawem. Zakres systemu, dokumentacji i wymaganych dowodów należy odnieść do obowiązujących przepisów KSC oraz innych regulacji mających zastosowanie do danego podmiotu.

Zatwierdzanie i przeglądy dokumentacji

Zatwierdzenie powinno obejmować nie tylko treść zasad, ale także możliwość ich wykonania. Przed akceptacją trzeba ustalić, czy dokument ma właściciela, jednoznaczny zakres, termin wejścia w życie i sposób weryfikacji przestrzegania wymagań. Należy również rozstrzygnąć, jak będą zatwierdzane i ewidencjonowane ewentualne odstępstwa od zasad wewnętrznych — nie mogą one uchylać obowiązków ustawowych.

Nie oznacza to, że zarząd musi podpisywać każdą instrukcję techniczną. Organizacja powinna określić poziomy zatwierdzania dokumentów, zachowując wymaganą prawem odpowiedzialność organu zarządzającego za przyjmowane środki i nadzór nad ich wdrożeniem. Dokumentacja musi pozostawać spójna: procedura nie powinna dopuszczać rozwiązań sprzecznych z nadrzędną polityką.

Przeglądy należy planować okresowo oraz uruchamiać po istotnych zmianach prawnych, organizacyjnych lub technologicznych, a także wtedy, gdy kontrola ujawni nieskuteczność przyjętych rozwiązań. Dowodem przeglądu jest zapis oceny i decyzji, nie samo odświeżenie daty dokumentu. Wynikiem może być aktualizacja albo uzasadnione pozostawienie dotychczasowej wersji.

Audyty i ocena skuteczności

Przegląd dokumentacji sprawdza jej aktualność i adekwatność. Audyt pozwala ocenić zgodność z ustalonymi kryteriami na podstawie dowodów, natomiast testy weryfikują działanie konkretnych zabezpieczeń. Te działania uzupełniają się, ale nie są zamienne. Wymagania dotyczące obowiązkowych audytów, ich terminów i wykonawców trzeba ustalać na podstawie przepisów właściwych dla danego podmiotu — nie zakładać jednego harmonogramu dla wszystkich organizacji objętych regulacjami.

Każde istotne ustalenie powinno prowadzić do wskazania działania korygującego, osoby odpowiedzialnej i terminu realizacji. Zamknięcie niezgodności wymaga potwierdzenia, że problem został usunięty; deklaracja wykonania zadania nie zawsze będzie wystarczającym dowodem.

Zasoby jako warunek wykonalności wymagań

Utrzymanie SZBI wymaga czasu pracowników, odpowiednich kompetencji, narzędzi oraz dostępu do niezależnej oceny tam, gdzie jest ona potrzebna lub wymagana. Przy zatwierdzaniu zasad należy więc sprawdzić, czy organizacja ma warunki do ich stosowania i dokumentowania. Jeżeli brakuje zasobów, luka powinna zostać ujawniona wraz z jej konsekwencjami i sposobem usunięcia. Formalne przyjęcie polityki nie rekompensuje braku możliwości jej wykonania.

Zarządzanie ryzykiem cyber: apetyt na ryzyko, metryki, nadzór i ciągłość działania

Z perspektywy zarządu ryzyko cybernetyczne to przede wszystkim ryzyko zakłócenia działalności: zatrzymania usługi, utraty wiarygodności danych, ujawnienia informacji lub niedotrzymania zobowiązań. Ocena nie może więc kończyć się na wykazie podatności technicznych. Powinna pokazywać, które procesy są zagrożone, jakie mogą być skutki i czy zastosowane zabezpieczenia ograniczają ryzyko do akceptowalnego poziomu. W Cognity omawiamy zarządzanie ryzykiem cybernetycznym zarówno od strony technicznej, jak i praktycznej — odnosząc je do decyzji, z którymi uczestnicy szkoleń mierzą się w swoich organizacjach.

Art. 21 NIS2 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych służących zarządzaniu ryzykiem. Przy ich doborze uwzględnia się m.in. stopień narażenia podmiotu, jego wielkość oraz prawdopodobieństwo i dotkliwość incydentów, w tym ich skutki społeczne i gospodarcze. To istotny punkt odniesienia przy wdrażaniu obowiązków wynikających z KSC: samo posiadanie zabezpieczenia nie dowodzi jeszcze, że odpowiada ono rzeczywistemu ryzyku.

Apetyt na ryzyko, tolerancja i ryzyko rezydualne

Pojęcia te opisują różne elementy decyzji zarządczej. Apetyt na ryzyko określa, jaki poziom i rodzaj ryzyka organizacja jest gotowa przyjmować, realizując swoje cele. Tolerancja ryzyka przekłada tę deklarację na konkretne granice, np. dopuszczalny czas niedostępności procesu. Ryzyko rezydualne to natomiast ryzyko pozostające po zastosowaniu zabezpieczeń — również wtedy, gdy działają one zgodnie z założeniami.

NIS2 nie narzuca jednej skali apetytu na ryzyko ani uniwersalnych progów akceptacji. Organizacja powinna dostosować je do znaczenia usług, zależności technologicznych i konsekwencji zakłóceń. Deklaracja „nie akceptujemy żadnego ryzyka” nie daje użytecznej podstawy do działania. Potrzebne są kryteria pozwalające odróżnić ryzyko możliwe do przyjęcia od takiego, które wymaga ograniczenia albo zmiany sposobu realizacji procesu.

Akceptacja ryzyka powinna mieć udokumentowane uzasadnienie, wskazanego właściciela, termin ponownej oceny i warunki jej wygaśnięcia. Nie zastępuje wykonania obowiązku prawnego: organizacja nie może uznać, że świadomie przyjmuje ryzyko niewdrożenia wymaganego środka, i na tej podstawie traktować obowiązku jako spełniony.

Metryki, które pokazują ekspozycję, a nie tylko aktywność

Liczba przeprowadzonych skanów czy zamkniętych zgłoszeń opisuje pracę zespołu, ale niekoniecznie poziom bezpieczeństwa. W nadzorze nad ryzykiem większą wartość mają wskaźniki powiązane z krytycznymi procesami, skutecznością zabezpieczeń i ustalonymi granicami tolerancji.

Każda metryka potrzebuje jednoznacznej definicji, wiarygodnego źródła danych i progu wymagającego reakcji. Ważny jest również trend: niezmieniony wynik może oznaczać pogorszenie sytuacji, jeśli w tym samym czasie wzrosła liczba obsługiwanych usług lub ich znaczenie. Ocena ryzyka wymaga aktualizacji także po istotnej zmianie systemu, dostawcy lub modelu świadczenia usług, a nie wyłącznie zgodnie z kalendarzem przeglądów.

Ciągłość działania jako sprawdzian założeń

NIS2 obejmuje ciągłość działania, w tym zarządzanie kopiami zapasowymi, odtwarzanie awaryjne i zarządzanie kryzysowe. Punktem wyjścia powinna być analiza wpływu na działalność, czyli BIA. Pozwala ona ustalić, które procesy należy przywrócić najpierw oraz od jakich danych, systemów, ludzi i dostawców zależy ich uruchomienie.

Dwa podstawowe parametry to RTO — docelowy czas przywrócenia procesu lub usługi — oraz RPO — punkt w czasie, do którego należy odtworzyć dane, określający dopuszczalny zakres ich utraty. Nie są one wartościami narzuconymi jednakowo wszystkim podmiotom przez NIS2. Muszą wynikać z potrzeb działalności i być osiągalne przy dostępnych rozwiązaniach.

O skuteczności planu nie świadczy samo istnienie kopii zapasowych, lecz możliwość odtworzenia użytecznej usługi. Testy powinny sprawdzać również zależności między systemami, dostępność danych uwierzytelniających i scenariusze niedostępności dostawcy. Jeżeli rzeczywisty czas odtworzenia przekracza przyjęty cel, wynik testu powinien zmienić ocenę ryzyka i prowadzić do działań korygujących — nie pozostawać wyłącznie uwagą w protokole.

5. Role i kompetencje: wyznaczenie CISO i innych ról, szkolenia kierownictwa, kultura bezpieczeństwa

Powierzenie cyberbezpieczeństwa działowi IT nie wystarcza do skutecznego rozdzielenia zadań. Administrator może zabezpieczać systemy, ale nie powinien samodzielnie rozstrzygać, jakie skutki przestoju są akceptowalne dla biznesu ani kto może korzystać z danych w danym procesie. Organizacja potrzebuje zarówno kompetencji technicznych, jak i jasno wskazanych osób odpowiedzialnych za koordynację bezpieczeństwa oraz decyzje po stronie biznesowej.

CISO: funkcja, która potrzebuje umocowania, nie tylko nazwy

NIS2 nie ustanawia powszechnego obowiązku utworzenia stanowiska o nazwie CISO. Wymaga natomiast odpowiednich środków organizacyjnych i technicznych, których wdrożenie potrzebuje wyraźnego podziału zadań. Szczegółowe wymagania dotyczące wyznaczania osób i funkcji należy ustalać na podstawie przepisów KSC właściwych dla danego podmiotu oraz ewentualnych regulacji sektorowych.

CISO, czyli osoba kierująca bezpieczeństwem informacji, może koordynować działania specjalistów, przekładać zagrożenia techniczne na konsekwencje biznesowe i dostarczać kierownictwu informacji potrzebnych do podejmowania decyzji. Aby ta funkcja działała, trzeba określić jej mandat, dostęp do informacji, możliwość zgłaszania zastrzeżeń oraz zastępstwo podczas nieobecności. Sam tytuł, bez czasu i uprawnień do wykonywania zadań, niewiele zmienia.

W mniejszej organizacji część funkcji można łączyć lub korzystać ze wsparcia zewnętrznego, o ile pozwalają na to właściwe przepisy. Należy jednak ocenić obciążenie pracą i konflikty interesów. Osoba odpowiedzialna za utrzymanie systemów może mieć trudność z niezależną oceną zabezpieczeń, które sama wdrożyła. Outsourcing kompetencji nie przenosi na dostawcę ustawowych obowiązków organizacji i jej kierownictwa.

Podział ról: bezpieczeństwo, IT, biznes i ochrona danych

Opis stanowiska powinien wskazywać nie tylko zakres zadań, lecz także granice uprawnień. W praktyce warto rozróżnić cztery obszary:

• Koordynacja bezpieczeństwa — łączenie działań poszczególnych zespołów, formułowanie wymagań i wskazywanie luk wymagających usunięcia.
• IT i zespoły techniczne — wdrażanie oraz utrzymywanie zabezpieczeń, zarządzanie konfiguracją i wykonywanie powierzonych czynności operacyjnych.
• Właściciele procesów, systemów i informacji — określanie potrzeb biznesowych, znaczenia chronionych zasobów oraz zasad korzystania z nich w granicach przyznanych uprawnień.
• Inspektor ochrony danych, jeżeli został wyznaczony — doradzanie i monitorowanie zgodności w zakresie ochrony danych osobowych. IOD nie zastępuje CISO; ewentualne łączenie funkcji wymaga oceny konfliktu interesów i zachowania niezależności IOD.

Taki podział należy utrwalić w zakresach obowiązków lub prostej macierzy odpowiedzialności. Pracownik powinien wiedzieć, do kogo zwrócić się z pytaniem, a osoba pełniąca daną funkcję — jakie decyzje może podjąć samodzielnie.

Szkolenia kierownictwa i codzienne nawyki pracowników

NIS2 przewiduje obowiązkowe szkolenia członków organów zarządzających podmiotów kluczowych i ważnych. Ich celem jest zdobycie wiedzy pozwalającej rozpoznawać ryzyko oraz oceniać praktyki zarządzania cyberbezpieczeństwem i ich wpływ na usługi organizacji. Nie chodzi o przygotowanie zarządu do konfiguracji zabezpieczeń, lecz do rozumienia konsekwencji decyzji. Przydatne są ćwiczenia oparte na realistycznych sytuacjach: niedostępności kluczowego systemu, przejęciu konta osoby decyzyjnej czy uzależnieniu procesu od jednego dostawcy.

Szkolenia pracowników powinny odpowiadać ich zadaniom. Innych umiejętności potrzebują administratorzy, innych osoby zatwierdzające płatności, a jeszcze innych zespoły obsługujące klientów. Skuteczność warto sprawdzać przez krótkie ćwiczenia i ocenę zachowań, nie wyłącznie listę obecności.

Kultura bezpieczeństwa powstaje wtedy, gdy zasady są wykonalne, a kierownictwo samo ich przestrzega. Pracownicy powinni móc zadawać pytania i zgłaszać pomyłki w dobrej wierze bez obawy przed automatycznym obwinianiem. Jeśli procedura utrudnia pracę, organizacja potrzebuje sposobu jej poprawienia — nie cichej zgody na obchodzenie zabezpieczeń.

Incydenty i obowiązki notyfikacyjne: raportowanie, współpraca z CSIRT, komunikacja i eskalacja

Obsługa incydentu wymaga prowadzenia dwóch działań równolegle: ograniczania jego skutków oraz realizacji obowiązków informacyjnych. Organizacja nie powinna czekać ze zgłoszeniem do zakończenia analizy technicznej ani uzależniać go od zebrania zarządu. Procedura musi pozwalać upoważnionym osobom na terminowe przekazanie dostępnych informacji, z wyraźnym wskazaniem, które ustalenia są jeszcze weryfikowane.

NIS2 określa unijny model raportowania, natomiast w Polsce podstawę obowiązków organizacji stanowią właściwe przepisy krajowe, w tym KSC. Przed zastosowaniem konkretnej ścieżki zgłoszenia trzeba sprawdzić aktualne brzmienie ustawy, przepisy przejściowe oraz ewentualne regulacje sektorowe. Poniższe terminy przedstawiają model wynikający z art. 23 NIS2 — nie należy automatycznie utożsamiać ich z obowiązkami każdego podmiotu objętego dotychczasowym KSC.

Kiedy incydent wymaga zgłoszenia?

Nie każdy alert bezpieczeństwa jest incydentem podlegającym obowiązkowej notyfikacji. NIS2 przewiduje zgłaszanie poważnych incydentów: takich, które spowodowały lub mogą spowodować poważne zakłócenia operacyjne usług albo straty finansowe danego podmiotu, bądź wywołały lub mogą wywołać znaczne szkody materialne lub niematerialne u innych osób lub organizacji. Znaczenie ma więc nie tylko potwierdzona szkoda, lecz także możliwy wpływ zdarzenia. Dla części kategorii podmiotów szczegółowe kryteria wynikają również z przepisów wykonawczych UE.

Ocena powinna obejmować m.in. zakres zakłócenia, dotknięte usługi, liczbę odbiorców i możliwe skutki dla innych podmiotów. Należy dokumentować zarówno decyzję o zgłoszeniu, jak i uzasadnienie odstąpienia od niego. Jeżeli pojawią się nowe informacje, kwalifikacja incydentu może wymagać zmiany.

Raportowanie etapowe: 24 godziny, 72 godziny i raport końcowy

W modelu NIS2 pierwsze terminy biegną od uzyskania wiedzy o poważnym incydencie, a nie od zakończenia dochodzenia. Zgłoszenia należy przekazywać bez zbędnej zwłoki; wskazane poniżej terminy są granicami, a nie zalecanym czasem oczekiwania.

Dla dostawców usług zaufania NIS2 przewiduje krótszy, 24-godzinny termin zgłoszenia poważnych incydentów wpływających na świadczenie tych usług. Jeżeli w terminie raportu końcowego obsługa incydentu nadal trwa, przekazuje się raport z postępów, a raport końcowy — w ciągu miesiąca od zakończenia obsługi.

Współpraca z CSIRT i eskalacja wewnętrzna

Zgłoszenie powinno trafić do adresata właściwego dla danego podmiotu i rodzaju obowiązku, zgodnie z krajowymi przepisami, a nie automatycznie do wszystkich zespołów CSIRT. Organizacja potrzebuje ustalonego punktu kontaktowego, dostępnego także poza godzinami pracy, oraz bezpiecznego kanału wymiany informacji. Współpraca obejmuje uzupełnianie ustaleń, przekazywanie danych technicznych i uwzględnianie otrzymanych wskazówek. Kontakt z CSIRT nie przenosi na ten zespół odpowiedzialności za opanowanie sytuacji w organizacji.

Kierownictwo powinno otrzymywać eskalację wtedy, gdy potrzebna jest decyzja wykraczająca poza uprawnienia zespołu operacyjnego — np. o wyłączeniu krytycznej usługi lub poinformowaniu odbiorców. Meldunek powinien jasno wskazywać potwierdzone fakty, niewiadome, wpływ na działalność, najbliższy termin zgłoszenia i decyzję wymaganą od kierownictwa. Równolegle trzeba zabezpieczać dowody oraz rejestrować czas wykrycia, kwalifikacji, eskalacji i wysłania zgłoszeń.

Komunikacja z odbiorcami i równoległe obowiązki

Notyfikacja do CSIRT lub właściwego organu nie zastępuje komunikacji z odbiorcami usług. NIS2 przewiduje, w odpowiednich przypadkach, informowanie ich bez zbędnej zwłoki o poważnych incydentach mogących niekorzystnie wpłynąć na świadczenie usług. Komunikat powinien wskazywać znany wpływ zdarzenia i działania, które odbiorca może podjąć, bez ujawniania szczegółów ułatwiających dalszy atak.

Ten sam incydent może uruchomić także obowiązki wynikające z RODO, regulacji sektorowych lub umów. Każda z tych ścieżek ma własne przesłanki, adresatów i terminy. Zgłoszenie w ramach KSC nie zastępuje więc automatycznie zgłoszenia naruszenia ochrony danych osobowych. Spójność informacji należy zapewnić przez wspólny rejestr ustaleń i aktualizacji, a nie przez opóźnianie jednej notyfikacji do czasu przygotowania pozostałych.

Co to oznacza w codziennym zarządzaniu: decyzje, budżet, priorytety, przeglądy i raportowanie do zarządu

Przełożenie wymagań KSC i NIS2 na codzienną pracę wymaga przede wszystkim uporządkowania decyzji: kto je podejmuje, na podstawie jakich informacji i w jakim terminie. Zarząd nie powinien zastępować zespołów technicznych w wyborze konfiguracji zabezpieczeń. Powinien natomiast rozstrzygać kwestie, które wpływają na działalność organizacji — finansowanie niezbędnych zmian, kolejność inwestycji czy warunki uruchomienia usługi mimo nierozwiązanych problemów bezpieczeństwa.

Priorytety i budżet powiązane z działalnością

Lista zakupów technologicznych nie jest jeszcze planem poprawy bezpieczeństwa. Każdy istotny wydatek warto powiązać z konkretną potrzebą: ograniczeniem możliwości przestoju, ochroną danych, usunięciem luki zgodności albo zapewnieniem utrzymania kluczowej usługi. Dzięki temu kierownictwo może porównywać propozycje według ich znaczenia dla organizacji, a nie wyłącznie ceny lub pilności zgłoszonej przez dostawcę.

W praktyce należy odróżnić działania niezbędne do spełnienia obowiązków od usprawnień, których zakres i harmonogram można dobierać elastycznie. Akceptacja ryzyka przez zarząd nie zastępuje wykonania obowiązku prawnego. Jeżeli brakuje środków na wymagane działanie, problem powinien trafić do rozstrzygnięcia wraz z konsekwencjami opóźnienia i możliwymi rozwiązaniami, zamiast pozostawać bez terminu na liście zadań IT.

Budżet powinien obejmować nie tylko wdrożenie, lecz także późniejsze utrzymanie: pracę specjalistów, aktualizacje, wsparcie, testy i odnowienia usług. Decyzja o zakupie rozwiązania bez zapewnienia zasobów do jego obsługi może oznaczać koszt bez oczekiwanego efektu ochronnego.

Raport do zarządu, który prowadzi do rozstrzygnięć

Raport zarządczy ma inne zadanie niż zestawienie operacyjne. Nie musi przedstawiać wszystkich zdarzeń i wykonanych czynności; powinien pokazywać, gdzie potrzebna jest interwencja kierownictwa. Przy każdej sprawie wymagającej decyzji warto wskazać:

• problem i jego wpływ na działalność — co może zostać zakłócone i jakie będą konsekwencje;
• dostępne warianty — z rekomendacją, kosztem oraz skutkami odłożenia działania;
• oczekiwaną decyzję i termin — czego konkretnie potrzebuje osoba odpowiedzialna za realizację;
• stan wcześniejszych ustaleń — co zakończono, co jest opóźnione i jakie przeszkody wymagają usunięcia.

Taki format pozwala odejść od ogólnego komunikatu „bezpieczeństwo wymaga poprawy” na rzecz decyzji, które można wykonać i później rozliczyć.

Stały rytm przeglądów i kontrola wykonania

Sprawy cyberbezpieczeństwa warto włączyć do istniejącego cyklu zarządzania: planowania budżetu, przeglądów projektów i oceny zmian biznesowych. Częstotliwość przeglądów należy dopasować do skali działalności oraz tempa zmian; przyjęty harmonogram nie powinien jednak blokować pilnej eskalacji. Uruchomienie nowej usługi lub istotna zmiana dostawcy może wymagać decyzji wcześniej niż na kolejnym zaplanowanym posiedzeniu.

Każde istotne ustalenie powinno mieć właściciela, termin i sposób potwierdzenia wykonania. Krótki rejestr decyzji pozwala sprawdzić, czy przyznany budżet przełożył się na działające zabezpieczenia, a odroczone zadania rzeczywiście wróciły pod obrady. W ten sposób nadzór staje się częścią zarządzania organizacją, a nie wyłącznie okresowym odbieraniem prezentacji od działu IT.

Tabela obowiązków i 90-dniowy plan działań dla zarządu (obowiązek → kto odpowiada → dowody/artefakty)

Zarząd potrzebuje nie tylko informacji, że organizacja „wdraża NIS2”, lecz także dowodów, że ustalono zakres obowiązków, przydzielono odpowiedzialność i uruchomiono niezbędne działania. Praktycznym narzędziem jest rejestr łączący każde wymaganie z właścicielem, terminem oraz dokumentem potwierdzającym wykonanie. Poniższe zestawienie przedstawia ten układ bez rozbudowanej macierzy.

Punktem wyjścia musi być kwalifikacja prawna organizacji. NIS2 wyznacza ramy unijne, natomiast konkretne obowiązki krajowe, terminy i zasady odpowiedzialności należy ustalać na podstawie obowiązujących przepisów KSC, z uwzględnieniem przepisów przejściowych i właściwych regulacji sektorowych. Zaproponowane 90 dni to harmonogram organizacyjny, a nie ustawowy okres na osiągnięcie zgodności.

Obowiązek → kto odpowiada → dowody wykonania

Poniższy podział wskazuje proponowanych właścicieli prac. Nie zastępuje ustawowego przypisania odpowiedzialności — powierzenie zadania CISO, działowi IT czy zewnętrznemu dostawcy nie oznacza automatycznego przeniesienia odpowiedzialności kierownika podmiotu.

• Ustalenie zakresu stosowania przepisów i wymaganych zgłoszeń rejestrowych → funkcja prawna lub compliance, przy udziale właścicieli usług i kierownictwa → udokumentowana analiza kwalifikacji podmiotu, wykaz właściwych wymagań i terminów oraz potwierdzenia zgłoszeń, jeżeli są wymagane.
• Zatwierdzanie środków zarządzania ryzykiem i nadzór nad ich wdrożeniem → właściwy organ zarządzający lub kierownik podmiotu, wspierany przez osobę koordynującą cyberbezpieczeństwo → zatwierdzone dokumenty, protokoły decyzji, przypisane zadania i zapisy przeglądów postępu.
• Wdrożenie środków bezpieczeństwa oraz zapewnienie zasobów → właściciele procesów, IT, bezpieczeństwo i zakupy, zgodnie z podziałem kompetencji → plan postępowania z ryzykiem, przyznany budżet, dokumentacja wdrożeń i wyniki testów. Sam zakup narzędzia nie potwierdza skuteczności zabezpieczenia.
• Przygotowanie obsługi incydentów i realizacji zgłoszeń → wyznaczony koordynator incydentów oraz upoważnione osoby zgłaszające → aktualna ścieżka eskalacji, dane kontaktowe, rejestr incydentów i potwierdzenia dokonanych zgłoszeń; gotowość operacyjną potwierdza również zapis ćwiczenia.
• Zapewnienie wymaganych kompetencji kierownictwa → osoby objęte obowiązkiem szkoleniowym, przy organizacyjnym wsparciu HR lub compliance → potwierdzenia udziału, program i data szkolenia, pozwalające wykazać jego adekwatność do obowiązków uczestników.
• Ocena skuteczności zabezpieczeń i usuwanie niezgodności → właściciele zabezpieczeń oraz funkcja kontrolna lub audytowa, stosownie do właściwych wymagań → wyniki ocen, testów i wymaganych audytów, rejestr działań naprawczych oraz dowody ich zamknięcia.

Dni 1–30: ustalić punkt wyjścia i pilne zobowiązania

Pierwszy miesiąc powinien zakończyć się zatwierdzeniem zakresu programu: których podmiotów, usług i systemów dotyczy, kto prowadzi prace oraz jakie terminy prawne mają zastosowanie. Należy zebrać istniejące dowody i odróżnić rzeczywiste braki zabezpieczeń od braków dokumentacyjnych. Rezultat dla zarządu: krótka diagnoza luk, lista najpilniejszych ryzyk i decyzje o odpowiedzialności oraz finansowaniu. Obowiązków już wymagalnych nie wolno odkładać do końca tego etapu.

Dni 31–60: wdrożyć priorytety i sprawdzić gotowość

Drugi etap służy realizacji działań o największym znaczeniu dla ryzyka i zgodności. Każde zadanie powinno otrzymać kryterium odbioru: nie „opracowano procedurę”, lecz przykładowo „upoważniona osoba potrafi przeprowadzić zgłoszenie incydentu na podstawie scenariusza testowego”. W Cognity łączymy teorię z praktyką – dlatego te zagadnienia rozwijamy także w formie ćwiczeń na szkoleniach.

Rezultat dla zarządu: raport wykonanych prac, wyniki pierwszych sprawdzeń oraz lista przeszkód wymagających decyzji — dodatkowych zasobów, zmiany zakresu lub interwencji u dostawcy.

Dni 61–90: zweryfikować dowody i rozliczyć odstępstwa

Ostatni etap powinien obejmować przegląd dowodów oraz sprawdzenie, czy deklarowane zabezpieczenia rzeczywiście działają. Otwarte braki trzeba opisać wraz z ich skutkami, właścicielem i terminem usunięcia. Akceptacja ryzyka nie zastępuje wykonania obowiązku prawnego. Rezultatem jest pakiet decyzyjny dla zarządu: potwierdzony stan realizacji wymagań, nierozwiązane problemy i harmonogram dalszych przeglądów. Sukcesem po 90 dniach jest wiarygodny obraz zgodności i kontrolowany plan domknięcia luk, a nie sama deklaracja zakończenia wdrożenia.

Power Query – 10 najczęstszych problemów z danymi i sposoby ich rozwiązania 04 października 2026

Power Query – jak łączyć dane z wielu plików i źródeł bez ręcznego kopiowania 02 października 2026