W skrzynce działu IT leżą trzy wiadomości. Klient przysłał ankietę bezpieczeństwa, bo porządkuje własny łańcuch dostaw. Zarząd wrócił z konferencji z pytaniem, czy firma „podlega pod NIS2”. Dostawca przysłał ofertę na SIEM z obietnicą zgodności w kwartał. Tymczasem w tej samej firmie nikt nie potrafi w ciągu godziny odpowiedzieć na trzy prostsze pytania: które usługi biznesowe zatrzymają się, gdy padnie konkretny hiperwizor, kto ma dostęp administracyjny do jego konsoli i kiedy ostatnio ktoś tę listę sprawdził.

To jest właściwa kolejność problemu. Wymagania wynikające z dyrektywy NIS2 i z polskiej ustawy o krajowym systemie cyberbezpieczeństwa nie są listą produktów do kupienia. Są opisem tego, co organizacja ma wiedzieć o własnym środowisku, jakie ryzyka i wymagania rozumieć, jakie środki wynikają z właściwego dla niej reżimu ustawowego, jakie dodatkowe zabezpieczenia dobrać do ryzyka i jak wykazać, że wszystko to naprawdę działa.

Ten materiał nie jest poradą prawną. Kwalifikacja podmiotu, zakres obowiązków i wykładnia przepisów należą do prawnika oraz do kierownictwa firmy. Opisuję część techniczną i organizacyjno-techniczną: co trzeba wiedzieć o infrastrukturze, jakie kontrole przygotować i jaki ślad po nich zostawić, żeby dało się go pokazać podczas audytu.

Najważniejsze wnioski

  • Przepisy opisują obszary, a nie produkty. W standardowym reżimie art. 8 ust. 1 ustawa wymienia szacowanie ryzyka, kontrolę dostępu, ciągłość działania, monitorowanie czy zarządzanie aktualizacjami; dla części podmiotów ważnych art. 8 ust. 3 przewiduje odrębne minimum z załącznika nr 4. W obu przypadkach ustawa nazywa środki, a nie produkty — konkretne narzędzie wybiera podmiot.
  • Pierwszym krokiem jest kwalifikacja i zakres, nie zakup. Zanim powstanie budżet na narzędzia, musi istnieć odpowiedź na pytanie, które usługi i które systemy informacyjne w ogóle wchodzą do zakresu.
  • Dowód działania kontroli jest osobnym produktem pracy. Wdrożone zabezpieczenie i możliwość wykazania, że działa, to dwie różne rzeczy — druga wymaga zaplanowania już na etapie wdrożenia.
  • Terminy wejścia do systemu KSC są konkretne. Dla podmiotów kwalifikujących się na podstawie przesłanek ustawowych biegną od dnia ich spełnienia. Podmiot, który spełniał je 3 kwietnia 2026 r. i podlega samorejestracji, składa wniosek o wpis do 3 października 2026 r.; podmiot wpisywany z urzędu wniosku o wpis nie składa — po otrzymaniu wezwania uzupełnia brakujące dane w terminie 6 miesięcy od jego doręczenia. Wdrożenie SZBI i podłączenie do systemu S46 przypada w obu przypadkach na 3 kwietnia 2027 r.
  • Ustawa nie ustanawia certyfikatu „zgodności z NIS2”. Zgodność jest stanem organizacji ocenianym wobec przepisów; komercyjne zaświadczenie, audyt gotowości ani kupiona dokumentacja nie zastępują obowiązków wynikających z przepisów.

Co obowiązuje w sierpniu 2026: dyrektywa NIS2 i polska ustawa

Dyrektywa (UE) 2022/2555, czyli NIS2, jest aktem skierowanym do państw członkowskich, a nie wprost do firm. Obowiązki, które wykonuje dział IT prywatnego przedsiębiorstwa, wynikają więc w pierwszej kolejności z ustawy z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa w brzmieniu obowiązującym — i tam należy ich szukać, a nie w tłumaczeniu dyrektywy.

Jedna uwaga do sposobu czytania przepisów, bo oszczędza późniejszych nieporozumień. Ustawa była po nowelizacji z 2026 roku zmieniana dalej, więc pytania o stan bieżący rozstrzyga tekst ujednolicony udostępniany przy akcie w bazie ELI, a nie sam tekst nowelizacji. Nowelizację czyta się po to, żeby ustalić datę wejścia w życie, zakres zmian i przepisy przejściowe — te ostatnie wyznaczają terminy, których w tekście ujednoliconym nie ma.

To nie znaczy, że ustawa jest jedynym aktem, który może mieć zastosowanie. Część wymagań pochodzi z prawa unijnego stosowanego bezpośrednio: dla wskazanych kategorii podmiotów cyfrowych i dla dostawców usług zaufania obowiązuje rozporządzenie wykonawcze Komisji (UE) 2024/2690. W sektorach objętych regulacjami sektorowymi trzeba osobno sprawdzić ich relację do KSC — w bankowości i infrastrukturze rynków finansowych ustawa sama ustępuje pierwszeństwa rozporządzeniu (UE) 2022/2554, czyli DORA, które jest wobec NIS2 aktem szczególnym w zakresie zarządzania ryzykiem ICT i zgłaszania incydentów. Nie jest to jednak wyłączenie całego KSC dla banku: ustawa wskazuje przepisy stosowane w tym sektorze nadal, między innymi o wykazie podmiotów, o szacowaniu ryzyka i o cyberhigienie. Praktyczna zasada brzmi więc: zacznij od KSC, ale nie zakładaj, że KSC jest jedynym aktem, który cię dotyczy.

Ustawa z 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw została ogłoszona w Dzienniku Ustaw z 2 marca 2026 r. pod pozycją 252 i weszła w życie 3 kwietnia 2026 r. Zmieniła zakres podmiotowy systemu, wprowadziła kategorie podmiotu kluczowego i podmiotu ważnego, przebudowała obowiązki w zakresie zarządzania bezpieczeństwem informacji oraz zasady zgłaszania incydentów.

Terminy, które w sierpniu 2026 r. mają dla firm największe znaczenie, Ministerstwo Cyfryzacji podaje w jednym zestawieniu:

  • wniosek o wpis do Wykazu KSC — 6 miesięcy od dnia spełnienia przesłanek uznania za podmiot kluczowy lub ważny; dla początkowej grupy podmiotów, które spełniały przesłanki w dniu wejścia w życie ustawy i podlegają samorejestracji, termin złożenia wniosku upływa 3 października 2026 r.; podmioty wpisywane z urzędu wniosku o wpis nie składają — po zawiadomieniu o wpisie dostają wezwanie i uzupełniają brakujące dane w terminie 6 miesięcy od dnia jego doręczenia;
  • podłączenie do systemu S46 oraz pierwsze wdrożenie obowiązków systemu zarządzania bezpieczeństwem informacji — 12 miesięcy, czyli 3 kwietnia 2027 r.;
  • pierwszy obowiązkowy audyt podmiotu kluczowego — 24 miesiące, czyli 3 kwietnia 2028 r.; dotychczasowi operatorzy usług kluczowych, którzy wykonali audyt przed nowelizacją, zachowują swój dotychczasowy cykl.

Warto zwrócić uwagę na sposób liczenia. Te terminy biegną od dnia spełnienia przesłanek, a nie od jednej wspólnej daty. Sam przekroczony próg ani samo uruchomienie działalności statusu jeszcze nie tworzy — podmiot musi zacząć spełniać komplet przesłanek właściwych dla swojej kategorii. Podmiot, u którego stanie się to w 2027 roku — na przykład przekroczy właściwy próg wielkości, prowadząc już działalność wymienioną w załączniku do ustawy, albo rozpocznie taką działalność przy spełnionym kryterium wielkości — ma własny bieg sześciu i dwunastu miesięcy, a jeżeli staje się podmiotem kluczowym, również własny termin 24 miesięcy na pierwszy audyt. Podmiotu ważnego ten ostatni termin nie dotyczy.

Osobno liczy się status powstały z decyzji. Podmiot uznany za kluczowy albo ważny decyzją organu właściwego do spraw cyberbezpieczeństwa oraz państwowa osoba prawna uznana decyzją Ministra Cyfryzacji realizują obowiązki rozdziału o podmiotach kluczowych i ważnych w terminie 12 miesięcy, a przewidziany dla podmiotu kluczowego pierwszy audyt — w terminie 24 miesięcy; oba terminy ustawa liczy od dnia doręczenia decyzji, a nie od samoistnego spełnienia przesłanek. Tak samo od doręczenia biegnie sześciomiesięczny termin uzupełnienia danych w wykazie.

Rozporządzenie wykonawcze 2024/2690 z 17 października 2024 r. warto sprawdzić na samym początku, bo obowiązuje bezpośrednio, ale wyłącznie dla kategorii wymienionych w jego art. 1: dostawców usług DNS, rejestrów nazw domen najwyższego poziomu, dostawców usług chmurowych, dostawców usług ośrodka przetwarzania danych, dostawców sieci dostarczania treści, dostawców usług zarządzanych, dostawców usług zarządzanych w zakresie bezpieczeństwa, dostawców internetowych platform handlowych, wyszukiwarek internetowych, platform usług sieci społecznościowych oraz dostawców usług zaufania. Dla nich określa dwie rzeczy: wymogi techniczne i metodyczne dotyczące środków zarządzania ryzykiem w cyberbezpieczeństwie, wypisane w załączniku na poziomie pojedynczych środków, oraz przypadki, w których incydent uznaje się za poważny. Ministerstwo Cyfryzacji wskazuje przy tym, że progi incydentu poważnego dla tych podmiotów wynikają właśnie z tego aktu, a nie z rozporządzenia krajowego.

Warto też oddzielić dwie rzeczy, które w ofertach bywają zlepione w jedną. Ustawa nie ustanawia oficjalnego certyfikatu ani znaku „NIS2 compliant”, którego posiadanie samo w sobie dowodziłoby wykonania obowiązków — przewiduje audyt bezpieczeństwa systemu informacyjnego dla podmiotów kluczowych oraz nadzór organów właściwych. Na rynku można natomiast kupić dokument o takiej nazwie: audyt gotowości, zaświadczenie dostawcy albo certyfikat prywatnego programu. Taki dokument bywa użytecznym materiałem roboczym, ale nie zastępuje obowiązków wynikających z przepisów i nie wiąże organu nadzoru. Zgodność nie sprowadza się więc do zakupu pojedynczego produktu ani papieru.

Czy moja firma podlega KSC?

Odpowiedź wymaga trzech niezależnych ustaleń i w części przypadków konsultacji prawnej. Poniższy opis pomaga przygotować materiał do takiej rozmowy, a nie ją zastąpić.

Sektor i rodzaj działalności. Sektory objęte ustawą wymieniają załączniki nr 1 (m.in. energia, transport, bankowość i infrastruktura rynków finansowych, ochrona zdrowia, woda pitna, ścieki, infrastruktura cyfrowa, zarządzanie usługami ICT, przestrzeń kosmiczna, podmioty publiczne) oraz nr 2 (m.in. usługi pocztowe, gospodarowanie odpadami, chemikalia, żywność, wskazana produkcja przemysłowa, dostawcy usług cyfrowych, badania naukowe). Ministerstwo Cyfryzacji zaznacza w materiale o samoidentyfikacji, że ocenia się rzeczywisty charakter prowadzonej działalności, a kody PKD pełnią wyłącznie rolę pomocniczą.

Wielkość przedsiębiorstwa. Ustawa nie ustala progów samodzielnie — odsyła do załącznika I do rozporządzenia Komisji (UE) nr 651/2014. Jego art. 2 ust. 1 wyznacza pułapy kategorii mikro-, małych i średnich przedsiębiorstw: mniej niż 250 pracowników i przy tym roczny obrót nieprzekraczający 50 mln EUR albo roczna suma bilansowa nieprzekraczająca 43 mln EUR. Warunek zatrudnienia obowiązuje zawsze, a z dwóch warunków finansowych wystarczy jeden spełniony — przekroczenie samego obrotu nie czyni więc firmy dużym przedsiębiorstwem, jeżeli suma bilansowa mieści się w limicie. Dużym przedsiębiorstwem jest dopiero podmiot, który tak rozumianych pułapów nie spełnia.

Przedsiębiorstwo, które ma przedsiębiorstwa partnerskie albo powiązane, nie prowadzi przy tym rachunku wyłącznie na własnych danych. Art. 6 ust. 2–4 załącznika I każe uzupełnić je o dane przedsiębiorstw partnerskich, i to proporcjonalnie do procentowego udziału w kapitale albo w prawach głosu — zależnie od tego, która z tych wartości jest większa, a przy holdingach typu cross-holding według większego udziału procentowego. Do tego dochodzą pełne dane przedsiębiorstw bezpośrednio i pośrednio powiązanych, o ile nie zostały już ujęte w skonsolidowanym sprawozdaniu finansowym; tych samych danych nie dolicza się więc dwa razy. Przy bardziej rozbudowanej strukturze trzeba przejść cały art. 6 ust. 2–4, bo określa on również sposób ustalania danych przedsiębiorstw powiązanych z przedsiębiorstwem partnerskim i danych przedsiębiorstw partnerskich przedsiębiorstwa powiązanego, a osobno — przypadek, w którym w skonsolidowanym sprawozdaniu brakuje danych o liczbie personelu.

O tym, które przedsiębiorstwa są partnerskie, a które powiązane, rozstrzyga art. 3 załącznika — między innymi przez próg 25 procent kapitału lub głosów oraz przez większość praw głosu. Ustawa dokłada do tego dwa własne zastrzeżenia: przy badaniu wielkości podmiotów kluczowych i ważnych nie stosuje się reguły o kapitale kontrolowanym przez organ publiczny (art. 5 ust. 3), a przesłanki bada się według stanu na dzień sporządzenia sprawozdania finansowego (art. 5 ust. 5). Kwalifikacja jest więc wynikiem przyłożenia pełnej definicji do konkretnej struktury organizacyjnej, a nie odczytania jednego parametru ze sprawozdania. Do wstępnego rachunku przydaje się Kwalifikator MŚP Polskiej Agencji Rozwoju Przedsiębiorczości.

Grupy kapitałowe powinny przeczytać ten punkt do końca, bo ustawa przewiduje tu własny wyjątek. Zasadą pozostaje prawidłowe zastosowanie opisanych wyżej reguł agregowania danych. Jeżeli jednak status podmiotu kluczowego albo ważnego wynika właśnie z tej agregacji — z przewyższenia albo ze spełnienia kryteriów średniego przedsiębiorstwa zgodnie z art. 6 ust. 2–4 załącznika I — art. 5 ust. 6 i 7 ustawy pozwala ten status wyłączyć. Przesłanki są alternatywne, a nie łączne: wystarczy, że system informacyjny podmiotu jest niezależny od systemów informacyjnych jego przedsiębiorstw powiązanych lub partnerskich, albo że podmiot nie świadczy usług wspólnie z tymi przedsiębiorstwami. Spełnienie którejkolwiek z nich oznacza, zgodnie z brzmieniem przepisu, że podmiot nie jest podmiotem kluczowym (ust. 6) ani podmiotem ważnym (ust. 7).

Cztery zastrzeżenia do tej ścieżki. Po pierwsze, nie jest to uniwersalny sposób odcinania spółek grupy od obowiązków: wyjątek dotyczy sytuacji, w której status wynikał z doliczenia cudzych danych, i nie pomoże tam, gdzie podmiot spełnia przesłanki samodzielnie albo należy do kategorii objętych ustawą niezależnie od wielkości. Po drugie, nie jest to automat — wymaga sprawdzenia konkretnych zależności technicznych i podziału obowiązków przy usłudze. Po trzecie, przyjętą kwalifikację i jej podstawę warto udokumentować, bo w razie pytania organu to podmiot pokazuje, na czym oparł swój rachunek. Po czwarte, zestaw pytań i odpowiedzi Ministerstwa Cyfryzacji pomaga zrozumieć obie przesłanki w praktyce — niezależność wiąże z tym, czy do świadczenia usługi konieczne jest działanie przedsiębiorstwa powiązanego lub partnerskiego oraz czy używane rozwiązanie da się w akceptowalnym czasie i koszcie zastąpić innym o nie gorszych właściwościach — ale sam zastrzega, że nie ma mocy prawnej i nie jest dokumentem wiążącym. Źródłem wyjątku jest ustawa; ten dokument jest materiałem pomocnym przy jej wykładni.

Szczególne podstawy objęcia ustawą. Część podmiotów wchodzi do systemu bez względu na wielkość — między innymi dostawcy usług DNS, kwalifikowani dostawcy usług zaufania, rejestry nazw domen najwyższego poziomu i podmioty świadczące usługi rejestracji nazw domen, operatorzy obiektów energetyki jądrowej oraz podmioty krytyczne w rozumieniu dyrektywy CER. Osobno traktowani są dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa: podmiotem kluczowym jest tu również mały przedsiębiorca. Przedsiębiorca komunikacji elektronicznej podlega ustawie niezależnie od skali — jako podmiot kluczowy, gdy jest średnim lub dużym przedsiębiorstwem, i jako podmiot ważny, gdy jest mikro- lub małym.

W uproszczeniu, które wystarcza na pierwszą rozmowę: duże przedsiębiorstwo z załącznika nr 1 to podmiot kluczowy, średnie z załącznika nr 1 oraz średnie i duże z załącznika nr 2 to podmiot ważny. Różnica ma konsekwencje techniczne — obowiązek cyklicznego audytu bezpieczeństwa dotyczy podmiotów kluczowych.

Kiedy potrzebny jest prawnik. Przy działalności na granicy opisu z załącznika, przy grupie kapitałowej z systemami częściowo współdzielonymi, przy kilku usługach mieszczących się w różnych sektorach, przy równoległych regulacjach sektorowych oraz zawsze wtedy, gdy wynik samoidentyfikacji brzmi „chyba nie”.

Kwalifikacja, decyzja i wpis to trzy różne rzeczy. Co do zasady organizacja sama analizuje, czy spełnia przesłanki, i nie powinna biernie czekać, aż ktoś ją o tym powiadomi — błąd tej analizy obciąża podmiot. Ustawa przewiduje jednak przypadki, w których o statusie rozstrzyga decyzja: organ właściwy do spraw cyberbezpieczeństwa może uznać za podmiot kluczowy lub ważny podmiot, który zwykłych przesłanek nie spełnia, jeżeli na przykład jako jedyny świadczy usługę o kluczowym znaczeniu dla krytycznej działalności społecznej lub gospodarczej albo zakłócenie jego usługi groziłoby ryzykiem systemowym; Minister Cyfryzacji może w ten sposób uznać za podmiot kluczowy państwową osobę prawną. Osobną kwestią jest sam wpis do Wykazu KSC, a i tutaj warto rozdzielić trzy rzeczy: obowiązek złożenia wniosku, moment skuteczności wpisu oraz wpis dokonywany z urzędu. Podmioty podlegające samorejestracji składają wniosek o wpis w terminie 6 miesięcy od dnia spełnienia przesłanek; wpisu dokonuje się z chwilą złożenia wniosku w systemie teleinformatycznym, a sam wpis jest czynnością materialno-techniczną o charakterze deklaratoryjnym — obowiązki wynikają więc ze spełnienia przesłanek, a nie z figurowania w wykazie. Z urzędu dane do wykazu wprowadza Minister Cyfryzacji: dotyczy to przedsiębiorców telekomunikacyjnych, dostawców usług zaufania, podmiotów publicznych i podmiotów krytycznych, a na podstawie przepisu przejściowego nowelizacji także dotychczasowych operatorów usług kluczowych. Te podmioty dostają zawiadomienie o wpisie oraz wezwanie do uzupełnienia brakujących danych w terminie 6 miesięcy od dnia jego doręczenia. Organ właściwy może ponadto wpisać z urzędu podmiot, który sam nie zarejestrował się w terminie.

Osobna uwaga dla firm, które do systemu nie wejdą. Wymagania dotyczące łańcucha dostaw sprawiają, że pytania o kontrolę dostępu, zgłaszanie incydentów i utrzymanie systemów zaczną przychodzić od klientów objętych ustawą. Przygotowanie techniczne przydaje się więc również poza zakresem podmiotowym.

Najpierw zakres i inwentaryzacja, dopiero potem narzędzia

Obowiązek dotyczy systemu informacyjnego wykorzystywanego w procesach wpływających na świadczenie usługi. To sformułowanie ma bezpośrednie skutki operacyjne: zanim powstanie polityka albo budżet, musi istnieć mapa prowadząca od usługi biznesowej przez procesy do konkretnych hostów, aplikacji i danych. Systemy w pełni odseparowane od świadczenia usługi pozostają poza tym zakresem, ale to trzeba wykazać, a nie założyć.

Podmiot publiczny ma tu jeszcze jedną regułę zakresu, wynikającą z art. 8 ust. 4. Uwzględnia w swoim systemie zarządzania bezpieczeństwem informacji również system informacyjny dostarczany przez inny podmiot publiczny — w szczególności zapewniający działanie rejestru publicznego — w zakresie odpowiadającym własnym kompetencjom, wynikającym z polityki bezpieczeństwa tego systemu lub z przepisów regulujących jego działanie. System utrzymywany przez inną jednostkę publiczną nie jest więc automatycznie „poza naszym SZBI”; poza nim zostaje tylko to, co wykracza poza zakres kompetencji podmiotu.

W praktyce potrzebna jest wiedza o kilkunastu warstwach naraz:

  • usługi biznesowe i procesy, które je realizują, wraz z właścicielem po stronie biznesu;
  • systemy wspierające, których zatrzymanie zatrzymuje usługę — również te „niewidoczne”, jak katalog tożsamości, serwer wydruku czy system księgowy;
  • hosty fizyczne, maszyny wirtualne, klastry i platformy kontenerowe;
  • urządzenia sieciowe, punkty styku i kanały zdalnego dostępu;
  • domeny, strefy DNS, certyfikaty i ich terminy ważności;
  • usługi wystawione do Internetu wraz z zakresami adresów IP;
  • dostawcy i utrzymywane przez nich elementy środowiska;
  • konta, tożsamości, grupy uprawnień i konta techniczne;
  • zależności między systemami, w tym te ujawniające się dopiero przy odtwarzaniu;
  • dane: gdzie leżą, jak są klasyfikowane, komu wolno je czytać;
  • kopie zapasowe: co obejmują, gdzie są, kto ma do nich dostęp;
  • właściciel techniczny każdego systemu i jego krytyczność dla usługi.

To jest zakres, w którym brak uporządkowanej ewidencji ujawnia luki bardzo szybko — i jednocześnie ten, który da się nadrobić bez zakupów. Sposób prowadzenia takiej ewidencji opisuje osobno materiał o CMDB i dokumentacji infrastruktury IT; tam jest też argument, dlaczego arkusz aktualizowany raz do roku bywa gorszy od braku ewidencji.

Praktyczna wskazówka na start: nie próbuj zinwentaryzować całego środowiska naraz. Weź jedną usługę o największej krytyczności, przejdź ją do końca — od procesu biznesowego po nazwy hostów, konta i kopie zapasowe — i dopiero ten wzorzec powiel. Taki przegląd ujawnia również zasoby, których w ewidencji wcześniej nie było; zjawisko opisuje materiał o Shadow IT w firmie.

Inwentaryzacja ma jeszcze jeden, całkiem prozaiczny powód. Wniosek o wpis do Wykazu KSC wymaga podania między innymi zakresu publicznych adresów IP oraz domen internetowych wykorzystywanych przez podmiot w sposób ciągły. Firma, która tej listy nie ma, dowiaduje się o tym w momencie wypełniania formularza.

Od ryzyka do kontroli technicznej

W standardowym reżimie art. 8 ust. 1 ustawa wymaga systematycznego szacowania ryzyka wystąpienia incydentu oraz wdrożenia odpowiednich i proporcjonalnych do tego ryzyka środków technicznych i organizacyjnych. Katalog obszarów, które te środki mają objąć, jest w art. 8 ust. 1 pkt 2 znowelizowanej ustawy i obejmuje między innymi polityki szacowania ryzyka i bezpieczeństwa systemu informacyjnego, bezpieczeństwo w procesie nabywania i utrzymania systemów, bezpieczeństwo fizyczne, bezpieczeństwo zasobów ludzkich, łańcuch dostaw, plany ciągłości działania, monitorowanie w trybie ciągłym, ocenę skuteczności środków, edukację personelu, kryptografię, zarządzanie aktywami i politykę kontroli dostępu.

Ważny wyjątek: część podmiotów ważnych stosuje załącznik nr 4

Ten katalog nie jest uniwersalny — to ważne rozróżnienie, które w rozmowach o KSC łatwo przeoczyć. Art. 8 ust. 3 wprost wyłącza stosowanie ust. 1 wobec dwóch grup. Pierwsza to podmiot ważny będący podmiotem publicznym — w załączniku nr 2 sektor „podmioty publiczne” obejmuje samorządowe jednostki i zakłady budżetowe, samorządowe instytucje kultury oraz spółki wykonujące zadania o charakterze użyteczności publicznej. Druga to podmioty wymienione w art. 7 ust. 1 pkt 1–4 i 6–7 Prawa o szkolnictwie wyższym i nauce — o ile nie są organizacją badawczą, w zakresie, w jakim realizują zadania publiczne z wykorzystaniem systemów informacyjnych. Są to uczelnie, federacje podmiotów systemu szkolnictwa wyższego i nauki, PAN, instytuty naukowe PAN, instytuty międzynarodowe, Centrum Łukasiewicz, instytuty Sieci Badawczej Łukasiewicz, Centrum Medyczne Kształcenia Podyplomowego oraz PAU; wskazany zakres 6–7 obejmuje bowiem także punkty 6a–6c, umieszczone w tym przepisie między pkt 6 a pkt 7. Katalog jest zamknięty: instytutów badawczych z pkt 5 ani podmiotów prowadzących głównie działalność naukową z pkt 8 w nim nie ma, a uczelnia będąca organizacją badawczą wraca do pełnego reżimu art. 8 ust. 1.

Zamiast katalogu z ust. 1 art. 8 ust. 3 odsyła obie wymienione wyżej grupy do wymogów załącznika nr 4 do ustawy: podmiot, o którym mowa w tym przepisie, opracowuje, wdraża, realizuje, monitoruje i utrzymuje — w systemach informacyjnych, które kontroluje — system zarządzania bezpieczeństwem informacji spełniający te wymogi.

Warto przy tym oddzielić normę odsyłającą od redakcji aktu, do którego odsyła. Tytuł załącznika nr 4 brzmi „Wymogi dla systemu zarządzania bezpieczeństwem informacji dla podmiotu ważnego będącego podmiotem publicznym”, a jego części I–IV konsekwentnie posługują się tym samym określeniem — o drugiej grupie z art. 8 ust. 3 sam załącznik nie wspomina. To asymetria redakcyjna: przepis odsyła obie grupy, literalne brzmienie załącznika mówi o jednej. Ministerstwo Cyfryzacji w aktualnym zestawie pytań i odpowiedzi przyjmuje, że uczelnia niebędąca organizacją badawczą również stosuje obowiązki z załącznika nr 4 — ale dokument ten sam zastrzega, że nie ma mocy prawnej i nie jest dokumentem wiążącym. Podmiot z drugiej grupy, podejmując na tym tle istotną decyzję prawną, powinien tę asymetrię uwzględnić i w razie potrzeby potwierdzić wykładnię.

Załącznik ma cztery części i to podział, od którego zaczyna się każda praktyczna rozmowa o zakresie prac. Część I to minimum obowiązkowe, wyliczone przez ustawodawcę jako „co najmniej”. Część II ma charakter fakultatywny — SZBI „może dodatkowo obejmować” wymienione tam środki. Część III określa przegląd systemu: co najmniej raz w roku albo bezzwłocznie po rekomendacji Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa lub po wystąpieniu okoliczności mogących wpłynąć na ryzyko incydentu poważnego. Część IV nakazuje dokumentować realizację zaplanowanych działań.

Obowiązkowe minimum jest konkretne i w dużej części techniczne. Wymienię przykłady, a nie całość: inwentaryzacja produktów, usług i procesów ICT służących do przetwarzania informacji; kontrola podstawowych wersji używanych produktów i mechanizmy kontroli ich instalacji; dopuszczanie do informacji wyłącznie osób z odpowiednimi uprawnieniami wraz ze środkami uniemożliwiającymi nieautoryzowany dostęp; zasada minimalnych uprawnień; bezzwłoczne cofanie uprawnień po ustaniu podstawy dostępu i zawieszanie ich przy dłuższym niewykonywaniu obowiązków; kopie zapasowe odseparowane logicznie i fizycznie od danych produkcyjnych; testowanie ich kompletności i możliwości odtworzenia; przygotowana i przetestowana procedura na wypadek awarii lub incydentu; oprogramowanie antywirusowe; cyberhigiena i szkolenia personelu wraz z kierownikiem podmiotu; monitorowanie cyklu życia produktów ICT oraz stosowanie wersji stabilnych, wobec których nie występują informacje o krytycznych podatnościach.

Osobnej ostrożności wymaga szacowanie ryzyka, bo tutaj najłatwiej rozciągnąć skrót myślowy za daleko. Ministerstwo Cyfryzacji wyjaśnia w aktualnym zestawie pytań i odpowiedzi, że podmiot ważny będący podmiotem publicznym, który stosuje załącznik nr 4, formalnie nie ma obowiązku przeprowadzania szacowania ryzyka — i zastrzega od razu, że analiza ryzyka nie jest w żaden sposób zakazana, a część II załącznika pozwala stosować dodatkowe środki, jeżeli są konieczne. Ten dokument jest wykładnią pomocniczą, a nie przepisem: sam podaje, że nie ma mocy prawnej i nie jest dokumentem wiążącym. Odpowiedź odnosi się przy tym do kontekstu art. 8 — wyłączeniu podlega prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu i zarządzanie tym ryzykiem, czyli obowiązek z art. 8 ust. 1 pkt 1, bo art. 8 ust. 3 wyłącza stosowanie całego ust. 1.

Nie znaczy to jednak, że sama ustawa nie stawia takiemu podmiotowi żadnych wymagań dotyczących ryzyka. Art. 10 nakłada obowiązek prowadzenia dokumentacji bezpieczeństwa na podmiot kluczowy lub podmiot ważny, bez zawężenia do reżimu art. 8 ust. 1, a w dokumentacji ochrony infrastruktury, z wykorzystaniem której świadczona jest usługa, art. 10 ust. 3 pkt 2 wymienia osobno szacowanie ryzyka dla obiektów infrastruktury oraz plan postępowania z ryzykiem. To wymóg węższy i innego rodzaju niż proces z art. 8 ust. 1 pkt 1: dotyczy obiektów infrastruktury, a nie systematycznego szacowania ryzyka wystąpienia incydentu, i żadnego z tych dwóch procesów nie należy podstawiać za drugi. Niezależnie od KSC obowiązek oceny ryzyka może wynikać jeszcze z innych przepisów; Ministerstwo wskazuje tu art. 32 RODO. Odpada więc konkretny obowiązek z art. 8 ust. 1 pkt 1, a nie użyteczność samej metody: bez rozpoznania ryzyk trudno uzasadnić, dlaczego wybrano akurat takie środki, i trudno rozstrzygnąć, które pozycje z fakultatywnej części załącznika warto dołożyć.

Stąd zasada czytania dalszej części tego materiału. Punktów katalogu art. 8 ust. 1 nie wolno automatycznie przenosić na grupę z art. 8 ust. 3 jako jej ustawowego minimum — i tam, gdzie różnica jest istotna, zaznaczam ją przy konkretnej kontroli. Rozróżnienie dotyczy jednak tego, czego dany reżim wymaga literalnie, a nie tego, co warto wdrożyć: większość opisanych niżej kontroli pozostaje rozsądną praktyką techniczną również dla podmiotu stosującego załącznik nr 4. Warto też pilnować zakresów, bo nie pokrywają się ze sobą — wyjątek z art. 8 ust. 3 obejmuje obie opisane grupy, a uproszczenie ścieżki raportowej z art. 12c dotyczy już wyłącznie podmiotu ważnego będącego podmiotem publicznym.

Słowo „proporcjonalne” jest tu istotne i nie oznacza „mniej” — należy przy tym do reżimu art. 8 ust. 1. Ministerstwo Cyfryzacji tłumaczy je przez harmonię środków: rozbudowany zespół bezpieczeństwa z politykami i zaawansowanym SIEM-em nie będzie efektywny, jeżeli równocześnie zaniedbane zostanie szkolenie personelu z podstaw cyberhigieny. Kontrola dobrana bez rozpoznania zagrożeń i kontekstu bywa źle priorytetyzowana, niedopasowana do środowiska albo daje mniej, niż od niej oczekiwano — dlatego programu bezpieczeństwa nie warto zaczynać od narzędzia. Dla podmiotu stosującego załącznik nr 4 proporcjonalność nie zmienia natomiast ustawowego minimum części I.

Roboczy łańcuch, który sprawdza się przy przekładaniu analizy ryzyka na pracę zespołu utrzymania, wygląda tak: ryzyko → zasób → scenariusz → kontrola → właściciel → monitoring → dowód działania → sposób testowania. Każde ogniwo odpowiada na inne pytanie, a brak któregokolwiek widać później w audycie.

Tabelę można przewijać w poziomie.

Przykładowe mapowanie ryzyka na kontrolę, monitoring i dowód. Układ roboczy, a nie formularz przewidziany przepisami. W reżimie art. 8 ust. 1 zestaw wierszy wynika z analizy ryzyka; w reżimie załącznika nr 4 ta sama siatka pozwala rozpisać ustawowe minimum i środki dodatkowe na właściciela, monitoring, test i dowód.
Ryzyko i zasób Kontrola techniczna Monitoring i test Dowód działania
Przejęcie konta administracyjnego hiperwizora Konta imienne, uwierzytelnianie wieloskładnikowe, ograniczenie uprawnień do niezbędnych Kwartalny przegląd dostępów, rejestrowanie logowań i zmian Raport z przeglądu z podpisem właściciela, logi sesji administracyjnych
Ransomware w segmencie serwerowym Segmentacja sieci, odizolowana kopia zapasowa, osobne poświadczenia backupu Monitorowanie zadań kopii, cykliczny test odtworzenia wybranej usługi Protokół z testu ze zmierzonym czasem odtworzenia i punktem powrotu
Podatność w usłudze wystawionej do Internetu Ewidencja usług publicznych, skanowanie, aktualizacja po ocenie wpływu Ponowny skan po naprawie, kontrola terminów w rejestrze wyjątków Raport z remediacji, wpis w rejestrze zmian, rejestr wyjątków z terminem
Utrata dostępu do systemu utrzymywanego przez dostawcę Ewidencja dostawców, konta imienne dla serwisu, dostęp czasowy Przegląd aktywnych kont dostawców, alert przy logowaniu spoza okna prac Rejestr nadanych i odebranych dostępów, potwierdzenia zamknięcia prac

Tabela jest narzędziem roboczym. Przepisy nie przewidują tu obowiązkowego formularza, a w reżimie art. 8 ust. 1 metodykę szacowania ryzyka wybiera sam podmiot — istotne jest, żeby proces był opisany, powtarzalny i faktycznie prowadzony, a nie jednorazowy. Dla podmiotu stosującego załącznik nr 4 nie ma zastosowania systematyczny proces szacowania ryzyka wystąpienia incydentu z art. 8 ust. 1 pkt 1 — co nie oznacza braku wszelkich obowiązków dotyczących ryzyka, bo dokumentacja z art. 10 osobno obejmuje szacowanie ryzyka dla obiektów infrastruktury i plan postępowania z ryzykiem. Pierwsza kolumna wypełnia się natomiast inaczej: w wierszach stają najpierw obowiązkowe środki części I, które obowiązują niezależnie od wyniku własnej analizy, a obok nich środki dobrane ponad to minimum — z części II załącznika albo z rozpoznanej ekspozycji. Sam układ pozostaje użyteczny w obu reżimach, bo pomaga przypisać środkom właściciela oraz zaplanować dowód działania i dokumentowanie realizacji działań przewidziane w części IV załącznika.

Dostęp administracyjny i uwierzytelnianie

Art. 8 ust. 1 wymienia wśród środków polityki kontroli dostępu, a osobno — stosowanie bezpiecznych środków komunikacji elektronicznej uwzględniających uwierzytelnianie wieloskładnikowe „w stosownych przypadkach”. Treść obu punktów rozwija Ministerstwo Cyfryzacji: polityka ma wskazywać, kto uzyskuje dostęp fizyczny i logiczny do zasobów, obejmować zarządzanie prawami dostępu wraz z ich anulowaniem — również dla personelu dostawcy — prowadzenie rejestru udzielonych dostępów oraz zarządzanie tożsamościami użytkowników i systemów, a jako przykłady „stosownych przypadków” dla MFA wskazuje zdalne logowanie, dostęp do wrażliwych informacji i konta administratorów.

Załącznik nr 4 reguluje tę samą warstwę inaczej i w części miejsc konkretniej. Jego obowiązkowe minimum obejmuje dopuszczanie do informacji wyłącznie osób z odpowiednimi uprawnieniami wraz ze środkami uniemożliwiającymi nieautoryzowany dostęp, zasadę minimalnych uprawnień, bezzwłoczne cofanie uprawnień po ustaniu podstawy dostępu, zawieszanie ich przy niewykonywaniu obowiązków przez co najmniej miesiąc oraz modyfikację zakresu uprawnień po zmianie charakteru zadań. Klauzuli MFA z art. 8 ust. 1 nie ma jednak w tej części literalnie i nie należy jej tam dopisywać. Technicznie nie zmienia to rekomendacji: uwierzytelnianie wieloskładnikowe pozostaje jedną z najskuteczniejszych kontroli dostępu administracyjnego i zdalnego, a część II załącznika wprost dopuszcza dodatkowe środki techniczne i organizacyjne, jeżeli są konieczne dla odpowiedniego poziomu bezpieczeństwa.

Po stronie środowiska oznacza to zestaw spraw, które w większości nie wymagają nowego produktu, tylko decyzji i konsekwencji:

  • konta imienne zamiast współdzielonych — konto imienne daje najlepszą bezpośrednią atrybucję działań, a konto wspólne istotnie ją osłabia; jeżeli system technicznie wymusza konto współdzielone, sesję trzeba powiązać z osobą inną warstwą kontroli: indywidualnym uwierzytelnieniem do bastionu lub systemu PAM, wydaniem poświadczenia na czas prac i zapisem sesji — sam fakt posiadania takiego narzędzia niczego jeszcze nie przesądza, liczy się to, czy każdą sesję da się przypisać konkretnej osobie;
  • uprawnienia ograniczone do niezbędnych, przeglądane cyklicznie, a nie przy okazji migracji;
  • kontrola nad root i sudo — kto może eskalować, do czego i czy ta eskalacja zostawia ślad;
  • konta techniczne i serwisowe z właścicielem, udokumentowanym przeznaczeniem i planem rotacji poświadczeń;
  • cykl życia dostępu: nadanie, zmiana roli, odebranie — z potwierdzeniem odebrania jako osobnym artefaktem;
  • dostęp dostawców ograniczony czasowo i powiązany z konkretnym zleceniem;
  • rejestrowanie działań administracyjnych w miejscu, którego nie kasuje osoba wykonująca te działania.

Szczegółowo temat rozwija materiał o zarządzaniu dostępami uprzywilejowanymi w Linux i IT, a warstwę poświadczeń — kontrola credentiali, sekretów i dostępu administracyjnego. Tutaj wystarczy jeden wniosek: przegląd dostępów bez zapisu wyniku nie jest dowodem, że przegląd się odbył.

Osobna sprawa to odporność metody uwierzytelniania na phishing. Aktualnym dokumentem odniesienia jest NIST SP 800-63B-4, który zastąpił wycofane SP 800-63B — starsze wydanie bywa jeszcze cytowane we wdrożeniach i w ofertach, warto to sprawdzać. Zgodnie z nim hasła jednorazowe, uwierzytelnianie poza pasmem i sekrety wyszukiwane nie są odporne na phishing. CISA we wskazówkach dotyczących wdrażania odpornego na phishing MFA wskazuje jako powszechnie dostępne rozwiązanie tej klasy uwierzytelnianie FIDO/WebAuthn, a dopasowanie numeru traktuje jako środek przejściowy dla organizacji, które nie mogą wdrożyć go od razu.

To nie znaczy, że każde konto w firmie wymaga klucza sprzętowego. Znaczy tyle, że wybór metody powinien wynikać z oceny ryzyka konkretnego dostępu — i że dla kont z uprawnieniami do całego środowiska wirtualizacji argument „mamy MFA” bywa za słaby, jeżeli tym MFA jest kod SMS. Techniczną stronę tego wyboru rozwija osobny materiał o MFA odpornym na phishing i wdrożeniu FIDO2 w firmie: różnice między metodami, projekt rejestracji i odtwarzania dostępu oraz kolejność migracji kont.

Podatności i aktualizacje

W reżimie art. 8 ust. 1 ustawa wymaga zbierania informacji o cyberzagrożeniach i podatnościach dotyczących systemu informacyjnego oraz regularnego przeprowadzania aktualizacji oprogramowania z uwzględnieniem analizy wpływu aktualizacji na bezpieczeństwo usługi i poziomu krytyczności poszczególnych poprawek. Ministerstwo Cyfryzacji dodaje do tego komentarz, który warto zapamiętać: podmiot odpowiada za bezpieczeństwo własnych systemów i nie powinien bezrefleksyjnie kierować się zaleceniami producenta, tylko samodzielnie ocenić wpływ aktualizacji.

Załącznik nr 4 rozkłada te akcenty inaczej i warto tych dwóch katalogów nie mieszać. W jego części obowiązkowej znajduje się monitorowanie częstotliwości wydawania kolejnych wersji produktów ICT, źródeł ich dystrybucji oraz cyklu życia produktów, a także stosowanie wersji stabilnych, wobec których nie występują informacje o krytycznych podatnościach — z dopuszczeniem wersji, które nie wpływają istotnie negatywnie na poziom bezpieczeństwa, jeżeli takie informacje się pojawią. Samo „zapewnienie aktualności wykorzystywanych produktów ICT oraz usług ICT” wymieniono natomiast w części dodatkowej. Proces opisany niżej pozostaje właściwy dla obu grup — z tą różnicą, że dla podmiotu z art. 8 ust. 3 jest doborem środka, a nie literalnym punktem ustawowego minimum.

W środowisku produkcyjnym różnicę robi rozdzielenie ośmiu kroków, które w raportach ze skanera zlewają się w jeden:

  1. wykrycie — skaner zgłasza obecność wersji podatnej;
  2. ocena ekspozycji — czy usługa jest osiągalna z Internetu, z sieci użytkowników, czy wyłącznie z segmentu zarządzania;
  3. ocena ryzyka — co się stanie, gdy ten konkretny host padnie albo zostanie przejęty;
  4. priorytetyzacja — kolejność wynikająca z ekspozycji, realnego wykorzystywania podatności i krytyczności zasobu;
  5. poprawka — aktualizacja albo zmiana konfiguracji usuwająca przyczynę;
  6. wyjątek — świadoma decyzja o odroczeniu, z terminem, uzasadnieniem i właścicielem;
  7. kontrola kompensacyjna — to, co ogranicza ryzyko na czas trwania wyjątku;
  8. weryfikacja po naprawie — ponowny skan lub test potwierdzający, że problem zniknął.

Sama liczba w skali CVSS nie wyznacza kolejności napraw. CVSS ocenia cechy samej podatności, a nie to, ile ryzyka wnosi ona do konkretnego środowiska — do decyzji biznesowej potrzebne są jeszcze trzy przesłanki. Pierwsza to sygnał o rzeczywistym wykorzystywaniu: katalog znanych wykorzystywanych podatności (KEV) zbiera podatności, dla których istnieją dowody wykorzystania w atakach, a CISA zaleca traktować go jako jedno z wejść do własnego procesu priorytetyzacji, a nie jako całą listę zadań. Druga to ekspozycja — czy podatny system jest w ogóle osiągalny dla potencjalnego atakującego. Trzecia to krytyczność zasobu, czyli co się dzieje z usługą, gdy ten konkretny host zostanie przejęty. Sposób złożenia tych przesłanek w powtarzalną decyzję opisuje CISA w materiale o SSVC.

Sposób przełożenia raportu skanera na listę prac opisuje materiał o tym, jak z raportu OpenVAS zrobić plan napraw, a stronę wykonawczą — aktualizacje serwerów Linux w produkcji. Dla audytu istotne jest to, czego w obu tych materiałach dotyczy końcówka procesu: rejestr wyjątków z terminem oraz dowód, że po naprawie ktoś sprawdził wynik.

Monitoring, logi i wykrywanie

W standardowym reżimie art. 8 ust. 1 objęcie systemu informacyjnego wykorzystywanego do świadczenia usługi monitorowaniem w trybie ciągłym jest wymaganiem ustawowym. Ministerstwo Cyfryzacji doprecyzowuje jego cel — zapewnienie rozliczalności działań i możliwość odtworzenia tego, co działo się w systemie — oraz wymienia obszary, które monitorowanie powinno objąć w szczególności: ruch do i z podmiotu, dostęp do systemu, konta z dostępem uprzywilejowanym, krytyczne pliki konfiguracyjne i kopie zapasowe, logi narzędzi bezpieczeństwa oraz zdarzenia środowiskowe mogące wpłynąć na infrastrukturę.

Dla grupy z art. 8 ust. 3 minimum wygląda inaczej i to jedno z ważniejszych miejsc, w których łatwo o nadinterpretację. Monitorowanie dostępu do informacji oraz stanu działania systemów informacyjnych — prowadzone dedykowanym oprogramowaniem albo przez dostawcę usług zarządzanych w zakresie cyberbezpieczeństwa — jest w załączniku nr 4 środkiem z części fakultatywnej. Część obowiązkowa wymaga w tym obszarze przede wszystkim procedury na wypadek awarii lub incydentu i jej przetestowania. Z punktu widzenia realnego bezpieczeństwa nie zmienia to jednak rekomendacji: bez obserwacji dostępu i stanu systemów incydent bywa wykrywany dopiero po skutkach, a zgłoszenie incydentu poważnego — które podmiot ważny będący podmiotem publicznym nadal składa — wymaga wskazania momentu wykrycia, przebiegu zdarzenia i jego wpływu na usługę. Fakultatywność w załączniku oznacza swobodę doboru środka, a nie powód, żeby monitoringu nie mieć.

Równie ważne jest to, czego przepis nie wymaga. Nie ma obowiązku posiadania własnego centrum operacji bezpieczeństwa — Ministerstwo Cyfryzacji odpowiada na to pytanie wprost w zestawie pytań i odpowiedzi do nowelizacji: nie narzucono rozwiązań technicznych ani organizacyjnych, a podmiot sam decyduje, czy buduje kompetencje wewnętrznie — również w ramach grupy kapitałowej — czy korzysta z usługi zewnętrznej.

Praktyczne minimum operacyjne — nie cytat z przepisu, tylko to, bez czego reszta pozostaje trudna do policzenia w obu reżimach:

  • synchronizacja czasu we wszystkich systemach — bez niej korelacja zdarzeń między hostem, firewallem i aplikacją wymaga ręcznego kompensowania rozjazdów zegarów i daje mniej pewny obraz kolejności zdarzeń, a raportowanie incydentu poważnego opiera się na wskazaniu momentu jego wystąpienia i wykrycia;
  • centralizacja logów poza hostem, którego dotyczą, wraz z określoną retencją;
  • integralność i kontrola dostępu do zapisów — logi są tu zarówno narzędziem operacyjnym, jak i dokumentacją operacyjną w rozumieniu wymagań dokumentacyjnych SZBI;
  • rozdzielenie monitoringu dostępności od monitoringu bezpieczeństwa — pierwszy odpowiada na pytanie, czy usługa działa, drugi na pytanie, czy dzieje się z nią coś nietypowego;
  • alert z właścicielem i ze zdefiniowaną reakcją — powiadomienie, którego nikt nie obsługuje, nie zapewnia skutecznej kontroli operacyjnej ani terminowej reakcji;
  • test alarmu — sprawdzenie, czy wykrycie faktycznie dociera do osoby dyżurnej i w jakim czasie.

Warstwę logów rozwija materiał o centralizacji i retencji logów Linux, a podział ról między narzędziami — Wazuh, Zabbix i firewall jako jeden model działania. Jakość samych powiadomień warto przy okazji przejrzeć według metody z materiału o audycie alertów IT — przygotowanie do audytu jest dobrym momentem, żeby usunąć alerty, których nikt nie czyta.

Backup, odtwarzanie i ciągłość działania

W reżimie art. 8 ust. 1 ustawa wymienia trzy osobne plany, które trzeba wdrożyć, udokumentować, przetestować i utrzymywać: plan ciągłości działania, plan awaryjny systemu informacyjnego oraz plan odtworzenia działalności po zdarzeniu przekraczającym zdolność odbudowy własnymi środkami. Załącznik nr 4 stawia w tym miejscu inne, węższe minimum: wykonywanie kopii zapasowych odseparowanych logicznie i fizycznie od danych przetwarzanych w systemach służących realizacji zadania publicznego, testowanie tych kopii pod kątem kompletności i możliwości odtworzenia danych oraz przygotowanie i przetestowanie procedury na wypadek awarii lub incydentu. Trzech nazwanych planów w jego części obowiązkowej nie ma, a zapewnienie wysokiej dostępności systemów informacyjnych wymieniono w części dodatkowej.

Rozdzielenie pojęć nie jest formalnością — w praktyce operacyjnej odpowiadają one na cztery różne pytania:

  • backup — czy dane i konfiguracje są skopiowane poza system źródłowy;
  • restore — czy da się z tej kopii odtworzyć konkretny system, w znanym czasie, ze znanym punktem powrotu;
  • disaster recovery — czy da się odbudować środowisko po utracie podstawowej lokalizacji lub platformy;
  • ciągłość działania — czy firma potrafi realizować usługę w czasie, gdy systemy są odtwarzane.

Model „3-2-1” bywa przywoływany jako odpowiedź na wszystkie cztery pytania i nią nie jest. To zasada organizacji kopii, która nie mówi nic o czasie odtworzenia, o poprawności odtworzonych danych ani o tym, czy poświadczenia do systemu kopii nie leżą w tej samej domenie, którą właśnie przejęto. Przepisy w obu reżimach mówią o testowaniu — planów albo kopii i procedury awaryjnej — a nie o liczbie egzemplarzy; i to test jest tym, co zostawia dowód.

Na wynik odtworzenia szczególnie wpływają trzy sprawy: izolacja kopii przeznaczonej na scenariusz ransomware, osobne poświadczenia i osobna ścieżka dostępu do systemu kopii oraz przećwiczony wariant utraty całego środowiska podstawowego — łącznie z tym, skąd wtedy bierze się dokumentacja i hasła. Szerzej opisuje to materiał o backupie i odtwarzaniu po awarii, a wybór punktu powrotu po kompromitacji — odtwarzanie po ransomware.

Segmentacja i ograniczanie zasięgu incydentu

Segmentacji ustawa nie wymienia z nazwy w żadnym z dwóch katalogów. W reżimie art. 8 ust. 1 mieści się ona w wymaganiu bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego — Ministerstwo Cyfryzacji wskazuje segmentację systemów prowadzoną na podstawie analizy ryzyka wprost w komentarzu do tego punktu. W obowiązkowej części załącznika nr 4 osobnego wymogu segmentacji nie ma; jest natomiast wymóg zapewnienia środków uniemożliwiających nieautoryzowany dostęp do systemów, a segmentacja pozostaje jednym ze sposobów jego realizacji. Jej rola w przygotowaniu do KSC jest ta sama co w zarządzaniu ryzykiem w ogóle: ogranicza zasięg pojedynczego zdarzenia i zwiększa liczbę miejsc, w których można je wykryć. Nie jest zabezpieczeniem przed samym wejściem do środowiska.

Praktyczny model — strefy, macierz przepływów, migracja etapami i testowanie obu stron polityki — opisuje osobny materiał o segmentacji sieci firmowej na VLAN-y i strefy. Z punktu widzenia przygotowania do audytu dokładam do niego trzy artefakty: aktualną macierz przepływów, zapis z cyklicznego przeglądu reguł zapory oraz wynik testu potwierdzającego, że ruch niedozwolony jest faktycznie blokowany, a wymagany działa.

Powierzchnia ataku i usługi publiczne

Dane wymagane do wykazu nie są formalnością administracyjną — ustawa pyta o zakres publicznych adresów IP oraz domeny internetowe wykorzystywane w sposób ciągły, czyli o listę, którą i tak trzeba znać, żeby zarządzać ryzykiem. Warto jednak od razu oddzielić dwie rzeczy: ten zestaw trafia do wniosku, a pełny obraz ekspozycji jest szerszy. Poza wnioskiem zostają certyfikaty i ich terminy, rekordy DNS pozostałe po wycofanych systemach, panele administracyjne dostępne z Internetu, usługi uruchomione na chwilę, hosty, o których nikt już nie pamięta, oraz środowiska testowe, które miały być tymczasowe.

Metodę systematycznego odkrywania tego, co firma wystawiła na zewnątrz, opisuje materiał o External Attack Surface Management. W kontekście KSC ma on jedno dodatkowe zastosowanie: wynik takiego przeglądu jest naturalnym punktem wyjścia do rozmowy o zakresie SZBI, bo pokazuje systemy, o których w ewidencji nie było mowy.

Dostawcy i łańcuch dostaw

W reżimie art. 8 ust. 1 ustawa wymaga zapewnienia bezpieczeństwa i ciągłości łańcucha dostaw produktów, usług i procesów ICT, od których zależy świadczenie usługi, z uwzględnieniem relacji z bezpośrednim dostawcą sprzętu lub oprogramowania; przy doborze środków podmiot bierze pod uwagę między innymi podatności związane z dostawcą, ogólną jakość jego produktów i usług oraz wyniki skoordynowanej oceny bezpieczeństwa przeprowadzonej przez Grupę Współpracy. Ministerstwo Cyfryzacji wskazuje przy tym na konieczność prowadzenia aktualnego wykazu bezpośrednich dostawców z danymi kontaktowymi i informacją, co dostarczają, na kryteria wyboru dostawców w polityce oraz na postanowienia umowne dotyczące zgłaszania incydentów i informowania o podatnościach. Podejście do zarządzania ryzykiem łańcucha dostaw opisuje też poradnik ENISA o dobrych praktykach w tym obszarze.

W załączniku nr 4 dostawcy pojawiają się w innym miejscu i w węższym zakresie. Część obowiązkowa dotyka ich raz: przy korzystaniu z usług dostawcy chmury obliczeniowej lub centrum przetwarzania danych trzeba udokumentować mechanizmy ochrony przetwarzanych informacji. Zapisy w umowach serwisowych ze stronami trzecimi gwarantujące odpowiedni poziom bezpieczeństwa systemów, a także kontrola zasad korzystania z ogólnodostępnych usług chmurowych i dużych generatywnych modeli sztucznej inteligencji, są już w części dodatkowej. Ogólnego wymogu bezpieczeństwa łańcucha dostaw znanego z art. 8 ust. 1 ten załącznik nie powtarza — co nie zmienia tego, że dostęp dostawcy do środowiska trzeba kontrolować, bo to wprost wynika z jego obowiązkowych wymagań dotyczących uprawnień.

Umowy są tu domeną prawnika. Po stronie technicznej zostaje zestaw pytań, na które trzeba umieć odpowiedzieć bez szukania po skrzynkach pocztowych:

  • kto po stronie dostawcy ma dostęp do naszego środowiska i pod jakimi kontami;
  • do których systemów sięga ten dostęp i jakie ma uprawnienia;
  • jak jest nadawany, na jaki czas i kto go odbiera po zakończeniu prac;
  • które elementy środowiska dostawca faktycznie utrzymuje, a które tylko wdrożył;
  • gdzie przetwarzane i przechowywane są dane powierzone dostawcy;
  • jakie zależności techniczne powstały przy okazji: konta w chmurze, tunele VPN, klucze API, integracje;
  • jak monitorujemy ten dostęp i czy logowanie serwisu poza oknem prac wywoła alert;
  • co dzieje się po zakończeniu współpracy: odebranie kont, kluczy, certyfikatów i dostępu do repozytoriów.

Ostatni punkt szczególnie łatwo zostawić niedomknięty. Konto serwisowe wyłączone „na wszelki wypadek dopiero po kwartale” to konto aktywne przez kwartał.

Incydent: technologia musi współpracować z procedurą

Obsługa incydentów jest miejscem, w którym część techniczna i część proceduralna spotykają się pod presją czasu. Ustawa wiąże je konkretnymi terminami. Wczesne ostrzeżenie o incydencie poważnym zgłasza się niezwłocznie, nie później niż w ciągu 24 godzin od momentu wykrycia; samo zgłoszenie incydentu poważnego — nie później niż w ciągu 72 godzin od wykrycia, a w przypadku dostawcy usług zaufania w ciągu 24 godzin; sprawozdanie końcowe z obsługi incydentu — nie później niż w ciągu miesiąca od dnia zgłoszenia. Sprawozdanie okresowe przekazuje się na wniosek CSIRT sektorowego. Zgłoszenia idą przez system S46.

Podmiot ważny będący podmiotem publicznym ma tu uproszczoną ścieżkę raportową, ale warto przeczytać art. 12c dokładnie. Stosuje się do niego art. 11 i art. 12 z wyjątkiem przepisów o przekazywaniu wczesnego ostrzeżenia, sprawozdania okresowego, sprawozdania z postępu obsługi incydentu i sprawozdania końcowego. Z etapów raportowych pozostaje więc zgłoszenie incydentu poważnego na zasadach art. 11 — co do zasady w ciągu 72 godzin od wykrycia; jeżeli ten sam podmiot jest równocześnie dostawcą usług zaufania, zastosowanie ma szczególny 24-godzinny termin z art. 11 ust. 1a, którego art. 12c nie wyłącza. Wyłączenie obejmuje cztery wymienione dokumenty, a nie pozostałe obowiązki związane z incydentem: obsługa incydentu, klasyfikacja go jako poważnego według progów, zapewnienie właściwemu CSIRT dostępu do informacji o rejestrowanych incydentach, współdziałanie przy obsłudze incydentu poważnego i krytycznego, usuwanie wskazanych podatności oraz informowanie użytkowników usługi pozostają w mocy. Uproszczenie zmniejsza liczbę dokumentów, a nie zakres pracy nad incydentem.

Jedna ścieżka bywa pomijana przy pisaniu procedury. Dla podmiotów objętych pełną ścieżką raportową obsługa incydentu nie musi zamknąć się w miesiącu: jeżeli w terminie sprawozdania końcowego nadal trwa, podmiot przekazuje wtedy CSIRT sektorowemu sprawozdanie z postępu obsługi, a sprawozdanie końcowe — nie później niż w ciągu miesiąca od zakończenia obsługi incydentu. Miesięczny termin oznacza więc moment pierwszego rozliczenia, a nie deklarację, że po miesiącu sprawa jest zamknięta. Ten fragment procedury nie dotyczy podmiotu, dla którego art. 12c wyłącza oba te dokumenty.

Progi decydujące o tym, kiedy incydent jest poważny, są w sierpniu 2026 r. w stanie przejściowym i warto sprawdzić ten stan przed opisaniem procedury. Znowelizowana ustawa nakazuje Radzie Ministrów określić je rozporządzeniem, z wyłączeniem podmiotów, dla których progi ustaliła już Komisja Europejska w bezpośrednio stosowanym akcie wykonawczym — czyli w rozporządzeniu 2024/2690. Nowe rozporządzenie nie zostało dotąd wydane. W mocy pozostaje rozporządzenie Rady Ministrów z 31 października 2018 r. w sprawie progów uznania incydentu za poważny, ale na podstawie przepisu przejściowego nowelizacji: do dnia wejścia w życie nowych przepisów wykonawczych i nie dłużej niż przez 12 miesięcy od wejścia w życie nowelizacji. Praktyczny wniosek jest podwójny. Progów z 2018 roku nie należy automatycznie przykładać do każdej nowej kategorii podmiotów, bo powstały pod poprzedni zakres podmiotowy. Podmioty objęte rozporządzeniem 2024/2690 czytają natomiast swoje kryteria wprost z aktu unijnego — i nie jest to kwestia rozstrzygania kolizji dwóch przepisów. Sama delegacja z art. 11 ust. 4 ustawy wyłącza z zakresu przyszłego rozporządzenia Rady Ministrów progi dla podmiotów, dla których określiła je już Komisja Europejska w akcie wykonawczym wydanym na podstawie dyrektywy. Przepis krajowy po prostu nie sięga tam, gdzie kryteria zostały ustalone aktem unijnym.

Praktyczny przebieg wygląda tak: wykrycie → kwalifikacja → eskalacja → zabezpieczenie śladów → ograniczenie skutków → komunikacja → obowiązek raportowy → odtworzenie → wnioski. Kilka miejsc na tej ścieżce jest technicznie wrażliwych.

Moment wykrycia trzeba umieć wskazać. Od niego biegną opisane wyżej terminy: 24 godziny na wczesne ostrzeżenie tam, gdzie jest ono wymagane, i co do zasady 72 godziny na zgłoszenie incydentu poważnego; dla dostawcy usług zaufania art. 11 ust. 1a przewiduje 24 godziny. Jeżeli pierwsze sygnały pojawiły się w logach, a nikt ich nie odczytał, ustalenie tego momentu po fakcie wymaga zapisów, które już istnieją, są zachowane i dają się skorelować po porównywalnych znacznikach czasu — mogą to być logi hosta, aplikacji i zapory, telemetryka sieciowa albo zapisy po stronie dostawcy usługi. Centralizacja logów bardzo to ułatwia, bo porządkuje retencję, pozwala odseparować zapisy od hosta, którego dotyczą, ograniczyć do nich dostęp i sprowadzić je do jednej osi czasu. Sama agregacja nie czyni ich jednak niezmienialnymi — o tym rozstrzygają kontrola dostępu do systemu zbierającego, rozdzielenie ról i mechanizmy kontroli integralności zapisów. Centralizacja nie jest też jedyną drogą do odtworzenia przebiegu.

Naprawa potrafi skasować materiał dowodowy. Reinstalacja hosta nieodwracalnie usuwa część lokalnych śladów, a sama w sobie nie dowodzi ani usunięcia przyczyny, ani tego, jak daleko incydent sięgnął — poświadczenia mogły wyciec, a punkt wejścia leżeć gdzie indziej. To, co robić najpierw, jest kompromisem między ograniczaniem skutków a udokumentowaniem stanu i zależy od sytuacji; ślady, które da się zabezpieczyć przed destrukcyjną zmianą, warto jednak zabezpieczyć, bo to z nich powstaje opis przyczyny i przebiegu wymagany w zgłoszeniu. Kolejność działań w pierwszej godzinie opisuje materiał o pierwszych 60 minutach incydentu na serwerze Linux.

Zgłoszenie wymaga danych, których nie da się wymyślić. Trzeba podać, na które usługi incydent wpłynął, ilu użytkowników dotyczy, jaki jest zasięg geograficzny, czy ucierpiały inne podmioty, jaka była przyczyna i przebieg oraz jakie działania zapobiegawcze i naprawcze podjęto. Zgłoszenie może ponadto zawierać inne istotne informacje o przebiegu zdarzenia — na przykład oznaki naruszenia integralności systemu. Wszystkie te informacje pochodzą z ewidencji zasobów, monitoringu i zapisów z obsługi zdarzenia.

Procedura musi być przećwiczona. Dokument opisujący eskalację, którego nikt nie przeszedł w warunkach ćwiczenia, w praktyce oznacza szukanie numeru telefonu w środku nocy. Formę zapisu, który daje się użyć pod presją, opisuje materiał o runbookach i dokumentacji operacyjnej.

Skala zjawiska nie jest hipotetyczna. Zgodnie z raportem rocznym CERT Polska za 2025 rok zespół otrzymał 658 320 zgłoszeń i zarejestrował na ich podstawie 260 783 unikalne incydenty bezpieczeństwa; 253 238 z nich, czyli 97,1 procent, stanowiły oszustwa komputerowe. Ataków ransomware odnotowano 179 — wobec 147 rok wcześniej i 161 w rekordowym dotąd 2023 roku. Te liczby opisują cztery różne rzeczy i nie warto ich mieszać: zgłoszenie to nie to samo co zarejestrowany incydent, a incydent ransomware to nie to samo co incydent poważny w rozumieniu ustawy — raport zaznacza, że żaden z zarejestrowanych w 2025 roku ataków ransomware nie spełnił progów incydentu poważnego.

Jakie dowody warto mieć przed audytem

Audyt bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi przeprowadza na własny koszt podmiot kluczowy — co najmniej raz na trzy lata, licząc od dnia sporządzenia i podpisania przez audytorów raportu z poprzedniego audytu; kopię raportu przekazuje się organowi właściwemu do spraw cyberbezpieczeństwa w terminie 3 dni roboczych od dnia otrzymania raportu przez podmiot. Cykliczny obowiązek nie obejmuje podmiotów ważnych, ale audyt może im zostać nakazany: organ właściwy może w drodze decyzji nakazać zewnętrzny audyt podmiotowi kluczowemu w każdym czasie, a podmiotowi ważnemu — w przypadku wystąpienia incydentu poważnego lub innego naruszenia przepisów ustawy przez ten podmiot.

Audyt może przeprowadzić akredytowana jednostka oceniająca zgodność, co najmniej dwóch audytorów z wymaganymi certyfikatami albo z udokumentowaną praktyką, a także CSIRT sektorowy — ale wyłącznie ustanowiony w ramach sektora lub podsektora wymienionego w załączniku nr 1 do ustawy i pod warunkiem, że jego audytorzy spełniają te same wymagania co audytorzy z poprzedniej grupy. Istotne technicznie jest wyłączenie wynikające z konfliktu ról: audytu nie może przeprowadzić osoba, która w audytowanym podmiocie realizuje zadania objęte art. 8 oraz art. 9–13 ustawy — na przykład prowadzi SZBI, utrzymuje dokumentację bezpieczeństwa albo obsługuje i zgłasza incydenty — ani osoba, która realizowała te zadania w ciągu roku przed dniem rozpoczęcia audytu (czyli w dwunastu miesiącach liczonych wstecz od tego dnia, a nie w poprzednim roku kalendarzowym).

Dokumentacja dzieli się na dwie części, co warto uwzględnić przy planowaniu pracy. Dokumentacja normatywna opisuje usługę, systemy, infrastrukturę i sposób zarządzania bezpieczeństwem. Dokumentacja operacyjna to zapisy potwierdzające, że opisane czynności są wykonywane — w tym automatycznie generowane wpisy w dziennikach systemów. Ta druga część jest w praktyce zbiorem dowodów.

Zestaw, który warto mieć zebrany i datowany:

  • aktualna inwentaryzacja zasobów z właścicielami i krytycznością;
  • wyniki cyklicznych przeglądów dostępów wraz z listą zmian po przeglądzie;
  • raporty ze skanowania podatności i zapisy z remediacji;
  • historia aktualizacji z odnotowaną oceną wpływu dla zmian krytycznych;
  • wyniki testów odtworzenia: co odtwarzano, w jakim czasie, z jakim punktem powrotu;
  • wyniki testów planów awaryjnych i odtworzenia działalności;
  • konfiguracja monitoringu i retencji logów wraz z zapisem faktycznego przechowywania;
  • wyniki testów alarmów: czy powiadomienie dotarło i w jakim czasie;
  • dokumentacja obsłużonych incydentów, łącznie z tymi, które nie były poważne;
  • rejestr wyjątków z uzasadnieniem, terminem i kontrolą kompensacyjną;
  • potwierdzenia odebrania dostępów po zakończeniu współpracy lub zmianie roli;
  • zapisy z przeglądów reguł zapory i macierzy przepływów;
  • wykaz bezpośrednich dostawców z zakresem dostarczanych produktów i usług ICT;
  • zapisy ze szkoleń personelu oraz ze szkolenia kierownika podmiotu.

Sam dokument nie dowodzi, że kontrola działa. Ministerstwo Cyfryzacji formułuje to bez ogródek: kupiona dokumentacja podpisana przez zarząd i odłożona na półkę nie zapewni realnego cyberbezpieczeństwa w organizacji. Dowodem jest zapis z wykonania czynności — data, zakres, wynik, osoba odpowiedzialna — a nie polityka opisująca, że czynność powinna być wykonywana.

Warto też pamiętać, że odpowiedzialność za wdrożenie SZBI, wpis do wykazu, wyznaczenie osób kontaktowych, korzystanie z S46, zgłaszanie incydentów i przeprowadzanie audytów przypisano kierownikowi podmiotu — i pozostaje ona po jego stronie także wtedy, gdy zadania powierzono komuś innemu. Kierownik podlega przy tym corocznemu szkoleniu z wykonywania tych zadań.

Realistyczna kolejność przygotowania

Kolejność wynika z zależności, a nie z długości listy. Bez kwalifikacji nie da się ustalić właściwego reżimu ani zakresu, bez zakresu nie da się zinwentaryzować właściwych systemów, a bez inwentaryzacji analiza ryzyka opisuje środowisko, którego nie ma. Sama analiza nie jest przy tym warunkiem powstania obowiązków — w reżimie załącznika nr 4 minimum wynika wprost z ustawy — ale bez niej trudno ustawić kolejność prac i uzasadnić, co dokładamy ponad to minimum.

  1. Kwalifikacja prawna — ustalenie, czy i jako jaki podmiot firma wchodzi do systemu; materiał techniczny do tej rozmowy przygotowuje dział IT.
  2. Właściwy reżim — art. 8 ust. 1 albo art. 8 ust. 3 wraz z załącznikiem nr 4; od tej odpowiedzi zależy, co jest ustawowym minimum, a co doborem.
  3. Zakres — które usługi i procesy wchodzą do SZBI i które systemy informacyjne je obsługują.
  4. Inwentaryzacja — zasoby, zależności, dostępy, dane, kopie, dostawcy, właściciele.
  5. Analiza ryzyka — scenariusze dla zasobów o największej krytyczności, nie dla wszystkiego naraz. W reżimie art. 8 ust. 1 systematyczne szacowanie ryzyka wystąpienia incydentu jest obowiązkiem ustawowym z art. 8 ust. 1 pkt 1. W reżimie załącznika nr 4 tego konkretnego obowiązku nie ma, ale pozostaje wymóg z art. 10: szacowanie ryzyka dla obiektów infrastruktury wraz z planem postępowania z ryzykiem w dokumentacji ochrony infrastruktury. Szersza analiza cyberryzyka jest tam natomiast narzędziem praktycznym — pozwala ustawić priorytety i uzasadnić środki dodatkowe.
  6. Baseline — w art. 8 ust. 1 środki proporcjonalne do oszacowanego ryzyka, w reżimie załącznika nr 4 co najmniej komplet z części I.
  7. Środki dodatkowe i priorytety — co dokładamy ponad baseline i w jakiej kolejności: z ryzyka, z części II załącznika, z innych wymogów prawnych i z faktycznej ekspozycji.
  8. Monitoring i testy — objęcie systemów obserwacją, która daje rozliczalność i możliwość odtworzenia przebiegu zdarzeń, oraz testy odtworzenia, alarmów, procedury incydentowej i reguł sieciowych.
  9. Dokumentacja i dowody — normatywna i operacyjna, powstająca razem z pracą, a nie po niej.
  10. Cykliczne przeglądy — ryzyka, dostępów, dostawców, reguł i samej dokumentacji; w reżimie załącznika nr 4 przegląd SZBI ma dodatkowo własny rytm wskazany w części III.

Część działań idzie równolegle i warto to wykorzystać. Inwentaryzacja, przegląd dostępów administracyjnych, uporządkowanie synchronizacji czasu i centralizacja logów nie wymagają zamkniętej analizy ryzyka — a każde z nich jest wejściem do tej analizy. Podobnie test odtworzenia wybranej usługi: można go wykonać w pierwszym miesiącu i potraktować jego wynik jako materiał wejściowy, a nie jako końcowe potwierdzenie.

Formalne zadania mają własny kalendarz. Wpis do Wykazu KSC, wyznaczenie osób do kontaktu i uzyskanie dostępu do S46 nie zależą od stanu technicznego środowiska i nie ma powodu, żeby czekały na zakończenie prac wdrożeniowych.

Najczęstsze błędy

  • Zaczynanie od zakupów. Narzędzie kupione przed ustaleniem zakresu może objąć nie te systemy, które trzeba, i generować dane, których nikt nie czyta.
  • Utożsamianie zgodności z wdrożeniem SIEM. Monitorowanie jest jednym z obszarów wymienionych w przepisach, obok kilkunastu innych — i samo w sobie niczego nie potwierdza.
  • Brak zakresu i właścicieli. Bez przypisania systemu do usługi i do osoby każda kontrola wisi w próżni, a audytor nie ma kogo zapytać.
  • Nieaktualna inwentaryzacja. Ewidencja opisująca stan sprzed dwóch reorganizacji bywa gorsza od jej braku, bo tworzy fałszywe poczucie kontroli.
  • MFA tylko dla części dostępu administracyjnego. Jedna niezabezpieczona ścieżka — stary bastion, dostęp awaryjny, konsola dostawcy — bywa drogą obejścia pozostałych zabezpieczeń i mocno ogranicza korzyść z MFA wdrożonego gdzie indziej.
  • Skanowanie bez procesu napraw. Raport pozostawia zapis, że podatność została wykryta; bez procesu napraw nie ma jednak dowodu jej terminowej obsługi i remediacji.
  • Backup bez testu odtworzenia. Zadanie zakończone statusem „sukces” mówi o kopii, a nie o możliwości powrotu do działania.
  • Logi bez osoby reagującej. Samo zbieranie zdarzeń nie tworzy skutecznego procesu reakcji, dopóki ktoś nie ma obowiązku ich analizować i obsługiwać w określonym czasie.
  • Procedura incydentowa, której nikt nie przećwiczył. Pierwsze uruchomienie procedury nie powinno przypadać na prawdziwy incydent.
  • Dostęp dostawców bez cyklu życia. Konta serwisowe zostają aktywne latami, bo nikt nie odpowiada za ich zamknięcie.
  • Dokumentacja opisująca stan sprzed kilku lat. Rozjazd między dokumentem a rzeczywistością jest w audycie gorszym sygnałem niż brak dokumentu.
  • Traktowanie audytu jako jednorazowego projektu. Wymagania dotyczą procesu prowadzonego stale i jednorazowy zryw go nie zastępuje: podmiot kluczowy powtarza audyt co najmniej raz na trzy lata, a podmiot ważny może zostać zobowiązany do audytu w przypadkach przewidzianych ustawą.

Najczęstsze pytania

Czy każda firma w Polsce podlega NIS2 i KSC?

Nie. Objęcie ustawą wynika z sektora działalności wskazanego w załącznikach, rodzaju rzeczywiście prowadzonej działalności oraz wielkości przedsiębiorstwa, do której co do zasady dolicza się dane przedsiębiorstw partnerskich i powiązanych. Znaczna część firm spoza tych sektorów pozostaje poza zakresem — ale może odczuć wymagania pośrednio, jako dostawca podmiotu objętego ustawą.

Czy mała firma może zostać objęta wymaganiami?

Tak, w określonych przypadkach. Ustawa wymienia podmioty objęte niezależnie od wielkości — między innymi dostawców usług DNS, kwalifikowanych dostawców usług zaufania czy podmioty rejestrujące nazwy domen. Osobno traktowani są dostawcy usług zarządzanych w zakresie cyberbezpieczeństwa, wśród których podmiotem kluczowym jest również mały przedsiębiorca, oraz przedsiębiorcy komunikacji elektronicznej, którzy podlegają ustawie w każdej skali.

Czy ISO 27001 automatycznie oznacza zgodność z KSC?

Nie. Wdrożony system zarządzania bezpieczeństwem informacji według uznanego standardu bardzo pomaga — istniejącą dokumentację i procesy można wykorzystać i dostosować. Zgodność ocenia się jednak wobec przepisów ustawy, a jej zakres, terminy zgłaszania incydentów i obowiązki wobec organów nie pokrywają się z zakresem certyfikacji.

Czy trzeba wdrożyć SIEM?

Nie, KSC nie nakazuje zakupu konkretnego SIEM-u. W standardowym reżimie art. 8 ust. 1 pkt 2 lit. g wymaga objęcia systemu informacyjnego wykorzystywanego do świadczenia usługi monitorowaniem w trybie ciągłym. Praktyczny cel tego monitoringu — wspieranie rozliczalności działań oraz analizy i odtwarzania zdarzeń w systemie — wyjaśnia aktualny, niewiążący zestaw pytań i odpowiedzi Ministerstwa Cyfryzacji, a nie sam przepis. W reżimie załącznika nr 4 monitorowanie dostępu do informacji i stanu działania systemów jest środkiem z części dodatkowej — co nie zwalnia z doboru środków odpowiadających rzeczywistym zagrożeniom i innym przepisom, którym podmiot podlega. Ministerstwo Cyfryzacji wprost dopuszcza budowanie kompetencji własnych, korzystanie z usług zewnętrznych i narzędzia otwarte — wybór należy do podmiotu.

Czy Zabbix wystarczy do spełnienia wymagań monitoringu?

O zgodności nie przesądza samo narzędzie, tylko to, co i w jakim celu obserwuje. Zabbix dobrze obsługuje monitorowanie dostępności i wydajności. Art. 8 ust. 1 wymaga natomiast monitorowania w trybie ciągłym, a aktualny, niewiążący zestaw pytań i odpowiedzi Ministerstwa Cyfryzacji wskazuje jako przykłady monitorowanych zdarzeń między innymi dostęp do systemu, konta z dostępem uprzywilejowanym, krytyczne pliki konfiguracyjne, kopie zapasowe, ruch do i z podmiotu oraz logi narzędzi bezpieczeństwa — a to już obserwacja zdarzeń bezpieczeństwa, nie samej dostępności. W reżimie załącznika nr 4 monitorowanie dostępu i stanu systemów jest środkiem z części dodatkowej, ale samo rozróżnienie między obserwacją dostępności a obserwacją bezpieczeństwa pozostaje aktualne. W wielu środowiskach oznacza to zestaw narzędzi, a nie jedno; podział ról między nimi opisuje osobny materiał o modelu działania Wazuha, Zabbiksa i zapory.

Czy MFA jest wymagane wszędzie?

Art. 8 ust. 1 wskazuje stosowanie uwierzytelniania wieloskładnikowego „w stosownych przypadkach”, a Ministerstwo Cyfryzacji podaje jako przykłady zdalne logowanie, dostęp do wrażliwych informacji i konta administratorów. Zakres wynika więc z analizy ryzyka. Podmioty stosujące załącznik nr 4 mają inny literalny katalog minimum i klauzuli MFA w jego części obowiązkowej nie ma — nie znaczy to, że MFA jest tam zabezpieczeniem zbędnym czy niewłaściwym; dla dostępu administracyjnego i zdalnego pozostaje jedną z najskuteczniejszych kontroli, a załącznik pozwala stosować środki dodatkowe. Dla kont dających kontrolę nad całym środowiskiem warto rozważyć metodę odporną na phishing, zgodnie z aktualnymi zaleceniami NIST i CISA.

Czy backup 3-2-1 oznacza spełnienie wymagań ciągłości działania?

Nie. To zasada organizacji kopii. W reżimie art. 8 ust. 1 wymagania dotyczą wdrożenia, udokumentowania, przetestowania i utrzymywania planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności. W reżimie załącznika nr 4 obowiązkowe minimum to kopie odseparowane logicznie i fizycznie od danych produkcyjnych, testowanie ich kompletności i możliwości odtworzenia danych oraz przygotowana i przetestowana procedura na wypadek awarii lub incydentu. W obu przypadkach dowodem jest wynik testu odtworzenia ze zmierzonym czasem i punktem powrotu, a nie liczba egzemplarzy kopii.

Od czego zacząć, jeśli firma nie ma CMDB ani pełnej dokumentacji?

Od jednej usługi o największej krytyczności. Przejście jej do końca — proces, systemy, hosty, konta, zależności, kopie — daje wzorzec do powielenia i od razu ujawnia najpoważniejsze luki. Równolegle warto uporządkować synchronizację czasu i centralizację logów, bo bez wiarygodnego czasu i scentralizowanych zapisów późniejsze ustalenia są znacznie trudniejsze do zweryfikowania i mniej wiarygodne.

Jak przygotować dowody działania kontroli?

Planując je razem z kontrolą, a nie po fakcie. Przy każdym wdrażanym środku warto od razu ustalić, kto go wykonuje, w jakim cyklu, gdzie zapisuje wynik i jak wygląda ten zapis. Najprostsze dowody to datowane raporty z przeglądów, protokoły z testów odtworzenia, zapisy z remediacji i logi z zachowaną retencją.

Czy TaKeN.PL może pomóc w technicznej części przygotowania infrastruktury?

Tak, w części technicznej i organizacyjno-technicznej: inwentaryzacja środowiska, uporządkowanie dostępu administracyjnego, monitoring i centralizacja logów, zarządzanie podatnościami i aktualizacjami, testy odtworzenia oraz przygotowanie zapisów, które można pokazać podczas audytu. Kwalifikacja prawna podmiotu, wykładnia przepisów i dokumentacja formalna pozostają po stronie prawnika i kierownictwa firmy.

Źródła

Dokumenty, na których oparte są twierdzenia w tym materiale. Stan prawny sprawdzony 9 sierpnia 2026 r.

Przepisy i wykładnia urzędowa

Uwierzytelnianie, podatności i odporność środowiska

Podsumowanie

Przygotowanie do KSC i NIS2 nie jest projektem zakupowym. Techniczna część zaczyna się od wiedzy o środowisku: które usługi są krytyczne, jakie systemy je obsługują, kto ma do nich dostęp i co się stanie, gdy zabraknie któregoś elementu. Dalej drogi się rozchodzą: w reżimie art. 8 ust. 1 analiza ryzyka prowadzi do kontroli proporcjonalnych do tego ryzyka, a w reżimie załącznika nr 4 obowiązkowe minimum wynika już z samej ustawy — analiza pomaga wtedy wdrożyć je w rozsądnej kolejności i zdecydować o środkach dodatkowych. W obu przypadkach kontrola potrzebuje właściciela, sposobu testowania i zapisu, którym da się wykazać, że rzeczywiście działa.

Terminy są znane i policzalne, a większość pierwszych kroków nie wymaga budżetu na narzędzia: inwentaryzacja, przegląd dostępów administracyjnych, synchronizacja czasu, centralizacja logów i test odtworzenia jednej usługi dają więcej wiedzy o stanie gotowości niż jakikolwiek zakup wykonany przed tymi ustaleniami.

Jeżeli chcesz przełożyć to na prace w konkretnym środowisku, najbliżej temu materiałowi do bezpieczeństwa środowiska IT — uporządkowania ekspozycji, dostępów, podatności i dowodów działania kontroli. Warstwę utrzymania systemów obejmuje administracja serwerami Linux, a obserwowalność i reakcję — monitoring infrastruktury IT.