SZBI — System Zarządzania Bezpieczeństwem Informacji. Dokumentacja, wdrożenie i audyt

SZBI to skrót, który spotyka każda osoba zajmująca się bezpieczeństwem informacji w polskiej organizacji — i jednocześnie jeden z najczęściej źle rozumianych terminów w branży. SZBI to nie folder w sieci ani komplet dokumentów do oddania kontrolerowi. To żywy system zarządzania, który łączy ludzi, procesy i technologie w spójną całość chroniącą informacje organizacji. Ten przewodnik krok po kroku wyjaśnia, czym jest SZBI, co powinna zawierać dokumentacja SZBI z przykładami oraz jak wygląda wdrożenie i audyt tego systemu w firmie, szpitalu lub urzędzie.

Czym jest SZBI i co oznacza skrót w kontekście KRI i ISO 27001

SZBI co to dokładnie? Skrót oznacza System Zarządzania Bezpieczeństwem Informacji. W terminologii międzynarodowej odpowiada mu pojęcie ISMS — Information Security Management System. SZBI to systemowe podejście do ochrony informacji, oparte na cyklu Plan-Do-Check-Act (planuj, wykonuj, sprawdzaj, działaj), które ma zapewnić, że poufność, integralność i dostępność informacji są utrzymywane na poziomie adekwatnym do ryzyka i wymagań prawnych.

Co oznacza skrót SZBI w kontekście KRI? W polskim prawie pojęcie SZBI pojawia się przede wszystkim w rozporządzeniu w sprawie Krajowych Ram Interoperacyjności, które w paragrafie 20 nakłada na podmioty realizujące zadania publiczne obowiązek wdrożenia, eksploatacji i okresowego audytu Systemu Zarządzania Bezpieczeństwem Informacji. Wymagania KRI w zakresie SZBI są w znacznej mierze inspirowane normą ISO/IEC 27001 — można powiedzieć, że KRI to “polska, obowiązkowa wersja” wymagań tej normy, dostosowana do realiów administracji publicznej.

Relacja SZBI ISO 27001 jest dość prosta: ISO/IEC 27001:2022 to międzynarodowa norma opisująca, jak zaprojektować, wdrożyć, utrzymywać i doskonalić ISMS (czyli właśnie SZBI). Norma jest dobrowolna — ale jeśli organizacja wdroży SZBI zgodnie z ISO 27001 i przejdzie audyt certyfikacyjny, otrzymuje certyfikat, który jest uznawany na całym świecie. Wiele polskich firm wdraża SZBI nie ze względu na obowiązek prawny, ale ze względu na wymagania kontraktowe (duże przedsiębiorstwa wymagają certyfikatu od swoich dostawców), wymagania rynku finansowego, wymogi sektorowe albo dla redukcji ryzyka cyber.

Trzeba jednak pamiętać o zasadniczej różnicy. SZBI w rozumieniu KRI musi być wdrożony — ale niekoniecznie certyfikowany. Wystarczy, że spełnia wymagania rozporządzenia i jest co roku audytowany wewnętrznie. SZBI w rozumieniu ISO 27001 może być certyfikowany przez akredytowaną jednostkę certyfikującą i wtedy organizacja otrzymuje formalne potwierdzenie zgodności. Wiele JST wdraża SZBI w wariancie KRI (obowiązkowy) i dodatkowo certyfikuje się na ISO 27001, kiedy chcą udowodnić swoją dojrzałość partnerom zewnętrznym albo zmierzyć się z zewnętrznymi audytami w sposób ustrukturyzowany.

Niezależnie od wariantu, SZBI opiera się na trzech filarach: dokumentacji (zapisane polityki, procedury, instrukcje), procesach (faktyczne działania w organizacji — nadawanie dostępów, zarządzanie incydentami, szkolenia) oraz mechanizmach kontrolnych (audyty, przeglądy zarządzania, KPI bezpieczeństwa). System bez któregoś z tych filarów nie jest SZBI — to tylko jego pozór.

Dokumentacja SZBI — co musi zawierać i przykłady

Dokumentacja SZBI to często pierwszy element, na który patrzą audytorzy — zarówno wewnętrzni, jak i zewnętrzni. Wbrew obiegowej opinii, dokumentacja SZBI nie musi być gruba — musi być adekwatna, aktualna i stosowana. Lepszy jest komplet 12 spójnych dokumentów, które ludzie znają i z których korzystają, niż 80 plików leżących w archiwum, których nikt nie otwierał od trzech lat.

Standardowy zestaw dokumentacji SZBI obejmuje następujące pozycje:

Polityka Bezpieczeństwa Informacji — dokument najwyższego poziomu, zatwierdzony przez kierownika organizacji (zarząd, wójta, dyrektora), który deklaruje cele, zasady i odpowiedzialności w zakresie bezpieczeństwa informacji. To “konstytucja” SZBI. Dobry przykład polityki ma 4-8 stron, jest napisany językiem zrozumiałym dla zwykłego pracownika i odwołuje się do polityk szczegółowych.

Polityki szczegółowe — komplet dokumentów regulujących konkretne obszary: polityka kontroli dostępu, polityka kryptograficzna, polityka kopii zapasowych, polityka korzystania z urządzeń mobilnych, polityka dotycząca nośników wymiennych, polityka czystego biurka i czystego ekranu, polityka bezpiecznego korzystania z poczty elektronicznej i internetu. Każda polityka szczegółowa powinna mieć wskazanego właściciela i datę przeglądu.

Procedury operacyjne — opis tego, jak konkretnie wykonywane są określone czynności. Procedura zarządzania dostępem (kto wnioskuje, kto akceptuje, kto nadaje, kto weryfikuje, kto odbiera). Procedura zarządzania incydentami (jak zgłosić, kto reaguje, jak dokumentować). Procedura zarządzania zmianą w systemach informatycznych. Procedura zarządzania kopiami zapasowymi. Procedura postępowania z nośnikami wymiennymi.

Inwentaryzacja aktywów — rejestr aktywów informacyjnych, czyli wszystkiego, co ma wartość informacyjną dla organizacji: sprzęt, oprogramowanie, dane, usługi, dokumenty, ludzie. Każdy aktyw ma właściciela, klasyfikację (poufność/integralność/dostępność) i powiązanie z procesem biznesowym.

Analiza ryzyka — metodyka i raport z analizy ryzyka. Identyfikacja zagrożeń i podatności, ocena prawdopodobieństwa i skutku, decyzje o postępowaniu (akceptacja, redukcja, transfer, unikanie). Plan postępowania z ryzykiem.

Plan ciągłości działania (BCP) i plan przywrócenia po awarii (DRP) — co robimy, kiedy systemy padną. Czasy RTO i RPO, scenariusze awaryjne, lista zasobów krytycznych, plan komunikacji kryzysowej.

Rejestry operacyjne — rejestr incydentów, rejestr szkoleń, rejestr przeglądów uprawnień, rejestr testów kopii zapasowych, rejestr przeglądów dokumentacji.

Plan szkoleń i materiały szkoleniowe — kto, kiedy i z czego jest szkolony. Materiały, prezentacje, testy sprawdzające.

Oświadczenie stosowalności (SoA — Statement of Applicability) — dokument wymagany przez ISO 27001, ale przydatny w każdym SZBI. Lista wszystkich zabezpieczeń z Załącznika A normy z informacją, czy są stosowane (i dlaczego), czy nie (i dlaczego nie).

Jako szbi przykład wyobraźmy sobie 50-osobową firmę usługową. Jej dokumentacja SZBI to: polityka główna (5 stron), 7 polityk szczegółowych (po 2-4 strony), 12 procedur operacyjnych, rejestr aktywów w arkuszu kalkulacyjnym (kilkadziesiąt pozycji), analiza ryzyka (raport ~20 stron + arkusz z rejestrem ryzyk), plany BCP/DRP, kilka rejestrów. Łącznie to ok. 150-200 stron — czytelnych, używanych, aktualizowanych co najmniej raz w roku.

W szbi dokumentacja powinna być utrzymywana w wersjonowanym repozytorium, z jasnym oznaczeniem statusu (projekt, zatwierdzony, wycofany), z historią zmian i z dostępem dla osób, które jej potrzebują (nie szerzej, nie węziej).

Wdrożenie i audyt SZBI — etapy projektu

Wdrożenie SZBI to projekt, który zwykle trwa od 4 do 12 miesięcy w zależności od wielkości organizacji, dojrzałości wyjściowej i wybranego wariantu (KRI, ISO 27001, oba). Mówimy tu o projekcie wdrożenia od podstaw — w organizacjach, które już mają jakiś poziom dokumentacji, projekt może być znacznie krótszy.

Faza 1: Inicjacja i analiza wstępna (ok. 4-6 tygodni). Powołanie zespołu projektowego, wybór sponsora projektu na poziomie zarządczym, analiza luki (gap analysis) — czyli co już mamy, czego nam brakuje względem wymagań KRI/ISO 27001. Definicja zakresu SZBI: czy obejmuje całą organizację, czy konkretną jednostkę biznesową lub lokalizację.

Faza 2: Inwentaryzacja i analiza ryzyka (ok. 4-8 tygodni). Spisanie aktywów informacyjnych, ich klasyfikacja, identyfikacja zagrożeń i podatności, ocena ryzyka, decyzje o postępowaniu. To etap, który najczęściej rozciąga się w czasie, bo wymaga współpracy wielu osób z różnych działów.

Faza 3: Opracowanie dokumentacji (ok. 6-10 tygodni). Tworzenie polityk, procedur, planów. Konsultacje z właścicielami procesów. Zatwierdzanie przez kierownictwo.

Faza 4: Wdrożenie zabezpieczeń (ok. 8-16 tygodni, równolegle z fazą 3). Wdrożenie zabezpieczeń technicznych i organizacyjnych zgodnie z planem postępowania z ryzykiem: konfiguracja systemów, wdrożenie nowych narzędzi (DLP, SIEM, MFA), modyfikacja procesów, szkolenia pracowników.

Faza 5: Audyt wewnętrzny i przegląd zarządczy (ok. 2-4 tygodnie). Sprawdzenie, czy SZBI faktycznie działa. Identyfikacja niezgodności, plan działań korygujących. Formalny przegląd przez kierownictwo z decyzją o przekazaniu systemu do “produkcji”.

Faza 6: Audyt zewnętrzny (opcjonalnie — tylko ISO 27001). Audyt certyfikacyjny dwuetapowy: audyt dokumentacji (Stage 1) i audyt wdrożenia (Stage 2). Po pozytywnym wyniku — wydanie certyfikatu na 3 lata z corocznymi audytami nadzoru.

Audyt SZBI po wdrożeniu jest działaniem cyklicznym. W modelu KRI musi się odbyć co najmniej raz w roku. W modelu ISO 27001 dochodzą jeszcze coroczne audyty nadzoru jednostki certyfikującej. Niezależnie od wariantu, wdrożenie SZBI to nie koniec, ale początek — system trzeba utrzymywać, doskonalić, dostosowywać do zmieniającego się środowiska zagrożeń i regulacji.

Najczęstsze pułapki przy wdrożeniu SZBI to: brak realnego wsparcia kierownictwa (projekt utyka na linii politycznej), nadmierna formalizacja (200 procedur, których nikt nie czyta), zbytnie skupienie na technologii kosztem procesów i ludzi, traktowanie audytu jako jednorazowego eventu zamiast ciągłego doskonalenia. Dobry zespół wdrożeniowy potrafi te pułapki ominąć — i właśnie to zwykle decyduje o sukcesie projektu.

Jeśli Twoja organizacja stoi przed wdrożeniem SZBI — zarówno w wariancie KRI, jak i ISO 27001 — porozmawiajmy. Pomożemy zaprojektować system na miarę Twoich potrzeb, opracować dokumentację, którą da się stosować, i przeprowadzić audyt, który da realną wartość, a nie tylko stos papieru.