Skąd zarząd ma wiedzieć, że jego firma ma odpowiednie zabezpieczenia?

Ustawa o KSC nie mówi, ile zabezpieczeń wystarczy. Mówi, że mają być dobrane do oszacowanego ryzyka, i przerzuca na podmiot ciężar pokazania, dlaczego dobrał je tak, a nie inaczej.

Dlatego pytanie „czy mamy uwierzytelnianie wieloskładnikowe, kopie zapasowe, SOC i politykę?” niewiele zarządowi mówi, nawet jeśli na każde pada odpowiedź „tak”.

Zarząd wie, że zabezpieczeń jest dość, kiedy ktoś potrafi mu pokazać ciąg: która usługa, jakie ryzyko, jaka decyzja, jaki środek, jaki test i kto zaakceptował to, co zostało.

Ten tekst jest dla członków zarządu i opisuje ten ciąg: skąd się bierze, gdzie najczęściej się urywa i czego żądać od osoby, która odpowiada za cyberbezpieczeństwo w spółce.

Dlaczego ustawa nie daje listy kontrolnej?

Art. 8 ust. 1 pkt 2 ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawy o KSC) wymaga środków „odpowiednich i proporcjonalnych do oszacowanego ryzyka”, uwzględniających „najnowszy stan wiedzy, koszty wdrożenia, wielkość podmiotu, prawdopodobieństwo wystąpienia incydentów, narażenie podmiotu na ryzyka, skutki społeczne i gospodarcze”.

Dalej przepis wymienia obszary, które środki mają objąć (polityki, łańcuch dostaw, ciągłość działania, monitorowanie, kontrolę dostępu i inne), ale nie mówi, jak gruby ma być mur w każdym z nich. Z tego wynika rzecz dla zarządu niewygodna.

Dwie spółki z tego samego sektora mogą mieć różne zabezpieczenia i obie spełniać ustawę.

Pytanie „czy nie mamy mniej niż konkurencja?” nie ma więc sensu, dopóki nie wiadomo, jakie ryzyko ma każda z nich. Sensowne pytanie brzmi: dlaczego uznaliśmy, że ten poziom jest u nas adekwatny, i gdzie to jest zapisane.

Odpowiedź na nie ma kilka ogniw i każde z nich może pęknąć:

Co widać w polskich firmach?

Business Growth Review zbadał na przełomie stycznia i lutego 2026 r., czyli jeszcze przed wejściem w życie nowelizacji, 1018 firm zatrudniających ponad 300 osób. Była to ankieta internetowa; odpowiadali głównie ludzie od bezpieczeństwa, ryzyka i compliance, a członków zarządu było wśród nich 14,2 %.

Najczęściej wskazywanym obszarem niejasności był zakres wymagań (44,9 %), potem łańcuch dostaw (39,2 %) i raportowanie incydentów (38,7 %). Odpowiedzialność zarządu wskazało 33,4 % firm, a 40,9 % nie ustaliło, czy w ogóle jest podmiotem kluczowym lub ważnym.

Dla mnie ciekawsze od listy niejasności jest to, jak firmy oceniły same siebie w dziesięciu obszarach (skala od 1 do 5). Najwyżej wypadły polityki i procedury (3,63) oraz kopie zapasowe i testy odtwarzania (3,57). Najniżej reagowanie na incydenty i ćwiczenia (3,21) oraz bezpieczeństwo dostawców (3,0).

Najlepiej idzie więc to, co da się napisać i położyć na stole, a najsłabiej to, co trzeba przećwiczyć albo wymusić na kimś spoza firmy.

To samoocena, więc prawdziwy obraz jest raczej gorszy niż lepszy.

Gdzie kończy się to, co trzeba chronić?

Art. 8 ust. 1 ustawy o KSC każe wdrożyć system zarządzania bezpieczeństwem informacji (SZBI) „w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi”. Nie w całej firmie. To dobra wiadomość dla budżetu i zła dla tego, kto ma ten zakres wyznaczyć, bo każde wyłączenie trzeba umieć obronić.

Weźmy spółkę produkcyjną z systemem ERP, systemem sterowania produkcją, SCADA, magazynem, pocztą, CRM, kadrami, platformą zakupową i kilkoma usługami w chmurze.

Czy kadry są w zakresie? Zwykle nie. Czy poczta? Jeśli przez nią przychodzą zamówienia, które uruchamiają produkcję, to już tak. Czy konto administratora domeny, przez które ktoś może dojść do SCADA? Na pewno. O zakresie decydują zależności, a nie to, który dział kupił system.

Sam dokument „Zakres SZBI: systemy X, Y, Z” niczego nie dowodzi. Pokazuję zarządowi, jak do tego zakresu doszliśmy: usługa, procesy, które ją realizują, systemy, od których te procesy zależą, i dostawcy tych systemów.

Wyłączenie z uzasadnieniem obroni się przed audytorem. Wyłączenie, które po prostu się zdarzyło, bo nikt o systemie nie pomyślał, już nie.

Jak odróżnić procedurę od dowodu, że działa?

Polityka mówi: „kopie zapasowe są wykonywane codziennie”. Audytor prosi o kopię z konkretnego dnia sprzed kilku miesięcy. Potem o wynik ostatniego testu odtworzenia.

Potem o pokazanie, że ransomware, które zaszyfruje serwery produkcyjne, nie zaszyfruje razem z nimi kopii. Przy trzecim pytaniu większość segregatorów przestaje pomagać.

Rozróżniam trzy poziomy:

1. Dokument: polityka, procedura, instrukcja. Mówi, co ma się dziać.
2. Zapis: log, zgłoszenie w systemie, raport ze skanu, protokół. Pokazuje, że to się działo.
3. Dowód skuteczności: test odtworzenia z czasem, ponowny skan po poprawce, ćwiczenie incydentu z wnioskami. Pokazuje, że to działa i że ktoś to sprawdził.

Trzeci poziom nie jest moim wymysłem. Wśród obszarów z art. 8 ust. 1 pkt 2 ustawy o KSC są wprost, pod lit. h, „polityki i procedury oceny skuteczności środków technicznych i organizacyjnych”.

Kto chce zobaczyć, jak taki dowód może wyglądać w praktyce, znajdzie przykłady w wytycznych ENISA do wdrożenia NIS2 z czerwca 2025 r. Formalnie dotyczą one wybranych dostawców usług cyfrowych i infrastruktury cyfrowej, a nie każdego podmiotu, ale jako wzór tego, co audytor może uznać za dowód, przydają się każdemu.

Jak wygląda dowód, że zarząd nadzorował?

Art. 8d ustawy o KSC każe kierownikowi podmiotu podejmować decyzje o SZBI, planować adekwatne środki finansowe, przydzielać zadania i nadzorować ich wykonanie. Art. 8c ust. 3 dodaje, że kierownik odpowiada także wtedy, gdy obowiązki powierzył innej osobie.

Jeśli kierownikiem jest zarząd i nie wskazano osoby odpowiedzialnej, odpowiadają wszyscy jego członkowie (art. 8c ust. 2). Od 3 kwietnia 2028 r. organ może nałożyć na kierownika karę do 300 % wynagrodzenia (art. 73a).

„CISO zapewnił nas, że jest dobrze” nie jest dowodem nadzoru.

Dowodem jest ślad decyzji w protokołach zarządu, z którego wynika:

• jakie ryzyka przedstawiono zarządowi i kiedy;
• które zarząd zaakceptował jako ryzyko rezydualne, a które kazał ograniczyć;
• jaki budżet przyznał, a co odłożył i z jakiego powodu;
• kiedy zarząd dowiedział się o luce i co zrobił w ciągu następnego kwartału;
• czy znał wyniki testów i ćwiczeń, a nie tylko listę kupionych narzędzi.

Odłożenie wydatku jest w porządku, jeśli zarząd zrobił to świadomie i to zapisał. Źle wygląda dopiero luka, o której zarząd nie wiedział, albo taka, o której wiedział i nic z nią nie zrobił.

Czy o trzeciej w nocy ktoś wie, że to incydent poważny?

Art. 11 ust. 1 ustawy o KSC każe sklasyfikować incydent według progów i zgłosić wczesne ostrzeżenie o incydencie poważnym do CSIRT sektorowego „niezwłocznie, niepóźniej niż w ciągu 24 godzin od momentu jego wykrycia”. Pełne zgłoszenie idzie w ciągu 72 godzin.

Na papierze to proste. Tak wygląda to w nocy:

• 2:00: monitoring pokazuje nietypowy ruch;
• 3:00: wiadomo, że przejęto jeden serwer;
• 5:00: wiadomo, że napastnik chodził po sieci;
• 9:00: nadal nie wiadomo, czy wyniósł dane;
• 14:00: okazuje się, że przejęty serwer obsługuje proces, od którego zależy usługa.

Od której godziny liczą się 24 godziny? I kto o 3:00 ma prawo zdecydować, że dzwonimy do CSIRT?

Tych rozstrzygnięć nie da się wypracować w trakcie incydentu.

Kryteria klasyfikacji, nazwisko osoby, która w nocy decyduje o zgłoszeniu, i jej zastępca muszą być ustalone wcześniej i przećwiczone. W badaniu BGR 38,3 % dużych firm albo nie miało zdefiniowanych progów poważnego incydentu, albo nie wiedziało, czy je ma.

Jak głęboko sprawdzać dostawców?

W tym samym badaniu tylko 26,3 % firm deklarowało systemowe zarządzanie ryzykiem dostawców, a 28,8 % przyznało, że nie zarządza nim wcale. Zarząd słyszy wtedy pytania bez końca: czy sprawdzać firmę sprzątającą, czy da się audytować wielkiego dostawcę chmury, co z podwykonawcą naszego dostawcy.

Ustawa daje tu punkt zaczepienia. Art. 8 ust. 1 pkt 2 lit. e mówi o bezpieczeństwie łańcucha dostaw produktów, usług i procesów ICT, od których zależy świadczenie usługi, „z uwzględnieniem związków pomiędzy bezpośrednim dostawcą sprzętu lub oprogramowania a podmiotem”.

Zaczynam więc od bezpośrednich dostawców tego, co jest w zakresie SZBI. Głębiej schodzę tam, gdzie wiele systemów zależy od jednego dostawcy albo jednej chmury, bo tam awaria jednej firmy staje się awarią całej usługi. Firma sprzątająca trafia na listę tylko wtedy, gdy ma klucze do serwerowni.

Czy certyfikat ISO/IEC 27001 zamyka temat?

Nie zamyka, choć bardzo pomaga. Ustawa o KSC nie wymaga certyfikacji SZBI, a dobrze prowadzony system zgodny z normą to dobra podstawa. Dwie rzeczy trzeba jednak sprawdzić.

Pierwsza to zakres: certyfikat często obejmuje na przykład tylko serwerownię albo jeden dział, a zakres z ustawy wyznacza usługa.

Druga to obowiązki, których norma nie zna: zgłoszenia do CSIRT sektorowego w terminach ustawowych, coroczne szkolenie kierownika, informacja z Krajowego Rejestru Karnego dla osób, które realizują zadania z cyberbezpieczeństwa, wpis do wykazu podmiotów kluczowych i ważnych.

Z zarządem nie rozmawiam więc o tym, czy mamy ISO, tylko o tym, które wymagania ustawy nasze ISO pokrywa, a które nie.

Co pokazać audytorowi w 2028 r.?

Podmiot kluczowy przeprowadza audyt bezpieczeństwa systemu informacyjnego co najmniej raz na 3 lata, na własny koszt (art. 15 ust. 1 ustawy o KSC). Ci, którzy spełniali przesłanki podmiotu kluczowego w dniu wejścia w życie nowelizacji, mają na pierwszy audyt 24 miesiące (art. 33 ust. 2 ustawy nowelizującej), czyli czas do 3 kwietnia 2028 r.

Brzmi to odlegle, ale dowody trzeciego poziomu powstają tylko z upływem czasu: rok testów odtworzenia, dwa ćwiczenia incydentu, cztery kwartalne raporty dla zarządu.

Dowodów skuteczności nie da się wyprodukować w miesiąc przed wizytą audytora.

Audytu nie zrobi ta sama osoba, która prowadzi w spółce cyberbezpieczeństwo. Może natomiast przygotować zarząd na pytania, które padną. Poniżej zestawiam je z odpowiedziami, które niczego nie dowodzą, i z takimi, które coś znaczą:

Gdybym na najbliższym posiedzeniu zarządu mógł zadać tylko jedno pytanie, poprosiłbym osobę odpowiedzialną za cyberbezpieczeństwo o jedną stronę:

• krytyczne usługi spółki;
• najważniejsze ryzyka dla każdej z nich;
• zabezpieczenia, które je ograniczają, z datą ostatniego testu każdego z nich;
• ryzyka, których zarząd jeszcze nie zaakceptował ani nie kazał ograniczyć.

Jeśli taka strona powstanie w tydzień, system działa. Jeśli w odpowiedzi zarząd dostanie dwustustronicową procedurę i zrzut ekranu z panelu SOC, wie przynajmniej, od czego zacząć.

Stan prawny na dzień publikacji: 24.09.2026. Wpis nie był od tego czasu weryfikowany pod kątem zmian w przepisach. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).