W nowelizacji ustawy o krajowym systemie cyberbezpieczeństwa (UKSC), która wreszcie wdraża dyrektywę NIS 2, mamy dość precyzyjne wymagania co do dokumentacji systemu zarządzania bezpieczeństwem informacji (SZBI).
Art. 8 ust. 1 mówi wprost:
„Podmiot kluczowy lub podmiot ważny wdraża system zarządzania bezpieczeństwem informacji w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi przez ten podmiot…”
Wiemy wszyscy, że w praktyce SZBI to nie tylko „system informacyjny”, tylko cała organizacja – procesy, ludzie, otoczenie fizyczne, PPOŻ, ochrona fizyczna, ciągłość działania itd. Ale prawo jest napisane tak, jak jest – nie będziemy się bawić w adwokata diabła.
Najważniejsze: nie musicie pisać całej tej dokumentacji od nowa.
Ministerstwo Cyfryzacji jasno to potwierdziło w oficjalnej odpowiedzi na uwagi zgłoszone do projektu nowelizacji UKSC. Cytat dosłowny (druk sejmowy nr 1955, strona 753, uwaga nr 496 od ISSA Polska):
„Art. 10 ust. 3 nie wymaga tworzenia odrębnej dokumentacji.”
To nie jest jakaś luźna interpretacja – to stanowisko ministerstwa, które odpowiada za całość wdrożenia NIS 2 w Polsce. Macie więc bardzo mocny, pisemny argument zarówno przed zarządem („nie wydajemy 80 tys. na szablony, bo resort mówi, że nie trzeba”), jak i przed ewentualną kontrolą. Trzymajcie cały 1955 pod ręką, bo tam naprawdę sporo argumentów jest.
Jak to wygląda w praktyce?
Art. 10 UKSC dzieli dokumentację na dwie kategorie:
- normatywną – polityki, procedury, deklaracje stosowania, plany, polityki zarządzania ryzykiem itp.,
- operacyjną – dowody wykonania: raporty z testów penetracyjnych, rejestry incydentów, wyniki szkoleń, protokoły z przeglądów itp.
Ustęp 3 precyzyjnie określa minimalny zakres tego, co musi być udokumentowane. I właśnie tu wchodzi moja ulubiona metoda, którą stosuję od ponad 15 lat (jeszcze zanim ktoś wymyślił ładną nazwę „deklaracja stosowania”).
Deklaracja stosowania
Kiedyś, w polityce bezpieczeństwa danych osobowych z 2011 r., wpisywałem prosty zapis:
„Za bezpieczeństwo fizyczne nośników i serwerów odpowiada zewnętrzna agencja ochrony. Zasady ochrony fizycznej i technicznej określa Plan Ochronny sporządzony przez osobę posiadającą odpowiednie kwalifikacje.”
Dziś robimy to systemowo i znacznie szerzej:
- Tworzymy tabelę / wykaz wszystkich wymagań z art. 10 ust. 3 (cel, zakres, minimalna zawartość każdego dokumentu) i innych też (art. 8, 12 bo one też będą wymagały opisania).
- Robimy przeszukanie organizacji – czy taki dokument / procedura / załącznik już istnieje?
- Jeśli tak → wpisujemy:
- dokładna nazwa dokumentu
- numer wersji / data
- numer sekcji / załącznika / paragrafu → i wymaganie jest spełnione.
- Jeśli nie → dopiero wtedy modyfikujemy istniejący (jeśli coś jest, ale nie do końca pasuje) lub tworzymy nowy.
Całość jest w 100% zgodna ze stanowiskiem Ministerstwa Cyfryzacji. Zero zbędnego papieru, zero wymyślania koła na nowo.
Harmonogram Spokoju – o co naprawdę chodzi w cyklu
Zaczynamy właśnie od deklaracji stosowania, bo to naturalny pierwszy krok gap analysis (niektórzy sprzedają to jako „audyt zerowy”, choć z prawdziwym audytem ma to tyle wspólnego, co instant kawa z colą).
Kiedy już wiemy:
- co mamy i jest OK,
- co mamy, ale wymaga poprawki,
- czego kompletnie brakuje,
wtedy wychodzi realny, niedrogi, realny harmonogram wdrożeniowy.
I tu ważna uwaga: ten cykl nie jest o dokumentach. Dokumenty to tylko opis naszego myślenia o bezpieczeństwie. Trzymajmy się myślenia, a nie grubego segregatora z 400 stronami szablonów.
Masz jeszcze ponad rok do pełnego wdrożenia. Spokojnie. Nie daj się wciągnąć w panikę i w stare schematy „zapłać 50–100 tys. za pakiet dokumentów i śpij spokojnie”. To już było – przy RODO. I wszyscy pamiętamy, ile firm zostało z szufladą papieru i karami.
Więcej o tym, jak to zrobić sensownie, holistycznie i bez przepłacania – w kolejnych częściach „Harmonogramu Spokoju”.