Zgodny SZBI to nie segregator dokumentów i nie pojedyncza aplikacja. To system, w którym role, procesy, dane i dowody są ze sobą powiązane. Poniżej pokazujemy model referencyjny, który powinien być podstawą każdego wdrożenia i każdej aplikacji wspierającej SZBI. Bez nazw producentów i bez konkretnych narzędzi.

1. Co znaczy „zgodny SZBI”

Zgodność z NIS2 (Dz.Urz. UE L 333 z 27.12.2022) i KSC (Dz.U. 2026 poz. 20 (t.j.) i poz. 252) oznacza, że organizacja potrafi odpowiedzieć na trzy pytania:

  • Co chronimy: jakie usługi, procesy, systemy i dane są krytyczne.
  • Jak zarządzamy ryzykiem: jakie zagrożenia występują, jak je oceniamy i co z nimi robimy.
  • Jak to udowadniamy: jakie dokumenty, logi, rejestry i decyzje pokażemy audytorowi.

System musi być kompletny, ale nie musi być skomplikowany. W pełnym modelu z art. 8 ustawy o KSC wymagane jest systematyczne szacowanie ryzyka. Podmioty ważne będące podmiotami publicznymi mogą stosować uproszczony model z załącznika nr 4, który zawiera 18 wymagań obowiązkowych.

2. Model referencyjny: pięć warstw

Dobry SZBI ma pięć warstw. Każda z nich musi mieć właściciela, proces przeglądu i dowód działania.

Model referencyjny SZBI: governance, procesy, dane, technologia i dowody
Model referencyjny SZBI. Warstwy muszą być spójne, a nie tylko równolegle udokumentowane.
  • Governance: właściciel SZBI, zarząd, polityka, decyzje o ryzyku i przegląd zarządzania.
  • Procesy: ryzyko, incydenty, ciągłość, dostawcy, audyt i szkolenia.
  • Dane: aktywa, rejestr ryzyk, dokumenty, dowody i powiązania między nimi.
  • Technologia: tożsamość i dostęp, backup, monitoring, S46 i aplikacja wspierająca.
  • Dowody: logi, raporty, protokoły, potwierdzenia szkoleń i przeglądy.

3. Dwanaście modułów funkcjonalnych

Moduły nie są listą zakupową. To funkcje, które muszą działać razem. Jeżeli jeden moduł jest tylko dokumentem, system będzie miał lukę.

Dwanaście modułów funkcjonalnych SZBI
Dwanaście modułów SZBI. Wspólny model danych jest ważniejszy niż liczba ekranów w aplikacji.

3.1. Governance i role

System potrzebuje właściciela, sponsora w zarządzie i właścicieli aktywów oraz ryzyk. Governance obejmuje politykę, macierz RACI, rejestr decyzji i przegląd zarządzania. Dowodem są zatwierdzenia, protokoły i decyzje o akceptacji ryzyka.

3.2. Zakres i kontekst

Trzeba opisać usługi, procesy, lokalizacje, interesariuszy i granice systemu. Zakres nie może być listą serwerów. Ma wynikać z procesów, które wpływają na świadczenie usługi. Dowodem jest mapa procesów i opis wyłączeń.

3.3. Aktywa i usługi

Rejestr aktywów obejmuje systemy, aplikacje, usługi chmurowe, urządzenia, dane, integracje i procesy. Dla każdego elementu potrzebny jest właściciel, krytyczność, dostawca, wersja, lokalizacja i cykl życia. Rejestr jest punktem wyjścia do ryzyka, backupu i testów.

3.4. Ryzyko

Moduł ryzyka zawiera metodykę, rejestr ryzyk, ocenę prawdopodobieństwa i wpływu, plan postępowania, właścicieli, terminy i ryzyko rezydualne. Ryzyko trzeba przeglądać, a nie wpisywać raz do tabeli. Dobra aplikacja pokazuje powiązanie ryzyka z aktywem, kontrolą i dowodem.

3.5. Dokumentacja

Polityki, procedury i instrukcje muszą mieć właściciela, wersję, datę zatwierdzenia i termin przeglądu. Dokumentacja powinna być spójna. Audytor sprawdza, czy procedura opisuje rzeczywisty proces, a nie idealny świat.

3.6. Kontrole i działania

Każde ryzyko powinno mieć przypisaną kontrolę lub działanie. Moduł kontroli obejmuje plan wdrożenia, status, dowód działania i ocenę skuteczności. Bez dowodów kontrola jest tylko deklaracją.

3.7. Dostęp i tożsamość

System musi obsługiwać role, zasadę minimalnych uprawnień, MFA, proces joiner, mover, leaver, przeglądy uprawnień i konta uprzywilejowane. To jeden z najczęstszych obszarów luk w audycie.

3.8. Dostawcy i łańcuch dostaw

Rejestr dostawców obejmuje usługę, zakres dostępu, krytyczność, podwykonawców, umowę i plan wyjścia. Dla dostawców krytycznych potrzebna jest ocena due diligence, klauzule bezpieczeństwa i dowody przeglądów.

3.9. Ciągłość i backup

Moduł obejmuje BIA, RTO, RPO, plany ciągłości, plany awaryjne, kopie zapasowe i testy odtworzenia. Backup bez testu jest wiarą, nie kontrolą. Dowodem jest protokół odtworzenia i zmierzony czas.

3.10. Incydenty

System musi klasyfikować incydenty, prowadzić rejestr, pilnować terminów 24 i 72 godzin oraz miesiąca na sprawozdanie końcowe, a także wspierać przygotowanie zgłoszenia do S46. Nie zastępuje S46. Ma dostarczyć dane, dowody i historię decyzji.

3.11. Szkolenia i świadomość

Moduł obejmuje program szkoleń, szkolenie kierownika, szkolenia pracowników, rejestr uczestników, quizy i pomiar skuteczności. Szkolenie bez rejestru jest trudne do obrony w audycie.

3.12. Audyt, metryki i przegląd zarządzania

System powinien zbierać ustalenia, niezgodności, działania korygujące, wskaźniki i raport dla zarządu. Audyt wewnętrzny ma przygotować do audytu obowiązkowego, a przegląd zarządzania ma zamknąć cykl decyzji.

4. Model danych: jedna prawda, wiele wymagań

Najważniejsza decyzja architektoniczna to model danych. Aktywo, ryzyko, kontrola, dokument, dowód, incydent, dostawca i audyt nie mogą być osobnymi silosami. Jedno zdarzenie powinno obsługiwać wiele wymagań: NIS2, RODO, DORA (Dz.Urz. UE L 333 z 27.12.2022; ustawa Dz.U. 2025 poz. 1069), ISO 27001 i załącznik nr 4.

Model danych SZBI: organizacja, procesy, aktywa, ryzyka, kontrole, dowody, incydenty, dostawcy i audyt
Model danych SZBI. Wspólne encje i relacje pozwalają uniknąć duplikacji dowodów.

Przykład: rejestr aktywów może być dowodem dla NIS2, RODO (Dz.Urz. UE L 119 z 4.5.2016; ustawa Dz.U. 2018 poz. 1000), DORA i CRA (Dz.Urz. UE L 2024/2847). Rejestr ryzyk może obsługiwać SZBI i DPIA. Rejestr dostawców może obsługiwać NIS2, RODO i DORA. Aplikacja, która nie potrafi pokazać tych powiązań, zmusza użytkownika do pracy w kilku arkuszach.

5. Przepływy, które muszą działać

Interfejs może być prosty, ale przepływy muszą być kompletne. Najważniejsze z nich to:

  • Cykl ryzyka: identyfikacja, ocena, postępowanie, monitorowanie, przegląd.
  • Cykl dokumentu: projekt, akceptacja, publikacja, przegląd, wycofanie.
  • Cykl dostawcy: rejestracja, ocena, umowa, przegląd, exit.
  • Cykl audytu: plan, dowody, ustalenia, działania korygujące, weryfikacja.
  • Cykl incydentu: wykrycie, klasyfikacja, zgłoszenie, ograniczanie, analiza przyczyn, działania.
Przepływ incydentu poważnego: wykrycie, 24 godziny, 72 godziny, miesiąc, S46 i CSIRT
Przepływ incydentu poważnego. Zgłoszenie nie kończy incydentu. Po sprawozdaniu trzeba zaktualizować ryzyka i kontrole.

6. Mapa wymagań

Poniższa tabela pokazuje, jak moduły przekładają się na wymagania. To nie jest dosłowne brzmienie przepisów, ale mapa wdrożeniowa.

Wymaganie Moduł Dowód
Zarządzanie ryzykiem Ryzyko Rejestr ryzyk, plan postępowania, akceptacje
Polityka bezpieczeństwa Dokumentacja, governance Polityka z zatwierdzeniem i przeglądem
Inwentaryzacja aktywów Aktywa i usługi Rejestr aktywów z właścicielami
Kontrola dostępu Dostęp i tożsamość Macierz ról, przeglądy, logi MFA
Bezpieczeństwo łańcucha dostaw Dostawcy Rejestr, oceny, umowy, klauzule
Ciągłość działania Ciągłość i backup BIA, plany, testy odtworzenia
Zarządzanie incydentami Incydenty Procedura, rejestr, zgłoszenia S46
Szkolenia i cyberhigiena Szkolenia Program, rejestr, quizy
Audyt i przegląd Audyt i metryki Raport, findings, CAPA, przegląd zarządzania
Załącznik nr 4 Wszystkie moduły 18 wymagań, dowody, przegląd

7. Czego aplikacja SZBI nie powinna robić

  • Nie zastępuje systemu S46. Może przygotować zgłoszenie, ale nie jest oficjalnym kanałem.
  • Nie certyfikuje zgodności. Może wspierać audyt, ale nie wydaje certyfikatu.
  • Nie powinna być wyłącznie archiwum dokumentów. Dokument bez procesu i dowodu nie działa.
  • Nie powinna zmuszać do trzymania danych wrażliwych w arkuszu bez kontroli dostępu.
  • Nie powinna ukrywać logiki oceny ryzyka. Użytkownik musi rozumieć, dlaczego wynik jest taki, a nie inny.
  • Nie powinna być systemem ticketowym bez powiązania z aktywami, ryzykiem i dowodami.

8. Poziomy dojrzałości

  1. Poziom 1: dokumenty istnieją, ale nie są używane.
  2. Poziom 2: procesy są opisane i wykonywane częściowo.
  3. Poziom 3: procesy są powtarzalne, mają właścicieli i dowody.
  4. Poziom 4: system jest mierzony, a ryzyka i kontrole są przeglądane.
  5. Poziom 5: organizacja doskonali system na podstawie danych i testów.

Celem nie jest poziom 5 w pierwszym miesiącu. Celem jest poziom 3, czyli powtarzalność i dowody, a potem stopniowe doskonalenie.

9. Kolejność wdrożenia w 90 dni

Plan wdrożenia SZBI w 90 dni: sześć etapów
Plan 90 dni. Najpierw zakres i aktywa, potem ryzyko, dokumenty, kontrole, szkolenia i przegląd.

Kolejność jest ważna. Jeżeli organizacja zaczyna od kupna narzędzia, zwykle kupuje interfejs do nieuporządkowanych danych. Najpierw trzeba ustalić zakres, aktywa i ryzyko, a dopiero potem wybierać technologię.

10. Checklista: 20 pytań do oceny aplikacji SZBI

  1. Czy aplikacja pokazuje powiązanie aktywa z ryzykiem i kontrolą?
  2. Czy rejestr aktywów ma właścicieli i krytyczność?
  3. Czy ryzyko ma właściciela, termin i ryzyko rezydualne?
  4. Czy dokument ma wersję, akceptację i termin przeglądu?
  5. Czy kontrola ma dowód działania?
  6. Czy aplikacja obsługuje role i zasadę minimalnych uprawnień?
  7. Czy rejestr dostawców obejmuje podwykonawców i exit plan?
  8. Czy aplikacja pilnuje terminów 24 i 72 godzin?
  9. Czy można wygenerować szkic zgłoszenia do S46?
  10. Czy aplikacja jasno mówi, że nie zastępuje S46?
  11. Czy obsługuje załącznik nr 4 dla podmiotów publicznych?
  12. Czy pokazuje luki i plan działania?
  13. Czy ma rejestr szkoleń i potwierdzenia?
  14. Czy zbiera ustalenia z audytu i działania korygujące?
  15. Czy pokazuje raport dla zarządu?
  16. Czy można eksportować dane i dowody?
  17. Czy dane są izolowane między organizacjami?
  18. Czy aplikacja wspiera RODO, DORA lub ISO 27001 bez duplikacji?
  19. Czy logika oceny ryzyka jest opisana i zrozumiała?
  20. Czy wiadomo, gdzie są dane i kto ma do nich dostęp?

11. Wniosek

Zgodny SZBI to system decyzji i dowodów, a nie kolekcja dokumentów. Aplikacja może go wspierać tylko wtedy, gdy rozumie model danych, przepływy i wymagania prawne. Dlatego przed budową aplikacji publikujemy ten model i pokazujemy, jakie elementy muszą ze sobą współgrać.

Jeżeli chcesz sprawdzić, jak Twój obecny system wygląda na tle tego modelu, przejdź do wymagań SZBI i audytu SZBI. Praktyczny plan znajdziesz w wdrożeniu SZBI w 10 krokach.