Audytor pyta o właściciela aktywów, a dział IT wskazuje serwerownię. Zarząd pyta o poziom ryzyka, a otrzymuje listę wdrożonych narzędzi. To jeden z najczęstszych sygnałów, że System Zarządzania Bezpieczeństwem Informacji istnieje tylko częściowo. Wiedza techniczna jest potrzebna, ale nie zastąpi zarządzania ryzykiem, odpowiedzialnością i dowodami działania kontroli. Dlatego pytanie, jak przygotować SZBI, powinno zaczynać się nie od kupowania szablonów ani od pisania polityki, lecz od określenia, co organizacja ma chronić i kto za to odpowiada.
Dobrze zbudowany SZBI porządkuje decyzje dotyczące bezpieczeństwa. Łączy wymagania biznesowe, techniczne i prawne w system, który można utrzymać, sprawdzić oraz obronić przed audytorem, klientem lub organem nadzorczym. W realiach NIS2, KSC, RODO i coraz częstszych wymagań kontraktowych dokumentacja bez praktyki nie wystarczy. Tak samo nie wystarczy dobra ochrona techniczna bez formalnych zasad i dowodów ich stosowania.
Jak przygotować SZBI: zacznij od zakresu i odpowiedzialności
Największym błędem jest objęcie SZBI całej organizacji „na zapas”, bez oceny możliwości utrzymania tak szerokiego zakresu. Zakres powinien obejmować procesy, lokalizacje, systemy, dane, usługi zewnętrzne i role, które są istotne dla bezpieczeństwa oraz ciągłości działania. W jednostce publicznej może to być obsługa mieszkańców i systemy dziedzinowe. W firmie produkcyjnej – system ERP, sieć OT, zamówienia i logistyka. W biurze usługowym – dane klientów, poczta, urządzenia końcowe i środowisko chmurowe.
Zakres trzeba opisać precyzyjnie. Sformułowanie „cała infrastruktura IT” nie odpowiada na pytanie, czy obejmuje dostawcę chmury, pracę zdalną, prywatne telefony, archiwum papierowe albo systemy utrzymywane przez podmiot zewnętrzny. Granice SZBI muszą być zrozumiałe dla zarządu, IT i osób realizujących procesy biznesowe.
Równolegle należy ustanowić role. Zarząd zatwierdza politykę, akceptuje ryzyko i zapewnia zasoby. Właściciele procesów określają znaczenie informacji i skutki zakłóceń. IT wdraża oraz utrzymuje zabezpieczenia. Osoba odpowiedzialna za SZBI koordynuje system, pilnuje przeglądów i raportuje kierownictwu. Nie warto przypisywać wszystkich obowiązków jednemu administratorowi – zwłaszcza gdy nie ma on mandatu do egzekwowania decyzji w innych działach.
Zbuduj inwentaryzację, która odzwierciedla rzeczywistość
Nie da się rzetelnie ocenić ryzyka dla aktywów, których organizacja nie zna. Inwentaryzacja powinna obejmować nie tylko laptopy i serwery, lecz także informacje, aplikacje, konta uprzywilejowane, usługi SaaS, urządzenia sieciowe, kopie zapasowe, dokumentację papierową oraz kluczowych dostawców.
Sama tabela aktywów to za mało. Dla każdego istotnego elementu należy wskazać właściciela, lokalizację lub środowisko przetwarzania, klasyfikację informacji oraz zależności. Przykładowo system finansowy może zależeć od dostawcy chmury, usługi tożsamości, łącza internetowego, administratora zewnętrznego i regularnych kopii zapasowych. Awaria dowolnego z tych elementów może zatrzymać proces, mimo że serwer działa poprawnie.
Klasyfikacja informacji powinna odpowiadać potrzebom organizacji. Najczęściej uwzględnia się poufność, integralność i dostępność. Dane osobowe, dane finansowe, dokumentacja przetargowa czy informacje o infrastrukturze krytycznej będą wymagać odmiennego poziomu ochrony. Klasyfikacja nie może być dekoracją w polityce – powinna wpływać na uprawnienia, szyfrowanie, retencję, sposób przesyłania danych i zasady udostępniania.
Analiza ryzyka ma prowadzić do decyzji, nie do arkusza
Analiza ryzyka jest osią SZBI zgodnego z ISO 27001. Jej celem nie jest wyprodukowanie rozbudowanego rejestru zagrożeń, lecz podjęcie świadomych decyzji: co ograniczyć, co przenieść na dostawcę, co zaakceptować, a czego unikać.
Przyjęta metodyka musi być zrozumiała i powtarzalna. Organizacja powinna zdefiniować kryteria prawdopodobieństwa, wpływu oraz akceptacji ryzyka. Wpływ warto oceniać szerzej niż przez koszt odtworzenia sprzętu. Incydent może skutkować przerwą w usługach, naruszeniem danych, karami, odpowiedzialnością umowną, utratą reputacji lub zagrożeniem dla realizacji zadań publicznych.
Dla każdego istotnego ryzyka potrzebny jest właściciel i plan postępowania. Jeżeli ryzyko dotyczy phishingu, właściwą odpowiedzią nie będzie wyłącznie szkolenie pracowników. Zwykle konieczne są też filtrowanie poczty, MFA, procedura zgłaszania podejrzanych wiadomości, ograniczenie uprawnień oraz testy odporności. Z kolei ryzyko niedostępności systemu może wymagać kopii zapasowych, testów odtworzeniowych, zapasowego łącza i uzgodnionych czasów odtworzenia.
Należy pamiętać o ryzyku dostawców. Wiele organizacji korzysta z usług księgowych, chmurowych, serwisowych i telekomunikacyjnych, lecz nie weryfikuje ich zasad bezpieczeństwa ani zapisów umownych. Umowa powinna określać m.in. odpowiedzialność, zasady zgłaszania incydentów, dostęp do danych, podwykonawców, ciągłość działania oraz zakończenie współpracy. Zakres kontroli zależy od skali i krytyczności usługi – nie każdy dostawca wymaga takiego samego poziomu oceny.
Dobierz zabezpieczenia i zamień je w działające procesy
Plan postępowania z ryzykiem prowadzi do doboru zabezpieczeń organizacyjnych, fizycznych, technicznych i prawnych. Deklaracja, że organizacja „stosuje zabezpieczenia z ISO 27001”, nie jest dowodem. Potrzebne są konkretne mechanizmy, właściciele, terminy wdrożenia i sposób weryfikacji skuteczności.
W praktyce podstawą są zarządzanie tożsamością i dostępami, MFA, aktualizacje, ochrona urządzeń końcowych, segmentacja sieci, kopie zapasowe, kontrola dostawców oraz szkolenia. W organizacjach narażonych na większe ryzyko potrzebne będzie również centralne monitorowanie zdarzeń, korelacja alertów i szybki triage incydentów. XDR lub EDR nie zastąpi SZBI, ale daje dowody operacyjne, że organizacja wykrywa zdarzenia i reaguje w określony sposób.
Szczególną uwagę trzeba poświęcić kopiom zapasowym. W wielu środowiskach backup istnieje, ale nikt nie potwierdził, czy można z niego odtworzyć krytyczny system w wymaganym czasie. Regularne testy odtworzeniowe, rozdzielenie kopii od środowiska produkcyjnego oraz jasne parametry RTO i RPO są ważniejsze niż samo posiadanie narzędzia backupowego.
Dokumentacja SZBI musi być użyteczna podczas incydentu
Polityka bezpieczeństwa informacji wyznacza kierunek, ale nie może być jedynym dokumentem. System wymaga spójnych procedur i rejestrów. Powinny one obejmować między innymi zarządzanie ryzykiem, dostępami, aktywami, incydentami, ciągłością działania, dostawcami, kopiami zapasowymi, zmianami oraz szkoleniami.
Dokumenty mają opisywać faktyczny model pracy. Procedura reagowania na incydent, której nie zna osoba dyżurująca w IT, nie ochroni organizacji w czasie ransomware. Właściwa procedura określa, kto kwalifikuje zdarzenie, kto podejmuje decyzję o izolacji systemu, jak zabezpiecza się dowody, kiedy informuje się zarząd i kto ocenia obowiązek zgłoszenia naruszenia danych osobowych.
Wymagania NIS2 i krajowych regulacji zwiększają znaczenie zarządzania incydentami, ciągłości działania oraz odpowiedzialności kierownictwa. Nie należy jednak kopiować zapisów prawnych do polityki. Trzeba przełożyć je na mierzalne działania: terminy eskalacji, kanały kontaktu, ćwiczenia, raportowanie oraz okresowe przeglądy.
Przygotuj dowody działania przed audytem
Audyt SZBI nie ocenia wyłącznie jakości dokumentów. Audytor będzie szukał dowodów, że system działa: zatwierdzonych analiz ryzyka, przeglądów uprawnień, wyników szkoleń, rejestru incydentów, testów backupu, oceny dostawców, raportów z monitorowania i decyzji zarządu.
Warto ustalić kalendarz SZBI. Część działań wykonuje się na bieżąco, np. obsługę incydentów czy nadawanie dostępów. Inne wymagają cykliczności: przegląd ryzyka, audyt wewnętrzny, test ciągłości działania, ocena dostawców oraz przegląd zarządzania. Bez harmonogramu organizacja zazwyczaj przypomina sobie o tych obowiązkach tuż przed audytem, gdy brakuje już czasu na usunięcie niezgodności.
Audyt wewnętrzny powinien sprawdzać nie tylko zgodność z dokumentacją, ale też jej przydatność. Jeśli procedura przewiduje reakcję w cztery godziny, a logi są dostępne dopiero po dwóch dniach, problem leży w procesie i narzędziach, nie w sformułowaniu procedury. Po audycie konieczne są działania korygujące z terminem, właścicielem i potwierdzeniem zamknięcia.
SZBI nie powinien powstawać jako projekt na dzień certyfikacji lub kontroli. Największą wartość daje wtedy, gdy pomaga zarządowi podejmować decyzje, a zespołom działać pod presją incydentu. Zacznij od realnego zakresu, przypisz odpowiedzialność i utrzymuj rytm kontroli – wtedy zgodność staje się skutkiem dobrze zarządzanego bezpieczeństwa, a nie kosztownym ćwiczeniem dokumentacyjnym.