System zarządzania bezpieczeństwem informacji (SZBI) a KSC – wymagania i wdrożenie

System zarządzania bezpieczeństwem informacji (SZBI) to obowiązek podmiotów kluczowych i ważnych z ustawy o krajowym systemie cyberbezpieczeństwa (KSC), a nie jeden dokument ani jedno narzędzie IT. SZBI obejmuje szacowanie ryzyka, dobór środków technicznych i organizacyjnych, zarządzanie aktywami, incydentami, łańcuchem dostaw, ciągłością działania, monitoringiem, kryptografią, kontrolą dostępu i szkoleniami — oraz dowody, że wszystko to realnie działa.

Ten artykuł wyjaśnia, z czego składa się SZBI zgodnie z art. 8 ustawy o KSC, czym różni się dokumentacja normatywna od operacyjnej, dlaczego kupiona dokumentacja nie zastąpi wdrożenia, jakich dowodów może żądać organ nadzorczy oraz jak zaplanować audyt SZBI krok po kroku. Pokazuje też, gdzie kończy się warstwa techniczna, którą dostarcza Inteca, a zaczyna warstwa prawna, którą prowadzi kancelaria.

Czym jest system zarządzania bezpieczeństwem informacji w organizacji?

System zarządzania bezpieczeństwem informacji to praktycznie „system pracy” organizacji nad bezpieczeństwem informacji, a nie pojedynczy dokument ani pojedyncze narzędzie IT. Obejmuje zasady (polityki), sposób działania (procesy), odpowiedzialności (role) oraz dowody wykonania, które da się sprawdzić w audycie. Tak rozumiany system zarządzania bezpieczeństwem informacji jest podstawą bezpieczeństwa w skali całej firmy, bo łączy ryzyko biznesowe z wymaganiami technicznymi.

Jaki jest cel systemu zarządzania bezpieczeństwem informacji?

Celem systemu zarządzania bezpieczeństwem informacji jest utrzymanie akceptowalnego poziomu ryzyka dla informacji i usług poprzez świadome decyzje: co chronić, przed czym, jakimi środkami i jak to udowodnić. SZBI wspiera decyzje o priorytetach inwestycji (np. monitoring, backup, segmentacja), o akceptacji ryzyka oraz o tym, jak reagować na incydenty bez utraty ciągłości działania. Naturalnym kolejnym krokiem jest zrozumienie, z jakich elementów składa się SZBI wymagany przez art. 8 ustawy o KSC.

Z czego składa się system zarządzania bezpieczeństwem informacji wg art. 8 ustawy o KSC?

System zarządzania bezpieczeństwem informacji obejmuje dziewięć powiązanych ze sobą obszarów: zarządzanie ryzykiem, zarządzanie aktywami, kontrolę dostępu, obsługę incydentów, bezpieczeństwo łańcucha dostaw, ciągłość działania, monitorowanie i wykrywanie zagrożeń, kryptografię wraz z bezpieczną komunikacją oraz szkolenia personelu. Dokumentacja jest ważna, ale w SZBI liczy się przede wszystkim to, czy zabezpieczenia działają i czy organizacja potrafi to wykazać dowodami — logami, wynikami testów, rejestrami zmian.

Dokumentacja SZBI dzieli się na dwie części o różnej funkcji. Ministerstwo Cyfryzacji wyjaśnia to wprost:

„Dokumentacja normatywna to ta część dokumentacji, która opisuje świadczoną usługę, systemy, infrastrukturę oraz funkcjonowanie bezpieczeństwa informacji w podmiocie. Dokumentacja operacyjna potwierdza wykonywanie czynności opisanych w dokumentacji normatywnej.”

W praktyce oznacza to, że sama polityka bezpieczeństwa (dokumentacja normatywna) nie wystarcza — organizacja musi też pokazać logi, raporty z testów, protokoły przeglądów i rejestry zmian, czyli dokumentację operacyjną potwierdzającą, że polityka jest stosowana.

W tym miejscu warto precyzyjnie rozgraniczyć role. Inteca dostarcza dokumentację techniczną SZBI — polityki i konfiguracje gotowe na audyt, powiązane z logami, testami i procesami operacyjnymi, obejmujące IAM, monitoring, kryptografię, ciągłość działania i łańcuch dostaw. Inteca nie dostarcza natomiast całości dokumentacji SZBI w warstwie prawnej — definiowania formalnej struktury SZBI, polityk normatywnych w rozumieniu prawnym czy kwalifikacji podmiotu jako kluczowego lub ważnego. To zadanie kancelarii, z którą Inteca koordynuje harmonogram wdrożenia.

Czym jest SZBI w kontekście ustawy o krajowym systemie cyberbezpieczeństwa?

System zarządzania bezpieczeństwem informacji to zorganizowany sposób zarządzania ryzykiem dla informacji i systemów informacyjnych, oparty o polityki, procesy, role, pomiary i dowody wykonania. W kontekście ustawy o krajowym systemie cyberbezpieczeństwa SZBI staje się narzędziem spełnienia obowiązków podmiotów kluczowych i podmiotów ważnych, a nie „projektem IT”. Podstawowy obowiązek FAQ ministerstwa o KSC opisuje w ten sposób:

„Podstawowym obowiązkiem podmiotów kluczowych i podmiotów ważnych będzie wdrożenie systemu zarządzania bezpieczeństwem informacji (SZBI) w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi, obejmującego prowadzenie systematycznego szacowania ryzyka wystąpienia incydentu oraz zarządzanie tym ryzykiem, a także wdrożenie odpowiednich i proporcjonalnych do oszacowanego ryzyka środków technicznych i organizacyjnych.”

To podejście wymusza rozliczalność, bo ocenie podlega nie deklaracja, lecz skuteczność wdrożenia i możliwość wykazania dowodów.

Jakie ryzyka obejmuje system zarządzania bezpieczeństwem informacji?

System zarządzania bezpieczeństwem informacji obejmuje ryzyka naruszenia poufności, integralności i dostępności informacji, ale przekłada je na konkretne scenariusze: wyciek, modyfikację danych lub przerwę w usługach. Triada poufność–integralność–dostępność jest praktyczna, bo pozwala przypisać wymagania do zabezpieczeń, np. szyfrowanie i kontrola dostępu do poufności, rejestry zmian do integralności oraz BCP/DR do dostępności. Ten podział porządkuje analizę ryzyka, którą później weryfikuje audyt systemu zarządzania bezpieczeństwem informacji.

Jak przeprowadzić analizę ryzyka w systemie zarządzania bezpieczeństwem informacji?

Analiza ryzyka w systemie zarządzania bezpieczeństwem informacji polega na identyfikacji zagrożeń, ocenie podatności oraz określeniu wpływu na organizację. W kontekście KSC analiza ryzyka musi być udokumentowana i powiązana z doborem zabezpieczeń, aby można było wykazać jej adekwatność w audycie.

1. Zidentyfikuj aktywa — systemy, dane, usługi i ich właścicieli.
2. Określ zagrożenia, np. ransomware, awarię infrastruktury lub błąd ludzki.
3. Oceń prawdopodobieństwo wystąpienia i skutki dla usługi.
4. Wyznacz poziom ryzyka na podstawie przyjętej metodyki.
5. Podejmij i udokumentuj decyzję o akceptacji, redukcji lub transferze ryzyka.

Dlaczego system zarządzania bezpieczeństwem informacji jest wymagany w reżimie KSC i NIS2, a nie tylko „zalecany”?

System bezpieczeństwa informacji jest wymagany, ponieważ KSC (w wersji wdrażającej NIS2) opiera nadzór na mierzalnym, audytowalnym zarządzaniu ryzykiem, a nie na jednorazowych kontrolach technicznych. Ustawa zakłada, że organizacja ma potrafić stale identyfikować podatności, zarządzać incydentami i utrzymywać ciągłość działania, a to wymaga procesów i dowodów. Właśnie dlatego system zarządzania bezpieczeństwem informacji jest „kręgosłupem” zgodności, a nie dodatkiem.

Jak SZBI łączy normę ISO 27001 z KSC (NIS2)?

SZBI łączy ISO/IEC 27001 z KSC, bo ISO dostarcza sprawdzony model procesowy (np. cykl PDCA, audyty, przeglądy kierownictwa), a KSC doprecyzowuje obowiązki publicznoprawne i terminy. ISO/IEC 27001 wraz z katalogiem zabezpieczeń ISO/IEC 27002 pomaga zbudować spójność dokumentacji i kontroli, natomiast KSC wymaga dostosowania do obowiązków raportowania, audytu oraz reżimu podmiotów kluczowych i ważnych. Poniższa tabela porządkuje, „co do czego” w praktyce mapuje system zarządzania bezpieczeństwem informacji.

Jakie elementy systemu bezpieczeństwa informacji są wspólne dla ISO 27001 i KSC?

System bezpieczeństwa informacji w obu podejściach opiera się na analizie ryzyka, politykach, kontrolach, szkoleniach, audytach i ciągłym doskonaleniu. Różnice dotyczą przede wszystkim obowiązków zewnętrznych (wpis do wykazu, kanały komunikacji, terminy zgłoszeń) oraz sankcji i trybu nadzoru państwowego.

Kogo dotyczy system zarządzania bezpieczeństwem informacji w świetle KSC?

System zarządzania bezpieczeństwem informacji dotyczy obu kategorii podmiotów — podmiotów ważnych oraz kluczowych — ale różni się „ciężarem” audytu i nadzoru. Podmiot kluczowy ma zwykle bardziej rygorystyczny harmonogram audytowy i większy wpływ incydentów na otoczenie, więc SZBI musi być bardziej dojrzały operacyjnie. Podmiot ważny również musi wdrożyć SZBI, ale nadzór może mieć charakter bardziej reaktywny, co nie zwalnia z utrzymywania gotowości dowodowej.

Jak system zarządzania bezpieczeństwem informacji powinien organizować monitorowanie, SIEM oraz EDR/XDR?

System zarządzania bezpieczeństwem informacji powinien zdefiniować, jakie zdarzenia są logowane, gdzie są przechowywane oraz jak wygląda korelacja i analiza incydentów. Wymogi KSC w praktyce prowadzą do wdrożeń SIEM oraz EDR/XDR i do budowy lub zakupu funkcji SOC, bo bez tego trudno zapewnić wykrywalność i czas reakcji. Taki system musi też opisać ścieżkę eskalacji i kryteria kwalifikacji incydentu do zgłoszenia.

SZBI pomaga spełnić terminy zgłoszeń incydentów, bo wprowadza z góry zaplanowane role, szablony danych, kanały komunikacji i decyzje o klasyfikacji incydentu. Ustawa o KSC wskazuje konkretne okna czasowe: zgłoszenie wczesnego ostrzeżenia o incydencie poważnym w ciągu 24 godzin od wykrycia, zgłoszenie incydentu poważnego niezwłocznie, nie później niż w ciągu 72 godzin, oraz przekazanie sprawozdania końcowego nie później niż w ciągu miesiąca od zgłoszenia. Wymagają one gotowości operacyjnej także poza godzinami pracy.

SZBI a łańcuch dostaw oraz dostawcy wysokiego ryzyka

System zarządzania bezpieczeństwem informacji powinien obejmować łańcuch dostaw, ponieważ ryzyko dostawcy jest często ryzykiem całej organizacji. KSC akcentuje mechanizmy oceny i eliminacji ryzyk w łańcuchu dostaw ICT, w tym scenariusze wymiany technologii i ograniczania vendor lock-in. Podmiot kluczowy i podmiot ważny powinny znać swój łańcuch dostaw wraz z ryzykami, dbać o wymagania cyberbezpieczeństwa w umowach, a w przypadku umów adhezyjnych z globalnymi dostawcami wybierać tych, którzy posiadają certyfikację bezpieczeństwa własnych produktów i usług. Konieczne jest też inwentaryzowanie zasobów i monitorowanie podatności związanych z wykorzystywanym sprzętem i oprogramowaniem.

Jaką odpowiedzialność ponosi kierownictwo za system zarządzania bezpieczeństwem informacji w świetle KSC?

Kierownictwo ponosi odpowiedzialność za to, by system zarządzania bezpieczeństwem informacji był wdrożony, utrzymany i udowadnialny, a nie tylko „przyjęty uchwałą”. Ustawa o KSC precyzuje ten zakres odpowiedzialności wprost i przypisuje go osobiście kierownikowi podmiotu — nawet jeśli część zadań powierzono innym osobom.

• Dokonanie aktualnego wpisu do wykazu podmiotów kluczowych lub podmiotów ważnych.
• Wdrożenie systemu zarządzania bezpieczeństwem informacji w podmiocie.
• Realizację swoich zadań wynikających z ustawy o KSC.
• Weryfikację personelu realizującego zadania z zakresu SZBI i zgłaszania incydentów.
• Przeszkolenie siebie z realizacji obowiązków — raz w roku, obowiązkowo.
• Wyznaczenie osób kontaktowych dla organu i CSIRT.
• Korzystanie z systemu S46.
• Zgłaszanie incydentów w wymaganych oknach czasowych.
• Przeprowadzanie audytów SZBI.

Odpowiedzialność kierownika nie znika, gdy zadania zostaną powierzone zespołowi technicznemu lub dostawcy zewnętrznemu — ustawa wskazuje, że kierownik odpowiada także wtedy, gdy obowiązki wykonuje za jego zgodą inna osoba. To sprawia, że cykliczne raportowanie statusu ryzyka i dowodów SZBI do kierownictwa jest częścią samego systemu, a nie dodatkową formalnością.

Dlaczego kupiona dokumentacja SZBI nie wystarczy? Najczęstsze błędy wdrożenia

Kupiona i podpisana dokumentacja SZBI nie zapewnia zgodności z ustawą o KSC, jeżeli nie jest powiązana z realnie działającymi zabezpieczeniami. Ministerstwo Cyfryzacji formułuje to bezpośrednio w odpowiedzi na pytanie o gotowe wzory dokumentacji: „Unijne i krajowe regulacje wymagają realnego zapewnienia cyberbezpieczeństwa. Organizacja musi być świadoma swoich aktywów, ryzyk, cyberzagrożeń i dopasować adekwatne środki techniczne i organizacyjne ograniczające ryzyko. Organizacja musi mieć wdrożone, przetestowane i stosowane w praktyce procedury zarządzania incydentami. Kupiona dokumentacja, podpisana przez zarząd i schowana w »szafie NIS2« nie zapewni realnego cyberbezpieczeństwa w organizacji.”

W praktyce projektów wdrożeniowych powtarza się kilka błędów, które prowadzą dokładnie do tego scenariusza — dokumentacji, która istnieje, ale nie odzwierciedla stanu faktycznego systemów.

• Kupienie gotowego wzoru polityki bezpieczeństwa bez dostosowania do rzeczywistych systemów, aktywów i procesów organizacji.
• Brak realnej analizy ryzyka — ryzyka są wpisane do dokumentu, ale nie wynikają z inwentaryzacji aktywów ani z faktycznych zagrożeń.
• Procedury zarządzania incydentami, które nigdy nie zostały przetestowane w praktyce ani na scenariuszu ćwiczeniowym.
• Dokumentacja normatywna, która nie ma pokrycia w dokumentacji operacyjnej — brak logów, raportów i rejestrów potwierdzających wykonanie opisanych czynności.
• Konfiguracja techniczna (IAM, MFA, monitoring) rozjeżdżająca się z opisem w polityce, np. po zmianach infrastruktury, które nie zostały odzwierciedlone w dokumentach.
• Brak wskazanego właściciela poszczególnych polityk i procedur, co uniemożliwia wykazanie odpowiedzialności w trakcie kontroli.
• Traktowanie SZBI jako jednorazowego projektu wdrożeniowego, a nie procesu wymagającego cyklicznych przeglądów i aktualizacji.

Rozróżnienie dokumentacji normatywnej i operacyjnej, opisane wcześniej, jest tu kluczowe. Dokument opisujący politykę kontroli dostępu bez logów pokazujących jej stosowanie jest dokładnie tym scenariuszem, przed którym ostrzega ministerstwo. Dlatego Inteca projektuje dokumentację techniczną razem z konfiguracją systemów i mechanizmem generowania dowodów — a nie jako oddzielny dokument dostarczany po fakcie. Warstwa prawna dokumentacji SZBI — jej formalna struktura, polityki normatywne w rozumieniu regulacyjnym oraz kwalifikacja podmiotu — pozostaje zadaniem kancelarii.

Jak przygotować audyt systemu zarządzania bezpieczeństwem informacji?

Audyt systemu zarządzania bezpieczeństwem informacji jest łatwiejszy, gdy od początku buduje się repozytorium dowodów: rejestr ryzyk, rejestr incydentów, wyniki testów BCP, logi, rejestry zmian i wyniki przeglądów kierownictwa. Organ właściwy do spraw cyberbezpieczeństwa nie ocenia samej dokumentacji — Ministerstwo wskazuje wprost:

„Organ właściwy do spraw cyberbezpieczeństwa może prosić podmiot kluczowy lub podmiot ważny o przedstawienie dowodów realizacji systemu zarządzania bezpieczeństwem informacji. Mogą być dokumenty np. procedury, polityki, upoważnienia, zakresy obowiązków, ale również relacje personelu. Wymagane jest udowodnienie stosowania przepisów ustawy, a nie przedstawienie formalnie poprawnych dokumentów.”

W praktyce oznacza to, że „papier compliance” zwykle nie przechodzi testu audytu KSC.

Jak przygotować system zarządzania bezpieczeństwem informacji do audytu KSC?

Przygotowanie systemu zarządzania bezpieczeństwem informacji do audytu KSC polega na zgromadzeniu dowodów potwierdzających skuteczność wdrożonych procesów i zabezpieczeń — nie tylko na skompletowaniu dokumentów. Audytor lub organ mogą oczekiwać rozmowy z personelem odpowiedzialnym za dany obszar, pokazania konfiguracji na żywo lub przeprowadzenia scenariusza testowego, a nie wyłącznie odczytania procedury z pliku PDF.

• Aktualny rejestr ryzyk i decyzji zarządczych.
• Rejestr incydentów i udokumentowany sposób ich obsługi.
• Wyniki testów ciągłości działania (BCP/DR).
• Logi i dane z systemów monitorowania (SIEM, EDR/XDR).
• Rejestr aktywów oraz dowody zwrotu aktywów po zakończeniu współpracy.
• Rejestr uprawnień i logi kontroli dostępu, w tym dla kont uprzywilejowanych.
• Potwierdzenia szkoleń personelu oraz szkolenia kierownika podmiotu.
• Dokumentacja przeglądów kierownictwa i wynikających z nich decyzji.

Audyt KSC weryfikuje nie tylko dokumentację, ale przede wszystkim realne działanie systemu zarządzania bezpieczeństwem informacji i jego zdolność do reagowania na incydenty. Inteca projektuje ten zestaw dowodów już na etapie wdrożenia technicznego — logi, raporty z testów i konfiguracje są częścią architektury od pierwszego dnia, a nie dokumentem tworzonym retrospektywnie przed kontrolą.

Jak system zarządzania bezpieczeństwem informacji łączy KSC z RODO i KRI bez dublowania dokumentacji?

System zarządzania bezpieczeństwem informacji może łączyć KSC, RODO i KRI, jeśli opisuje wspólny model ryzyka, wspólne role oraz jednolitą politykę bezpieczeństwa informacji. W praktyce jedna metodyka analizy ryzyka i jedna procedura obsługi incydentów pozwala spełniać różne obowiązki raportowe i dowodowe, o ile zakresy są poprawnie rozdzielone. To podejście zmniejsza koszt utrzymania systemu zarządzania bezpieczeństwem informacji i ułatwia audyty.

Kiedy narzędzia klasy GRC są uzasadnione jako element systemu bezpieczeństwa informacji?

Narzędzia klasy GRC są uzasadnione, gdy system zarządzania bezpieczeństwem informacji obejmuje wiele procesów, dostawców i jednostek organizacyjnych, a ręczna kontrola dowodów staje się niewydolna. GRC pozwala powiązać ryzyka z kontrolami, przypisać właścicieli oraz automatyzować przypomnienia i raporty dla kierownictwa. W kontekście KSC to także sposób na szybsze przygotowanie pakietu dowodów na audyt.

Jak zaplanować wdrożenie systemu zarządzania bezpieczeństwem informacji w horyzoncie KSC (2026–2028)?

Wdrożenie SZBI warto podzielić na etapy: samoidentyfikacja i zakres, analiza luki, wdrożenie procesów, wdrożenie zabezpieczeń, testy i przygotowanie audytu. Dla organizacji z istniejącą praktyką ISO/IEC 27001 priorytetem jest domknięcie wymogów KSC: raportowanie incydentów, łańcuch dostaw i dowody nadzoru kierownictwa. Ostatnim krokiem jest stabilizacja, czyli cykliczne przeglądy i ciągłe doskonalenie.

Jak wdrożyć system zarządzania bezpieczeństwem informacji krok po kroku?

System zarządzania bezpieczeństwem informacji wdraża się etapowo, aby zapewnić zgodność z KSC i skuteczność operacyjną.

1. Zdefiniuj zakres SZBI oraz kluczowe usługi i systemy informacyjne.
2. Zidentyfikuj aktywa, właścicieli oraz procesy biznesowe.
3. Przeprowadź analizę ryzyka cyberbezpieczeństwa.
4. Dobierz i wdróż zabezpieczenia zgodne z ISO 27001 i wymaganiami KSC: kontrolę dostępu, monitoring, kryptografię, ochronę łańcucha dostaw.
5. Uruchom procesy operacyjne — monitoring, obsługę incydentów, raportowanie do CSIRT.
6. Przetestuj scenariusze incydentów oraz ciągłości działania (BCP/DR).
7. Przeszkól personel i kierownika podmiotu z obowiązków SZBI.
8. Zbierz dowody wdrożenia i przygotuj się do audytu.

Taki model wdrożenia pozwala osiągnąć zgodność regulacyjną oraz realną zdolność reagowania na incydenty — a nie tylko dokumentację, która czeka na kontrolę.

 

Źródła: