W poprzednim wpisie z serii „KSC po nowelizacji w praktyce” omówiliśmy podstawowe obowiązki podmiotów kluczowych i ważnych. W centrum tych obowiązków znajduje się system zarządzania bezpieczeństwem informacji, czyli SZBI. Teraz przechodzimy do dokumentacji, czyli obszaru, który w praktyce bardzo łatwo źle zrozumieć.
Część organizacji zakłada, że wystarczy kupić gotowy pakiet dokumentów, podpisać politykę, zachować procedury w folderze i uznać, że temat został zamknięty. Ustawa o krajowym systemie cyberbezpieczeństwa oraz FAQ Ministerstwa Cyfryzacji pokazują jednak inne podejście. Dokumentacja jest ważnym elementem SZBI, ale nie powinna być oderwana od faktycznego działania organizacji, wykorzystywanych systemów informacyjnych i sposobu świadczenia usług albo realizacji zadań publicznych.
Dokumentacja ma wspierać SZBI
Ustawa wskazuje, że podmiot kluczowy lub podmiot ważny opracowuje, stosuje i aktualizuje dokumentację dotyczącą bezpieczeństwa systemu informacyjnego wykorzystywanego w procesie świadczenia usługi. Już z tego wynika, że dokumentacja nie jest jednorazowym załącznikiem do wdrożenia. Ma być opracowana, ale też stosowana i aktualizowana.
Nie oznacza to jednak, że każdy podmiot musi tworzyć rozbudowany, wielotomowy system dokumentów. Zakres dokumentacji powinien być uporządkowany i adekwatny do statusu podmiotu, charakteru jego działalności oraz wymagań, które mają do niego zastosowanie. Inaczej należy patrzeć na podmiot kluczowy, inaczej na podmiot ważny, a jeszcze inaczej na podmiot ważny będący podmiotem publicznym, który stosuje załącznik nr 4 do ustawy.
Dokumentacja normatywna i operacyjna
Ustawa rozróżnia dokumentację normatywną i dokumentację operacyjną. To rozróżnienie jest praktyczne, bo pozwala oddzielić dokumenty opisujące zasady od zapisów potwierdzających, że określone działania rzeczywiście są wykonywane.
Dokumentacja normatywna to ta część, która opisuje zasady funkcjonowania systemu zarządzania bezpieczeństwem informacji. Może obejmować m.in. polityki, procedury, zasady odpowiedzialności, dokumentację techniczną, dokumentację dotyczącą ciągłości działania czy inne dokumenty wynikające ze specyfiki działalności danego podmiotu.
Dokumentacja operacyjna to z kolei zapisy potwierdzające wykonywanie określonych czynności. Mogą to być rejestry, potwierdzenia przeglądów, wyniki testów, zapisy działań, protokoły, raporty albo logi generowane przez systemy informacyjne.
W praktyce oznacza to, że dokumentacja SZBI nie powinna ograniczać się wyłącznie do polityki bezpieczeństwa. Jednocześnie nie chodzi o tworzenie dokumentów dla samych dokumentów. Ważne jest, aby dokumentacja była możliwa do stosowania i utrzymania przez konkretną organizację.
Nie zawsze trzeba zaczynać od zera
FAQ Ministerstwa Cyfryzacji wskazuje, że organizacja nie zawsze musi tworzyć zupełnie nową, odrębną dokumentację SZBI. W pierwszej kolejności warto przejrzeć dokumenty, które już funkcjonują w organizacji.
W wielu podmiotach istnieją już różne dokumenty i regulacje, które mogą być punktem wyjścia, na przykład:
- polityki bezpieczeństwa informacji,
- procedury zarządzania uprawnieniami,
- rejestry aktywów,
- procedury wykonywania kopii zapasowych,
- dokumentacja techniczna,
- plany ciągłości działania,
- regulaminy pracy systemów,
- dokumentacja ochrony danych osobowych.
Takie dokumenty mogą zostać wykorzystane, ale wymagają sprawdzenia. Trzeba ocenić, czy są aktualne, czy odpowiadają wymaganiom ustawy o KSC i czy faktycznie dotyczą systemów informacyjnych wykorzystywanych przy świadczeniu usług albo realizacji zadań publicznych. To podejście jest znacznie rozsądniejsze niż budowanie wszystkiego od początku tylko po to, żeby stworzyć nową „teczkę NIS 2”.
Gotowa dokumentacja nie oznacza zgodności
FAQ Ministerstwa Cyfryzacji odnosi się również do sytuacji, w której organizacja kupiła dokumentację określaną jako zgodna z NIS 2. Sam zakup dokumentacji nie oznacza automatycznej zgodności z ustawą o KSC.
Dokumenty muszą zostać dostosowane do konkretnego podmiotu, jego działalności, systemów informacyjnych, sposobu organizacji pracy oraz obowiązków, które rzeczywiście go dotyczą. Inaczej pozostaną tylko formalnym zestawem wzorów.
To ważne, bo dobrze przygotowana dokumentacja powinna pomagać organizacji w uporządkowaniu bezpieczeństwa, a nie tworzyć dodatkową warstwę papieru, której nikt nie stosuje. Dokumentacja powinna być narzędziem, a nie celem samym w sobie.
Podmioty ważne będące podmiotami publicznymi
Szczególnego omówienia wymagają podmioty ważne będące podmiotami publicznymi. FAQ Ministerstwa Cyfryzacji wskazuje, że załącznik nr 4 do ustawy został przygotowany jako uproszczony zestaw wymagań dla takich podmiotów. Nie jest to więc ten sam model obowiązków, który dotyczy podmiotów kluczowych realizujących pełny zakres wymagań SZBI określony w art. 8 ustawy.
Załącznik nr 4 został podzielony na trzy części:
- Część I ma charakter obowiązkowy i powinna zostać spełniona przez każdy podmiot ważny będący podmiotem publicznym.
- Część II ma charakter fakultatywny. Obejmuje elementy, których wdrożenie podmiot powinien rozważyć, biorąc pod uwagę potrzebę zapewnienia cyberbezpieczeństwa oraz własne uwarunkowania organizacyjne, finansowe i osobowe.
- Część III ma charakter obowiązkowy i dotyczy aktualizacji oraz przeglądu spełniania obowiązków określonych w poprzednich częściach załącznika.
To rozróżnienie jest bardzo ważne, ponieważ pozwala uniknąć automatycznego przenoszenia pełnych wymagań z art. 8 na wszystkie podmioty publiczne będące podmiotami ważnymi. W praktyce oznacza to, że przed przygotowaniem dokumentacji trzeba najpierw prawidłowo ustalić status podmiotu i zakres wymagań, które mają do niego zastosowanie.
Analiza ryzyka w podmiotach publicznych ważnych
W kontekście podmiotów ważnych będących podmiotami publicznymi warto zwrócić uwagę na jeszcze jedną kwestię. FAQ Ministerstwa Cyfryzacji wskazuje, że podmiot ważny będący podmiotem publicznym, który stosuje załącznik nr 4, formalnie nie ma obowiązku przeprowadzania szacowania ryzyka.
Nie oznacza to jednak, że analiza ryzyka jest zakazana albo bezcelowa. FAQ podkreśla, że zgodnie z załącznikiem nr 4 podmiot może stosować dodatkowe środki techniczne i organizacyjne, jeżeli jest to konieczne dla zapewnienia odpowiedniego poziomu bezpieczeństwa systemów informacyjnych.
W praktyce analiza ryzyka może więc nadal być użytecznym narzędziem porządkującym bezpieczeństwo. Trzeba jednak odróżnić dobrą praktykę i racjonalne podejście do bezpieczeństwa od formalnego obowiązku wynikającego z konkretnego przepisu. To szczególnie istotne w mniejszych jednostkach publicznych, które często mają ograniczone zasoby kadrowe, organizacyjne i finansowe.
Dokumentacja powinna być adekwatna
Najważniejsze słowo w dokumentacji SZBI to adekwatność. Dokumentacja nie powinna być ani zbyt uboga, ani sztucznie rozbudowana. Powinna odpowiadać temu, jaki podmiot ją wdraża, jakie obowiązki go dotyczą i jakie systemy informacyjne są istotne dla świadczenia usług albo realizacji zadań publicznych.
Inaczej będzie wyglądać dokumentacja dużego podmiotu kluczowego, inaczej podmiotu ważnego z sektora prywatnego, a inaczej samorządowej jednostki organizacyjnej będącej podmiotem ważnym publicznym i stosującej załącznik nr 4.
Dlatego przed przygotowaniem dokumentacji nie należy zaczynać od pytania: „ile procedur musimy mieć?”. Lepiej zacząć od ustalenia:
- jaki status ma podmiot,
- który zakres wymagań go dotyczy,
- jakie systemy informacyjne są istotne dla usług albo zadań publicznych,
- jakie dokumenty już funkcjonują,
- co trzeba uzupełnić, uprościć albo uporządkować.
Takie podejście jest bezpieczniejsze i bardziej praktyczne niż tworzenie dokumentacji, która formalnie wygląda obszernie, ale nie jest możliwa do realnego stosowania.
Po co dokumentacja?
Dokumentacja SZBI ma przede wszystkim porządkować sposób zarządzania bezpieczeństwem informacji. Powinna wskazywać, kto odpowiada za określone działania, jakie zasady obowiązują w organizacji, jak zarządza się dostępami, jak zabezpiecza się systemy, jak prowadzi się kopie zapasowe, jak reaguje się na incydenty i jak utrzymuje się ciągłość działania.
Nie chodzi o to, aby każda czynność była opisana w kilku osobnych procedurach. Chodzi o to, aby organizacja miała jasne, możliwe do stosowania zasady i potrafiła wykazać, że bezpieczeństwo systemów informacyjnych jest zarządzane w sposób uporządkowany.
Dobrze przygotowana dokumentacja nie powinna komplikować działania organizacji. Powinna pomagać w tym, żeby podstawowe zasady były jasne, odpowiedzialności przypisane, a najważniejsze działania możliwe do odtwórczego wykonania także wtedy, gdy pojawia się incydent, zmiana kadrowa albo kontrola.
Co organizacja powinna zrobić w praktyce?
Pierwszym krokiem powinno być ustalenie, jakie wymagania mają zastosowanie do konkretnego podmiotu. Dopiero potem można decydować, jaki zakres dokumentacji jest potrzebny.
Drugim krokiem powinien być przegląd dokumentów już funkcjonujących w organizacji. W wielu przypadkach część wymagań można oprzeć na istniejących procedurach, politykach, rejestrach i instrukcjach.
Trzecim krokiem powinno być uporządkowanie dokumentacji tak, aby była spójna, aktualna i możliwa do stosowania. Dokumenty nie powinny dublować się ze sobą ani tworzyć sprzecznych zasad.
Czwartym krokiem powinno być zadbanie o dokumentację operacyjną, czyli o dowody wykonywania podstawowych działań. To właśnie one pokazują, że dokumentacja nie jest tylko formalnością.
Piątym krokiem powinien być przegląd i aktualizacja dokumentacji wtedy, gdy zmieniają się systemy, organizacja, zakres zadań albo wymagania dotyczące podmiotu.
Twoje bezpieczeństwo to nasza pasja! 🌐 Jeśli interesuje Cię ochrona danych osobowych, bezpieczeństwo informacji czy cyberbezpieczeństwo, zajrzyj na stronę CAB oraz Platformę Cyberbezpieczeństwa. Szukasz informacji o ochronie sygnalistów? 📢 Sprawdź stronę Kanału Zgłoszeniowego. Czekają tam praktyczne porady i ekspercka wiedza!
*Ten wpis porządkuje kwestie dokumentacji SZBI wyłącznie na podstawie ustawy o krajowym systemie cyberbezpieczeństwa oraz FAQ Ministerstwa Cyfryzacji.