ISO 27001:2022 zmienia sposób porządkowania zabezpieczeń, ale nie zwalnia organizacji z odpowiedzialności za realne działanie systemu zarządzania bezpieczeństwem informacji. Najlepsze rezultaty daje przełożenie 93 kontroli na właścicieli ryzyka, konkretne procesy, mierniki oraz dowody, które można wykorzystać w codziennym zarządzaniu i podczas oceny systemu.
Od numerów kontroli do modelu działania
W poprzednim układzie Załącznika A pracowano ze 114 kontrolami podzielonymi na 14 obszarów. W wydaniu z 2022 roku otrzymujemy 93 kontrole pogrupowane w cztery kategorie: organizacyjne, ludzkie, fizyczne i technologiczne. To nie jest wyłącznie zmiana redakcyjna. Nowa struktura ułatwia przypisanie odpowiedzialności zespołom, które rzeczywiście zarządzają ryzykiem: właścicielom procesów, działom IT, bezpieczeństwa, HR, utrzymania obiektów oraz kierownikom biznesowym.
Zmiana ma sens tylko wtedy, gdy organizacja przestaje traktować Załącznik A jak listę kontrolną. Każdą kontrolę należy powiązać z ryzykiem, wymaganiem biznesowym, właścicielem, sposobem realizacji i dowodem działania. W praktyce oznacza to odejście od pytania „czy mamy procedurę?” na rzecz pytań: kto podejmuje decyzję, jak często kontrola działa, co dzieje się w przypadku wyjątku i jaki zapis potwierdza wykonanie zadania.
Dobrym punktem wyjścia jest przegląd analizy ryzyka oraz zakresu ISMS. Następnie warto przeprowadzić GAP assessment, porównując istniejące zabezpieczenia z kontrolami wersji 2022. Wyniki powinny być uporządkowane według właścicieli i strumieni pracy, na przykład: tożsamość i dostęp, operacje IT, ochrona danych oraz ciągłość działania. Taki podział ogranicza ryzyko rozproszenia działań i ułatwia planowanie kolejnych iteracji. W tym procesie pomocne może być praktyczne podejście do zarządzania ryzykiem w systemach jakości(/) jako inspiracja do uporządkowania kryteriów, odpowiedzialności i decyzji.
SOA jako mapa odpowiedzialności i dowodów
Deklaracja stosowania, czyli SOA, nie powinna być dokumentem tworzonym wyłącznie na potrzeby audytu. Jej wartość rośnie, gdy pokazuje logiczne przejście od ryzyka do kontroli, a następnie od kontroli do dowodu. Dla każdej pozycji warto opisać, czy została włączona, w jaki sposób jest realizowana, kto jest właścicielem oraz jakie zapisy potwierdzają jej skuteczność. Uzasadnienie wyłączenia również powinno wynikać z analizy ryzyka i zakresu systemu, a nie z braku czasu na wdrożenie.
Przykładowo, jeżeli organizacja zidentyfikowała wysokie ryzyko nieuprawnionego ujawnienia danych, SOA może wskazywać klasyfikację informacji, reguły dostępu, szkolenia, monitorowanie zdarzeń i zasady reagowania. Dowodami będą wtedy nie tylko zatwierdzone polityki, lecz także wyniki przeglądów uprawnień, raporty z monitoringu, rejestry wyjątków, potwierdzenia szkoleń oraz zapisy działań korygujących. Właśnie takie połączenie pokazuje, że kontrola funkcjonuje w procesie, a nie wyłącznie w dokumentacji.
Warto także rozdzielić widok techniczny od menedżerskiego. Zespół operacyjny potrzebuje informacji o konfiguracji, podatnościach, logach i zadaniach administracyjnych. Zarząd powinien natomiast widzieć poziom ryzyka, trendy, wyjątki, wpływ na usługi krytyczne i decyzje wymagające akceptacji. W obu przypadkach źródłem powinna być ta sama logika SOA, lecz przedstawiona z odpowiednim poziomem szczegółowości. Przydatnym uzupełnieniem może być macierz oceny ryzyka dla decyzji procesowych(/), o ile zostanie dopasowana do kryteriów obowiązujących w danej organizacji.
Właściciele ryzyka, mierniki i rytm przeglądów
Najczęstszy problem z wdrażaniem nowych kontroli nie polega na braku narzędzi, lecz na niejasnej odpowiedzialności. Właściciel kontroli powinien mieć możliwość podejmowania decyzji, zapewnienia zasobów i eskalowania wyjątków. Nie musi samodzielnie wykonywać wszystkich czynności, ale powinien wiedzieć, kto je realizuje, według jakiego standardu i z jaką częstotliwością. RACI, mapa procesów oraz rejestr ryzyk pomagają rozdzielić role bez dublowania zadań.
Nowe kontrole dotyczą między innymi bezpieczeństwa chmury, gotowości ICT na potrzeby ciągłości działania, monitorowania aktywności, filtrowania stron internetowych, bezpiecznego programowania, maskowania danych i zapobiegania utracie danych. Nie należy wdrażać ich automatycznie tylko dlatego, że są nowe. Najpierw trzeba ocenić ich znaczenie dla kontekstu organizacji, usług, danych i łańcucha dostaw. Jeżeli dana kontrola zostaje włączona, należy określić oczekiwany rezultat oraz sposób jego weryfikacji.
Mierniki powinny wspierać decyzje, a nie tworzyć kolejną warstwę raportowania. Mogą obejmować odsetek kont bez wieloskładnikowego uwierzytelniania, czas zamknięcia krytycznych podatności, liczbę wyjątków od standardu konfiguracji, czas reakcji na incydent albo wyniki testów odtwarzania usług. Każdy wskaźnik potrzebuje właściciela, częstotliwości pomiaru i progu reakcji. Sama wartość liczbowa nie świadczy jeszcze o skuteczności kontroli.
W środowiskach o wysokiej odpowiedzialności podobna dyscyplina dotyczy również systemów jakości. Dlatego jako kontekst dojrzałości procesowej można wykorzystać zasady zarządzania ryzykiem i zmianą w systemie AS 9100(/), pamiętając, że wymagania tego standardu dotyczą innego obszaru niż bezpieczeństwo informacji.
Plan migracji bez zakłócania operacji
Przejście na ISO 27001:2022 warto prowadzić etapami. Pierwszy etap powinien obejmować kontekst organizacji, interesariuszy, wymagania oraz aktualizację kryteriów oceny ryzyka. Drugi to mapa istniejących zabezpieczeń względem 93 kontroli i identyfikacja luk. Trzeci obejmuje zaplanowanie zmian, właścicieli, terminów oraz wymaganych dowodów. Dopiero później należy aktualizować SOA, procedury i rejestry w zakresie wynikającym z analizy.
Praktyczny harmonogram może dzielić pracę na krótkie pakiety. W obszarze tożsamości będą to przeglądy uprawnień, konta uprzywilejowane i uwierzytelnianie. W operacjach IT: standardy konfiguracji, zarządzanie podatnościami i kontrola zmian. Dla danych: klasyfikacja, retencja, maskowanie i ograniczenia transferu. Dla ciągłości: priorytety usług, scenariusze odtwarzania oraz testy. Każdy pakiet powinien kończyć się nie tylko wdrożeniem, lecz także oceną działania i aktualizacją dowodów.
Najważniejsza jest spójność: ryzyko wyznacza priorytet, właściciel odpowiada za realizację, kontrola opisuje sposób postępowania, a dowód potwierdza wykonanie. Tak zbudowana SOA staje się narzędziem zarządzania, a nie katalogiem deklaracji. Pozwala również prowadzić rozmowę z zarządem językiem skutków biznesowych: dostępności usług, ochrony danych, odporności operacyjnej i kosztu wyjątków.
ISO 27001:2022 nie wymaga mechanicznego przepisywania całego systemu od początku. Wymaga świadomego sprawdzenia, czy obecne zabezpieczenia odpowiadają ryzyku, czy mają właścicieli i czy można wykazać ich działanie. To właśnie te trzy elementy powinny wyznaczać kolejność prac oraz zakres zmian w organizacji.
Artykuł sponsorowany
