Czy Twoja firma przetrwa kryzys? Plan ciągłości działania według ISO 22301

Większość firm wie, że powinna być przygotowana na sytuacje kryzysowe. Niewielu ma jednak udokumentowany, przetestowany i realnie działający plan ciągłości biznesu. ISO 22301 to norma, która zmienia deklaracje w system – i pozwala odpowiedzieć na pytanie o przetrwanie nie intuicją, lecz konkretnym planem.

Plan ciągłości działania – co musi zawierać i jak go zbudować

Plan ciągłości działania (Business Continuity Plan – BCP) jest centralnym dokumentem systemu zarządzania ciągłością biznesu. ISO 22301 precyzuje, jakie elementy musi zawierać, aby był skuteczny – nie tylko jako dokument, ale jako rzeczywiste narzędzie zarządzania kryzysem.

Punktem wyjścia jest analiza wpływu na działalność (BIA), która identyfikuje procesy krytyczne dla przeżycia organizacji i określa maksymalny dopuszczalny czas ich przerwy (RTO) oraz maksymalną dopuszczalną utratę danych (RPO). BIA jest podstawą całej strategii – bez niej plan ciągłości jest zbiorem intuicji, a nie systemem opartym na danych.

Na podstawie wyników BIA opracowuje się strategie ciągłości – alternatywne sposoby realizacji krytycznych procesów podczas incydentu. Mogą to być rozwiązania techniczne (zapasowe centrum danych, backup w chmurze, redundancja systemów), organizacyjne (praca zdalna, przejęcie funkcji przez inny oddział, outsourcing awaryjny) lub kombinacja obu. Norma nie narzuca konkretnych rozwiązań – wymaga natomiast, aby strategie były adekwatne do zidentyfikowanych zagrożeń i celów RTO/RPO.

Sam plan BCP musi zawierać: procedury uruchomienia planu (kto decyduje, kiedy i na jakiej podstawie), role i odpowiedzialności kluczowego personelu, procedury komunikacji wewnętrznej i zewnętrznej podczas incydentu (w tym zasady informowania klientów, partnerów i mediów), procedury odtwarzania krytycznych procesów w kolejności priorytetów, a także procedury powrotu do normalnej działalności po zakończeniu incydentu.

Kluczowym wymaganiem ISO 22301, które odróżnia ją od zwykłego tworzenia dokumentów, jest testowanie planów. Norma wymaga regularnych ćwiczeń i symulacji – od prostych ćwiczeń przy biurku (table-top exercises), przez symulacje funkcjonalne, po pełne testy awaryjne angażujące rzeczywistą infrastrukturę. Wyniki testów muszą być analizowane, a plany aktualizowane na ich podstawie. Plan, który nigdy nie był testowany, jest planem, który nie zadziała w momencie kryzysu.

Najczęstsze błędy przy budowaniu systemu ciągłości działania

Firmy budujące system zarządzania ciągłością działania po raz pierwszy popełniają podobne błędy. Ich znajomość pozwala uniknąć kosztownych poprawek i przyspiesza drogę do skutecznej certyfikacji.

• BIA wykonana jednorazowo i nieaktualizowana – analiza wpływu na działalność odzwierciedla stan organizacji w momencie jej przeprowadzenia. Zmiany w strukturze, procesach, systemach IT i kluczowych dostawcach muszą być odzwierciedlone w aktualizacji BIA. Norma wymaga regularnego przeglądu wszystkich elementów systemu.
• Plany znane tylko działowi IT – ciągłość działania nie jest wyłącznie problemem technicznym. Plany muszą obejmować wszystkie krytyczne funkcje biznesowe i być znane kluczowemu personelowi z każdego działu. Pracownicy, którzy nigdy nie zapoznali się z planem, nie będą w stanie go realizować w stresie kryzysowym.
• Brak zdefiniowanego progu aktywacji planu – plan ciągłości działania musi zawierać jasne kryteria jego uruchomienia. Jeśli decyzja o aktywacji planu zależy od subiektywnej oceny sytuacji, w kryzysie może dojść do opóźnienia lub braku reakcji. ISO 22301 wymaga udokumentowanych procedur zarządzania incydentami, w tym kryteriów eskalacji i aktywacji BCP.
• Plany odtwarzania IT bez planów procesów biznesowych – odtworzenie systemu informatycznego nie oznacza odtworzenia procesu biznesowego. Plan musi opisywać nie tylko jak przywrócić system, ale jak organizacja funkcjonuje podczas przerwy i kto wykonuje które zadania w trybie awaryjnym.
• Brak testów lub testy wyłącznie na papierze – to najczęstszy i najpoważniejszy błąd. Ćwiczenia przy biurku (table-top) są cenne, ale nie zastępują testów angażujących rzeczywiste systemy i personel. Norma wymaga udokumentowania programu testów i jego realizacji, a audytorzy weryfikują zarówno fakty przeprowadzenia testów, jak i to, czy ich wyniki były analizowane i wdrażane.