Budowa systemu ciągłości działania zgodnego z ISO 22301 to zadanie, które łatwo zarówno przecenić, jak i nie docenić jego wagi. Niektóre organizacje traktują je jak wielomiesięczny projekt wymagający zewnętrznych konsultantów i setek stron dokumentacji. Inne zakładają, że wystarczy spisać kilka planów awaryjnych, żeby zamknąć temat. Ani jedno, ani drugie podejście nie poskutkuje powstaniem systemu, który faktycznie zadziała w sytuacji kryzysowej i przejdzie audyt. W tym artykule omówimy, jak podejść do wdrożenia systemu zgodnego z normą ISO 22301 krok po kroku, bez zbędnego rozbudowywania go, ale też bez pomijania naprawdę istotnych czynników.
Czym jest norma ISO 22301?
ISO 22301 określa wymagania dla systemu zarządzania ciągłością działania (BCMS, ang. Business Continuity Management System). Norma wymaga między innymi przeprowadzenia analizy wpływu na biznes, opracowania planów ciągłości działania i ich regularnego testowania. Nie narzuca natomiast konkretnych narzędzi ani rozwiązań technicznych, dzięki czemu ma zastosowanie zarówno w kilkudziesięcioosobowej firmie, jak i w dużej instytucji finansowej. System wdrożony zgodnie z ISO 22301 musi też być stale udoskonalany, a wnioski z każdego audytu lub testu powinny prowadzić do korekt.
Dlaczego zarządzanie ciągłością działania jest kluczowe
Zakłócenia operacyjne zdarzają się niezależnie od tego, jak dobrze organizacja jest na nie przygotowana. Może to być awaria centrum danych, utrata kluczowego dostawcy albo cyberatak paraliżujący systemy IT. Bez formalnego systemu ciągłości działania reakcja na takie zdarzenia jest doraźna, co wydłuża przestój i zwiększa straty.
Do tego dochodzi presja regulacyjna. Dyrektywa NIS2 wymaga od podmiotów kluczowych i ważnych wdrożenia środków zapewniających ciągłość działania. Rozporządzenie DORA stawia analogiczne wymagania instytucjom finansowym w zakresie cyfrowej odporności operacyjnej. W obu przypadkach organizacje muszą posiadać odpowiednie plany awaryjne oraz udowodnić, że są one testowane i aktualizowane.
Rosną też oczekiwania kontrahentów. Duzi klienci, zwłaszcza w sektorze finansowym, coraz częściej proszą dostawców o formalne potwierdzenie, że ci zarządzają ciągłością działania. Certyfikat ISO 22301 jest niezależnym dowodem zgodności z uznanym standardem i upraszcza takie rozmowy. Firmy, które wdrożyły już elementy zarządzania ciągłością działania (np. wspomniane plany awaryjne, kopie zapasowe czy procedury eskalacji), ale nie łączą ich w spójny system, znajdują w ISO 22301 ramy pozwalające te rozproszone elementy powiązać.
ISO 22301 a BCM – zależności i różnice
Zarządzanie ciągłością działania (BCM, ang. Business Continuity Management) można wdrożyć na dwa sposoby. Pierwszy to podejście nieformalne: organizacja buduje system ciągłości działania samodzielnie, dobierając metody i zakres według własnego uznania. Ma wtedy dużą swobodę, ale trudniej jej udowodnić audytorowi lub organowi regulacyjnemu, że system jest kompletny i skuteczny.
Drugi sposób to wdrożenie BCM według ISO 22301. Norma nie zmienia istoty zarządzania ciągłością działania, tylko nadaje mu formalną strukturę: wskazuje, jakie elementy system musi zawierać i jak wykazać, że faktycznie działają. [ŁK2]
Struktura normy ISO 22301
Norma składa się z dziesięciu klauzul. Trzy pierwsze dotyczą zakresu normy i terminologii. Wymagania, które firma musi spełnić, zaczynają się od klauzuli czwartej.
Klauzula 4 dotyczy kontekstu. Organizacja określa, w jakim otoczeniu działa, kto jest zainteresowany jej ciągłością działania i jaki zakres ma mieć system BCMS. Klauzula 5 wymaga zaangażowania kierownictwa, w tym formalnego zatwierdzenia polityki ciągłości działania i przydzielenia zasobów. Klauzula 6 to planowanie, identyfikacja ryzyk i szans oraz ustalenie celów systemu. Klauzula 7 dotyczy wsparcia, czyli kompetencji zespołu, świadomości pracowników i zarządzania dokumentacją.
Klauzule 8–10 to rdzeń operacyjny. Klauzula 8 zawiera wymagania dotyczące analizy wpływu na biznes (BIA), oceny ryzyka, strategii ciągłości i planów BCP. Klauzula 9 wymaga monitorowania, audytów wewnętrznych i przeglądów zarządzania. Klauzula 10 zamyka cykl: niezgodności prowadzą do działań korygujących, a te do doskonalenia systemu.
Taki układ odpowiada cyklowi PDCA (ang. Plan-Do-Check-Act). Klauzule 4-7 to faza planowania, klauzula 8 to wdrożenie, klauzula 9 to weryfikacja, a klauzula 10 to korekty i doskonalenie. Zastosowanie PDCA sprawia, że BCMS ewoluuje po każdym teście, audycie czy rzeczywistym incydencie.
Analiza wpływu na biznes (BIA)
Analiza BIA (ang. Business Impact Analysis) to punkt wyjścia do budowy planów ciągłości działania. Zaczyna się ona od inwentaryzacji aktywów organizacji: procesów biznesowych, systemów IT, personelu, lokalizacji i dostawców zewnętrznych, a następnie oceny, jakie skutki niesie niedostępność każdego z nich. Skutki te mogą być finansowe (utrata przychodów, kary umowne), regulacyjne (naruszenie obowiązków wobec organu nadzorczego) lub operacyjne (zatrzymanie produkcji, brak możliwości obsługi klientów). Na tej podstawie organizacja ustala, które aktywa i procesy są krytyczne i w jakiej kolejności wymagają ochrony.
Następnie firma określa kilka ważnych parametrów dla każdego z tych procesów. Pierwszy z nich to maksymalny tolerowany czas przestoju (MTPD, ang. Maximum Tolerable Period of Disruption), czyli najdłuższy dopuszczalny okres, przez który dany proces może nie działać, zanim skutki staną się nie do zaakceptowania. Drugi to minimalny poziom usług (MBCO, ang. Minimum Business Continuity Objective), czyli najniższy zakres działania, przy którym firma jest jeszcze w stanie funkcjonować. Z MTPD wynika kolejny parametr: RTO (ang. Recovery Time Objective), czyli czas, w jakim proces musi zostać faktycznie przywrócony. RTO musi być krótszy niż MTPD, bo uwzględnia margines na uruchomienie procedur awaryjnych. W kontekście systemów IT istotny jest też RPO (ang. Recovery Point Objective), który określa maksymalną dopuszczalną utratę danych mierzoną w czasie i wpływa na politykę tworzenia kopii zapasowych.
W procesie BIA powinni brać udział właściciele procesów biznesowych, a nie wyłącznie dział IT. To osoby odpowiedzialne za sprzedaż, logistykę, finanse czy obsługę klienta wiedzą najlepiej, jakie konsekwencje niesie przestój ich procesów i jakie zależności łączą je z innymi częściami firmy. Wyniki analizy BIA dają podstawy do oceny ryzyka i opracowania strategii ciągłości działania.
Ocena ryzyka w kontekście ciągłości działania
Analiza BIA pokazuje, które aktywa, w tym procesy są krytyczne i ile czasu firma ma na ich przywrócenie. Ocena ryzyka odpowiada na pytanie, co może te procesy zakłócić i jakie jest prawdopodobieństwo, że do tego dojdzie.
Zagrożenia mogą mieć różny charakter. Awaria infrastruktury IT, pożar w budynku, utrata kluczowego dostawcy, cyberatak lub pandemia to tylko niektóre z nich. Dla każdego zagrożenia warto oszacować, jak prawdopodobne jest jego wystąpienie i jak poważne byłyby skutki dla aktywów zidentyfikowanych w BIA. Taka ocena pozwala ustalić, które ryzyka wymagają zabezpieczeń w pierwszej kolejności, a które można zaakceptować.
Ocena ryzyka w kontekście ciągłości działania różni się od tej przeprowadzanej na potrzeby bezpieczeństwa informacji (np. w ramach ISO 27001). W ISO 27001 punktem wyjścia są aktywa informacyjne i zagrożenia dla ich poufności, integralności i dostępności. W ISO 22301 chodzi o zdolność firmy do utrzymania kluczowych procesów biznesowych niezależnie od źródła zakłócenia. Obie analizy ryzyka mogą się uzupełniać, ale odpowiadają na inne pytania i prowadzą do innych decyzji.
Strategie i plany ciągłości działania (BCP)
Na podstawie wyników BIA i oceny ryzyka firma opracowuje strategie ciągłości działania, czyli sposoby utrzymania lub szybkiego przywrócenia procesów krytycznych w razie zakłócenia.
Strategie mogą dotyczyć różnych obszarów. W zakresie infrastruktury IT może to być zapasowe centrum danych lub przeniesienie usług do chmury. W zakresie personelu istotne jest wyznaczenie i przeszkolenie zastępców kluczowych pracowników i możliwość pracy zdalnej. W relacjach z dostawcami warto zabezpieczyć alternatywne źródła dostaw lub utrzymywać zapas materiałów krytycznych. Każda strategia powinna być powiązana z konkretnymi procesami i parametrami ustalonymi w BIA, zwłaszcza z MTPD i RTO.
Ze strategii wynikają plany ciągłości działania (BCP, ang. Business Continuity Plan). Plan BCP to dokument operacyjny, który opisuje, kto odpowiada za poszczególne działania w sytuacji kryzysowej, w jakiej kolejności je realizować i jakie zasoby są do tego potrzebne. Dobry plan BCP zawiera też zasady komunikacji wewnętrznej i zewnętrznej: kogo powiadomić, w jakim terminie i jakim kanałem. Im bardziej konkretny jest plan, tym mniejsze ryzyko, że w sytuacji kryzysowej decyzje będą podejmowane chaotycznie.
Testowanie i utrzymanie BCMS
Plan ciągłości działania, który nie został przetestowany, daje pozorne poczucie bezpieczeństwa. Dopiero test pokazuje, czy procedury są wykonalne, czy zespół wie, co robić, i czy założone czasy przywrócenia procesów są realistyczne.
ISO 22301 wymaga regularnego testowania systemu, ale nie narzuca jednej metody. Najprostszą formą jest przegląd dokumentacji, który pozwala sprawdzić, czy plany są aktualne i spójne z bieżącą strukturą firmy. Kolejnym krokiem są warsztaty, na których zespół omawia hipotetyczny scenariusz zakłócenia i przechodzi przez procedury bez ich faktycznego uruchamiania. Można też przeprowadzić ćwiczenia symulacyjne, podczas których firma testuje reakcję na zakłócenie w warunkach zbliżonych do rzeczywistych.
Każdy test powinien kończyć się podsumowaniem, co zadziałało zgodnie z planem, co wymagało improwizacji, a gdzie pojawiły się luki. Te wnioski zasilają kolejny cykl PDCA i dają podstawy do aktualizacji planów i procedur. Norma wymaga też audytów wewnętrznych i przeglądów zarządzania, w których ocenia się dojrzałość całego systemu BCMS, nie tylko pojedynczych planów. Przegląd zarządzania to zadanie kierownictwa, które sprawdza, czy system ciągłości działania nadąża za zmianami w firmie i jej otoczeniu regulacyjnym.
Integracja ISO 22301 z innymi normami ISO
Wiele firm, które wdrażają ISO 22301, ma już system zarządzania bezpieczeństwem informacji zgodny z ISO 27001 lub korzysta z wytycznych ISO 31000 dotyczących zarządzania ryzykiem. Normy te można ze sobą integrować i w ten sposób nie powielać dokumentacji i procesów.
Integrację ułatwia wspólna struktura. ISO 22301 i ISO 27001 opierają się na tym samym schemacie klauzul (tzw. strukturze wysokiego poziomu), co oznacza, że wymagania dotyczące kontekstu firmy, zaangażowania kierownictwa, planowania, audytów wewnętrznych i doskonalenia mają w obu normach analogiczny układ. Firma, która przeszła już przez wdrożenie ISO 27001, ma gotowe elementy, które można rozszerzyć o wymagania ISO 22301. Chodzi tu np. o politykę zatwierdzoną przez kierownictwo, procedury audytów wewnętrznych, mechanizm przeglądów zarządzania czy rejestr ryzyk.
Są też obszary, w których obie normy się uzupełniają. ISO 27001 koncentruje się na ochronie poufności, integralności i dostępności informacji. ISO 22301 ma szerszy zakres i dotyczy zdolności do utrzymania kluczowych procesów biznesowych niezależnie od rodzaju zakłócenia. Analiza ryzyka przeprowadzona na potrzeby bezpieczeństwa informacji nie zastąpi BIA, ale może dostarczyć danych o zagrożeniach dla systemów IT, które warto uwzględnić przy planowaniu ciągłości.
ISO 31000 z kolei dostarcza ogólnych wytycznych dotyczących zarządzania ryzykiem, które mogą stanowić ramy metodyczne zarówno dla oceny ryzyka w ISO 22301, jak i w ISO 27001. Nie ma dla niej certyfikacji, ale jej wytyczne pomagają ujednolicić podejście do ryzyka w całej firmie.
Korzyści i dobre praktyki wdrożeniowe
Wdrożenie BCMS zgodnego z ISO 22301 daje firmie kilka wymiernych korzyści. Przede wszystkim zwiększa odporność operacyjną, bo wymusza systematyczne podejście do identyfikacji zagrożeń i przygotowania na nie. Organizacja, która przeprowadziła BIA, wyznaczyła strategie ciągłości i przetestowała swoje plany, reaguje na zakłócenia szybciej i bardziej przewidywalnie niż taka, która polega na improwizacji.
Formalny BCMS ułatwia też spełnienie wymagań regulacyjnych. NIS2 i DORA wymagają udokumentowanego zarządzania ciągłością działania, a system zgodny z ISO 22301 dostarcza dokumentacji i dowodów, których oczekują organy regulacyjne. Certyfikat bywa też argumentem w relacjach handlowych, zwłaszcza gdy kontrahent wymaga potwierdzenia, że dostawca jest przygotowany na zakłócenia.
Samo wdrożenie warto przeprowadzić według kilku zasad. Po pierwsze, zakres BCMS powinien być realistyczny. Lepiej zacząć od procesów faktycznie krytycznych i rozszerzać system stopniowo, niż próbować objąć nim całą firmę od razu. Po drugie, BIA i plany ciągłości muszą powstawać przy udziale właścicieli procesów, a nie w oderwaniu od ich codziennej pracy. Po trzecie, system wymaga regularnych testów i aktualizacji. BCMS, który został wdrożony, ale nie jest sprawdzany, traci wartość z każdym miesiącem, w którym firma się zmienia, a jej plany awaryjne pozostają takie same.
