Wróć do bloga
KSC i NIS2

SZBI według ustawy KSC – co trzeba wdrożyć?

Publikacja: 2026-07-276 minKrzysztof Jaroński

System zarządzania bezpieczeństwem informacji (SZBI) według ustawy o KSC to spójny zestaw polityk, procesów, ról i kontroli technicznych, który pozwala identyfikować ryzyka, chronić aktywa, utrzymywać ciągłość działania, reagować na incydenty (w tym poważne — 24 h / 72 h) i wykazywać dowody przed audytorem. Sam zakup SIEM nie spełnia wymogu SZBI — monitoring jest jednym z wielu elementów.

Stan prawny sprawdzony: 27 lipca 2026 r. Materiał informacyjny, nie porada prawna. Obowiązki wdraża się do 3.04.2027 (grupa początkowa); audyt podmiotu kluczowego co 3 lata (pierwszy do 3.04.2028 dla wcześniej niebędących OUK).

Spis treści

Czym jest SZBI w KSC

SZBI to nie jeden dokument PDF, lecz działający system: zarząd zatwierdza kierunek, kierownik ds. bezpieczeństwa informacji nadzoruje wdrożenie (odpowiedzialność nie znika przy delegacji), zespoły operacyjne wykonują kontrole, a dokumentacja opisuje jak naprawdę pracujecie. Ustawa wiąże SZBI z analizą ryzyka, ochroną sieci i systemów, zarządzaniem incydentami, wymaganiami wobec dostawców, ciągłością działania i — u podmiotu kluczowego — cyklicznym audytem.

Kontekst regulacyjny: Krajowy System Cyberbezpieczeństwa, podmiot kluczowy a ważny, wpis do Wykazu. Wdrożenie merytoryczne uzupełnia oferta cyberbezpieczeństwa NIS2 — bez obietnicy „pełnej zgodności w tydzień”.

Obszary SZBI — tabela mechanizmów i dowodów

ObszarPrzykładowy mechanizmPrzykładowy dowód
Zarządzanie i governancePolityka bezpieczeństwa, role RACI, przegląd zarządu kwartalnyProtokół zarządu, polityka z datą akceptacji
Analiza ryzykaRejestr ryzyk, macierz wpływ × prawdopodobieństwo, plan traktowaniaRejestr ryzyk z właścicielami i terminami
Aktywa i klasyfikacjaInwentaryzacja systemów, właściciele biznesowi, klasy danychCMDB / rejestr aktywów z właścicielami
Kontrola dostępuMFA na kontach uprzywilejowanych, JIT, offboarding w 24 hRaport z przeglądu dostępów, logi IAM
Bezpieczeństwo techniczneHardening, patch management, segmentacjaRaport skanera podatności, change records
Monitoring i wykrywanieLogi centralne, alerty, korelacja — uzupełnienie procesuPrzykładowe tickety SOC, retencja logów
IncydentyPlaybook 24 h / 72 h / miesiąc, S46Zgłoszenia w S46, retrospektywy
Ciągłość działaniaBCP/DR, test odtwarzaniaProtokół testu restore, RTO/RPO
DostawcyWymagania w umowach, ocena ryzyka dostawcyAneksy umowne, kwestionariusze
ŚwiadomośćSzkolenie roczne pracowników i kierownikaListy obecności, e-learning
Audyt wewnętrznyPlan audytu, lista niezgodnościRaport audytu wewnętrznego, CAPA

Tabela ilustruje praktykę — audytor będzie szukał spójności między kolumnami, nie samego existence polityki.

Kierownik, szkolenia, art. 8f

Ustawa wymaga wyznaczenia kierownika ds. bezpieczeństwa informacji. Może to być pracownik lub osoba z zewnątrz, ale delegowanie operacji na IT nie zwalnia kierownika z odpowiedzialności — kierownik nadzoruje SKBI, raportuje zarządowi i uczestniczy w incydentach poważnych.

Kierownik odbywa szkolenie co najmniej raz w roku — z udokumentowanym udziałem (certyfikat, lista obecności, program szkolenia). Przy powołaniu stosuje się weryfikację niekaralności (art. 8f) z wyjątkami przewidzianymi w ustawie — procedurę HR i prawną warto ustalić przed nominacją.

Bez kierownika SZBI jest „bez właściciela” — typowa niezgodność na audytie podmiotu kluczowego.

Ryzyko, aktywa, dostawcy

Analiza ryzyka to serce SZBI: identyfikujesz zagrożenia dla usług sektorowych (niedostępność, wyciek, manipulacja), oceniasz wpływ na odbiorców usług i wybierasz traktowanie (mitigacja, transfer, akceptacja z uzasadnieniem). Rejestr aktualizujesz po incydencie, zmianie architektury lub nowym dostawcy.

Aktywa muszą mieć właścicieli biznesowych — nie tylko „serwer leży w racku”. Bez inwentaryzacji nie wiesz, co chronić i co raportować w S46.

Dostawcy krytyczni (hosting, MSP, chmura, płatności) powinni mieć wymagania cyber w umowie: czas reakcji, zgłaszanie incydentów, dostęp zdalny, audytowalność. SZBI w KSC to nie tylko wewnętrzne IT — to łańcuch dostaw, co spójne z NIS2.

Ciągłość działania i incydenty

Ciągłość działania (BCP/DR) musi być przetestowana — backup bez restore to dekoracja. Ustal RTO/RPO dla usług wskazanych w analizie ryzyka i co najmniej raz rocznie wykonaj test odtwarzania z protokołem.

Zarządzanie incydentami łączy się z incydentem poważnym: definicja art. 2 pkt 7 (wpływ, nie progi liczbowe), 24 h wczesne ostrzeżenie, 72 h zgłoszenie, sprawozdanie końcowe do miesiąca. Playbook musi być zszyty z SZBI — po incydencie aktualizujesz ryzyko i kontrole.

Monitoring — dlaczego SIEM to za mało

SIEM, SOC czy EDR pomagają wykrywać zdarzenia, ale ustawa wymaga systemu zarządzania, nie licencji na narzędzie. Sam SIEM bez:

  • właścicieli alertów i SLA reakcji,
  • procedury kwalifikacji incydentu poważnego,
  • integracji z S46,
  • analizy ryzyka i akceptacji resztkowego,
  • szkoleń i testów ciągłości,

…nie dowodzi SZBI. Audytor zapyta: kto decyduje o powadze, kiedy eskalujesz do kierownika, jak zapisujesz decyzję. Kupno platformy bez odpowiedzi na te pytania to częsty błąd po RFP „pod KSC”.

DevSentinel nie twierdzi, że SIEM = zgodność — pomaga zaprojektować proces i dowody obok technologii.

Plan wdrożenia na 90 dni

Orientacyjny plan dla podmiotu, który wpisuje się do Wykazu w 2026 i musi domknąć obowiązki do 3.04.2027:

Dni 1–30 — fundament

  • Potwierdź kwalifikację (czy firma podlega KSC) i kategorię kluczowy/ważny.
  • Wyznacz kierownika (art. 8f, szkolenie w planie).
  • Złóż / zaplanuj wpis do Wykazu (S46).
  • Inwentaryzacja aktywów i usług krytycznych.
  • Szkic polityki bezpieczeństwa i rejestru ryzyk.

Dni 31–60 — kontrole

  • MFA i przegląd kont uprzywilejowanych.
  • Patch / podatności na ekspozycji zewnętrznej.
  • Backup + test restore krytycznego systemu.
  • Playbook incydentu (24/72/miesiąc) + duty roster.
  • Wymagania cyber u 2–3 krytycznych dostawców.

Dni 61–90 — dowody i rytm

  • Pierwsza wersja pełnego rejestru ryzyk i planu traktowania.
  • Ćwiczenie tabletop incydentu poważnego.
  • Przegląd zarządu: akceptacja polityki, ryzyka resztkowego.
  • Ustalenie planu audytu (podmiot kluczowy — pierwszy do 3.04.2028).
  • Luki techniczne — opcjonalnie audyt bezpieczeństwa IT jako input do rejestru ryzyk.

Po 90 dniach SZBI nie jest „zakończony” — wchodzi rytm utrzymania: kwartalny przegląd ryzyk, roczne szkolenie kierownika, coroczny test DR, audyt wewnętrzny przed audytem ustawowym.

Dla podmiotu kluczowego sensowne jest też zmapowanie wymagań SZBI na konkretne KPI operacyjne: odsetek systemów objętych MFA, czas zamknięcia krytycznej podatności, odsetek dostawców z aneksem cyber, czas od alertu do triage. KPI nie zastępują ustawy, ale ułatwiają zarządowi widzieć, czy SZBI żyje między audytami.

FAQ

Czy ISO 27001 zastępuje SZBI w KSC?

Certyfikacja ISO może przyspieszyć pracę, ale audyt KSC weryfikuje zgodność z ustawą i S46 — mapowanie normy na wymogi ustawowe trzeba utrzymywać i aktualizować.

Czy mała spółka w grupie musi mieć pełny SZBI?

Jeśli podlega ustawie — tak, w zakresie odpowiadającym skali i ryzyku, bez kopiowania tomów z korporacji matki 1:1. Spójność z grupą tak, teatr dokumentów nie.

Czy outsourcing całego IT zwalnia z SZBI?

Nie — podmiot regulowany odpowiada za nadzór nad dostawcą i za zgłoszenia w S46.

Czy DevSentinel gwarantuje zgodność z KSC?

Nie. Wspieramy wdrożenie praktyczne; gwarancji wyniku audytu lub decyzji organu nie składamy.

Kiedy pierwszy audyt ustawowy?

Podmiot kluczowy wcześniej niebędący OUK — do 3.04.2028; dotychczasowi OUK — cykl 3-letni. Podmiot ważny — audyt na nakaz organu.

Chcesz uporządkować SZBI i dowody przed audytem? Wejdź na cyberbezpieczeństwo i NIS2.

Oficjalne źródła

Powiązane materiały