Dokumentacja SZBI zgodna z ISO 27001 w praktyce

Dokumentacja SZBI zgodna z ISO 27001 porządkuje ryzyko, odpowiedzialności i dowody działania kontroli podczas audytu oraz po incydencie w praktyce.

Audytor prosi o dowód, że krytyczny dostęp został okresowo zweryfikowany. Zespół IT wie, że przegląd wykonano, ale nie potrafi wskazać właściciela kontroli, zakresu systemów, kryterium akceptacji ani zatwierdzonego zapisu. W takim momencie dokumentacja SZBI zgodna z ISO 27001 przestaje być formalnością. Staje się mechanizmem, który łączy ryzyko biznesowe, wykonanie kontroli i dowody potrzebne zarządowi, audytorowi oraz regulatorowi.

W organizacjach regulowanych problem rzadko polega na całkowitym braku dokumentów. Częściej dokumenty są rozproszone między IT, compliance, HR, dostawcami i zespołem bezpieczeństwa. Polityka mówi jedno, procedura drugie, a rzeczywista konfiguracja środowiska produkcyjnego trzecie. Celem nie jest więc stworzenie obszernego segregatora. Celem jest zbudowanie systemu zarządzania bezpieczeństwem informacji, który da się stosować, mierzyć i obronić na podstawie aktualnych dowodów.

Co musi obejmować dokumentacja SZBI zgodna z ISO 27001

Norma ISO/IEC 27001:2022 nie narzuca jednej listy plików ani wzoru „księgi SZBI”. Wymaga natomiast udokumentowanych informacji niezbędnych do działania systemu oraz tych, które są wyraźnie wskazane przez normę. To ważne rozróżnienie. Organizacja nie powinna kopiować kilkudziesięciu polityk tylko dlatego, że występują w szablonie. Powinna umieć wykazać, że zarządza konkretnym ryzykiem w swoim zakresie certyfikacji.

Punktem wyjścia jest precyzyjnie określony zakres SZBI. Musi on uwzględniać procesy, lokalizacje, spółki, systemy, usługi chmurowe, interfejsy z dostawcami oraz zależności zewnętrzne. Zakres typu „bezpieczeństwo informacji w organizacji” jest zwykle zbyt ogólny. Dla operatora produkcji trzeba jasno rozstrzygnąć, czy obejmuje on sieć OT, stacje inżynierskie, zdalny dostęp serwisowy i środowiska wspierające produkcję. Dla instytucji finansowej krytyczne będą także systemy przetwarzania danych klientów, usługi ICT dostawców oraz kanały wymiany informacji.

Kolejnym elementem jest kontekst organizacji: wymagania stron zainteresowanych, obowiązki prawne i regulacyjne, cele bezpieczeństwa oraz role decyzyjne. To tutaj należy powiązać SZBI z realiami NIS2, DORA, KSC, umowami z klientami czy wymaganiami właścicieli infrastruktury. ISO 27001 nie zastępuje tych regulacji. Może jednak dostarczać uporządkowaną strukturę dowodów, odpowiedzialności i cykli przeglądowych potrzebnych do ich realizacji.

Rdzeniem dokumentacji pozostaje metodyka oceny ryzyka. Powinna opisywać kryteria wpływu i prawdopodobieństwa, progi akceptacji, sposób identyfikacji właścicieli ryzyka oraz zasady ponownej oceny. Największą wartość ma wtedy, gdy odwołuje się do konsekwencji operacyjnych: zatrzymania linii, utraty dostępności usługi, naruszenia poufności danych, kar regulacyjnych, oszustwa lub niewykonania zobowiązań kontraktowych. Ocena oparta wyłącznie na technicznej punktacji CVSS nie wystarcza do zarządzania ryzykiem biznesowym.

Wynikiem powinny być rejestr ryzyk i plan postępowania z ryzykiem. Każde istotne ryzyko wymaga decyzji: ograniczyć, przenieść, zaakceptować albo uniknąć. Jeśli decyzją jest ograniczenie, plan musi wskazywać kontrolę, właściciela, termin, budżet lub zasoby, miernik ukończenia i pozostałe ryzyko po wdrożeniu. To właśnie ten poziom szczegółowości pozwala prowadzić kontrolowaną remediację zamiast gromadzić rekomendacje bez właściciela.

Niezbędna jest także deklaracja stosowania, czyli Statement of Applicability. Dokument pokazuje, które kontrole z załącznika A mają zastosowanie, dlaczego zostały włączone lub wyłączone oraz jak są wdrożone. W wersji 2022 załącznik A obejmuje 93 kontrole podzielone na obszary organizacyjne, ludzkie, fizyczne i technologiczne. Deklaracja nie może być listą mechanicznie zaznaczonych pozycji. Jeżeli organizacja wyłącza kontrolę dotyczącą określonego rozwiązania technicznego, musi umieć wykazać, że wyłączenie wynika z zakresu i oceny ryzyka, a nie z braku gotowości.

Polityki, procedury i dowody: trzy różne warstwy

Skuteczny SZBI rozdziela dokumenty zarządcze, instrukcje wykonawcze i zapisy potwierdzające działanie. Mieszanie tych warstw jest częstą przyczyną niezgodności. Polityka określa kierunek i odpowiedzialność. Procedura opisuje, kto oraz w jakim trybie wykonuje działanie. Dowód pokazuje, że działanie rzeczywiście wykonano.

Polityka bezpieczeństwa informacji powinna być zatwierdzona przez właściwy poziom zarządzania i przekładać cele biznesowe na zasady ochrony informacji. Obok niej zwykle potrzebne są regulacje dotyczące zarządzania aktywami, dostępami, dostawcami, incydentami, ciągłością działania, klasyfikacją informacji, bezpiecznym wytwarzaniem oprogramowania, podatnościami oraz kopią zapasową. Zakres zależy od ryzyka i modelu operacyjnego organizacji.

Procedury muszą nadawać się do użycia pod presją czasu. Procedura obsługi incydentu powinna określać triage według SLA, ścieżki eskalacji, zasady zabezpieczania materiału dowodowego, komunikację z biznesem oraz warunki zamknięcia sprawy. Procedura zarządzania podatnościami musi wiązać wynik skanu lub pentestu z właścicielem zasobu, oceną ekspozycji, terminem naprawy, wyjątkiem i weryfikacją remediacji. Sam raport z testu nie jest dowodem funkcjonującego procesu.

Dowody procesów powinny powstawać w ramach codziennej pracy, nie dopiero tydzień przed audytem. Mogą to być między innymi:

• zatwierdzone oceny ryzyka, rejestry wyjątków i decyzje o akceptacji ryzyka;
• zapisy przeglądów dostępów uprzywilejowanych oraz potwierdzenia odebrania uprawnień;
• zgłoszenia incydentów, raporty z ćwiczeń i działania poanalizowe;
• wyniki skanów, raporty pentestowe, tickety remediacyjne i potwierdzenia retestów;
• protokoły przeglądów zarządzania, audytów wewnętrznych i działań korygujących.

Warto od początku zdefiniować, gdzie dowody są przechowywane, kto je zatwierdza, jak długo są retencjonowane i kto kontroluje ich kompletność. Bez tej dyscypliny organizacja może mieć dobre praktyki operacyjne, ale nie będzie potrafiła ich wykazać w spójny sposób.

Jak opracować dokumentację bez tworzenia papierowego SZBI

Najbezpieczniejsza kolejność prac zaczyna się od diagnozy stanu faktycznego. Należy zestawić istniejące polityki, umowy, architekturę, wyniki audytów, rejestry aktywów, procesy SOC oraz praktykę zespołów IT i OT. Dopiero wtedy można wykonać analizę luk względem wymagań ISO 27001 i przyjąć realistyczny plan wdrożenia. Pisanie dokumentów przed rozpoznaniem procesów prowadzi zwykle do instrukcji, których nikt nie wykonuje.

Następnie trzeba uzgodnić model odpowiedzialności. Właściciel systemu nie musi być właścicielem ryzyka, a CISO nie powinien zatwierdzać wszystkich wyjątków technicznych. RACI dla kluczowych procesów pozwala wskazać, kto odpowiada za decyzję, wykonanie, konsultację i informowanie. Jest to szczególnie istotne w grupach kapitałowych oraz środowiskach, gdzie usługi IT świadczy centrum wspólne lub zewnętrzny dostawca.

Trzeci etap to połączenie kontroli z realnymi narzędziami i procesami. Jeśli kontrola wymaga monitorowania zdarzeń, dokumentacja powinna wskazywać źródła logów, odpowiedzialność za ich analizę, reguły eskalacji i retencję. Jeżeli wymaga segmentacji sieci, należy opisać strefy, zasady przepływu, proces zatwierdzania zmian oraz sposób okresowej weryfikacji. W OT/ICS trzeba uwzględnić ograniczenia dostępności i walidować zmiany tak, aby remediacja nie powodowała ryzyka przestoju produkcji.

Na końcu pozostaje test działania systemu: audyt wewnętrzny, przegląd zarządzania, ćwiczenie reagowania na incydent oraz weryfikacja zamknięcia działań korygujących. Te aktywności nie są dodatkiem do dokumentacji. Są jej sprawdzianem. Jeżeli podczas ćwiczenia nikt nie wie, kto podejmuje decyzję o odcięciu dostępu dostawcy, dokument należy poprawić razem z procesem, a nie tylko zmienić jego brzmienie.

Błędy, które podważają gotowość audytową

Najczęstszy błąd to traktowanie certyfikacji jako projektu dokumentacyjnego prowadzonego wyłącznie przez compliance. SZBI bez danych o podatnościach, ekspozycji usług, incydentach i konfiguracji środowiska nie odzwierciedla rzeczywistego ryzyka. Odwrotnie, zespół techniczny działający bez zatwierdzonych kryteriów ryzyka oraz śladu decyzyjnego nie zapewni wystarczających dowodów dla audytu i zarządu.

Ryzykowne jest również kopiowanie deklaracji stosowania z innej organizacji. Dwie firmy mogą korzystać z podobnej chmury, ale mieć odmienne dane, modele dostępu, zobowiązania wobec klientów i tolerancję przestoju. Kontrole muszą wynikać z własnego zakresu i ryzyka.

Problemem bywa także brak cyklu aktualizacji. Nowy dostawca, przejęcie spółki, wdrożenie systemu ERP, zmiana architektury chmurowej czy podłączenie urządzeń przemysłowych powinny uruchamiać ocenę wpływu na SZBI. Dokumentacja, która nie zmienia się mimo zmian operacyjnych, szybko traci wartość dowodową.

Dobrze przygotowana dokumentacja nie ma robić wrażenia objętością. Ma pozwolić szybko odpowiedzieć na pytania: jakie ryzyko kontrolujemy, kto odpowiada za działanie, gdzie jest dowód i co stanie się, gdy kontrola zawiedzie. SprintTech buduje takie SZBI od stanu faktycznego środowiska, tak aby zespoły techniczne mogły realizować ustalone działania, a zarząd otrzymywał mierzalny obraz ryzyka i postępu remediacji.