plan ciągłości działania

Plan ciągłości działania (BCP, business continuity plan) to według polskiego słownika NSC 7298 dokumentacja zawierająca zawczasu przygotowany zestaw instrukcji i procedur, które opisują, jak będą realizowane zadania organizacji podczas znacznych zakłóceń i jak przywrócić stan sprzed zakłócenia ^[1]. NIST definiuje go podobnie: jako opis tego, jak procesy biznesowe organizacji zostaną utrzymane w trakcie poważnego zakłócenia i po nim ^[3]. Plan nie dotyczy jednego serwera, tylko pracy całej firmy: sprzedaży, obsługi klienta, płac. Jego techniczną częścią jest disaster recovery (DR).

Jak powstaje

Przewodnik NIST SP 800-34 opisuje siedmiostopniowy proces planowania awaryjnego ^[2]:

1. przyjęcie polityki planowania awaryjnego;
2. analiza wpływu na działalność (BIA), która wskazuje i szereguje systemy krytyczne dla procesów biznesowych;
3. wskazanie środków zapobiegawczych, które zmniejszają skutki przerw;
4. opracowanie strategii odtwarzania;
5. napisanie planu z procedurami przywracania;
6. testy, szkolenia i ćwiczenia;
7. utrzymanie planu jako żywego dokumentu, aktualizowanego wraz ze zmianami w systemach i organizacji ^[2].

Rdzeń tego procesu pokazuje schemat poniżej.

RYS. 1Od analizy do działającego planu

W analizie wpływu ustala się dla każdego procesu dopuszczalny czas przestoju i dopuszczalną utratę danych, czyli RTO i RPO. Plan bez tych liczb nie mówi, co odtwarzać najpierw.

Plan ciągłości a inne plany

SP 800-34 zaznacza, że planowanie ciągłości i planowanie awaryjne są często mylone. Planowanie ciągłości dotyczy samej działalności i zdolności do kontynuowania krytycznych funkcji, a planowanie awaryjne dotyczy systemów informatycznych ^[2]. Przewodnik opisuje kilka rodzajów planów, które razem tworzą pakiet przygotowań na wypadek zakłóceń.

Plan reagowania na incydent opisuje reagowanie na incydenty: wykrycie, ograniczenie i usunięcie skutków ataku. Plan ciągłości odpowiada na inne pytanie: jak firma ma działać, zanim systemy wrócą.

Kogo dotyczy

W Polsce obowiązek wynika z ustawy o krajowym systemie cyberbezpieczeństwa (KSC). Po nowelizacji z 23 stycznia 2026 roku art. 8 wymaga od podmiotu kluczowego i ważnego, w ramach systemu zarządzania bezpieczeństwem informacji (SZBI), wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania oraz planów awaryjnych i planów odtworzenia działalności ^[4]. Ustawa wdraża dyrektywę NIS2 ^[4].

Rozporządzenie wykonawcze 2024/2690, wydane do NIS2 dla m.in. dostawców usług chmurowych, usług zarządzanych i platform handlowych, wymienia elementy takiego planu ^[6]:

• cel, zakres i odbiorców;
• funkcje i obowiązki;
• kluczowe osoby do kontaktu i kanały komunikacji;
• warunki aktywacji i dezaktywacji planu;
• kolejność przywracania działalności;
• wymagane zasoby, w tym kopie zapasowe i redundancje ^[6].

Plan ma opierać się na wynikach szacowania ryzyka i być testowany oraz aktualizowany po poważnych incydentach ^[6].

Sektor finansowy ma osobne przepisy. DORA nakazuje wprowadzać, utrzymywać i okresowo testować plany ciągłości działania w zakresie ICT ^[5]. Testy mają się odbywać co najmniej raz w roku oraz po istotnych zmianach w systemach wspierających krytyczne funkcje ^[5].

W WordPressie

Dla sklepu albo serwisu na WordPressie plan ciągłości odpowiada na proste pytania. Kto decyduje o przełączeniu strony w tryb awaryjny? Jak klienci składają zamówienia, gdy sklep nie działa? Gdzie leży kopia i kto potrafi ją odtworzyć?

Podstawą jest kopia zapasowa (backup). Dokumentacja WordPressa przypomina, że pełne odtworzenie wymaga dwóch części: bazy danych i plików ^[7]. Zaleca trzymanie co najmniej 3–5 ostatnich kopii w różnych miejscach, na przykład na serwerze, w chmurze i na komputerze lokalnym ^[7]. Radzi też, by nie polegać wyłącznie na kopiach dostawcy hostingu, bo uzyskanie kopii od firmy hostingowej zajmuje czas, a szybkie odtworzenie jest krytyczne ^[7].

W planie warto zapisać zależności strony od dostawców: hostingu, domeny, bramki płatności, poczty i twórców kluczowych wtyczek. Awaria jednego z nich może zatrzymać sprzedaż tak samo jak włamanie. Oceną takich zależności zajmuje się zarządzanie ryzykiem dostawców (TPRM).

Dobre praktyki

• Zacząć od analizy wpływu i ustalić RTO oraz RPO dla każdego procesu, a nie dla „strony” jako całości ^[2].
• Zapisać role, dane kontaktowe i warunki uruchomienia planu, tak jak wymienia je rozporządzenie 2024/2690 ^[6].
• Ćwiczyć plan. SP 800-34 wymienia ćwiczenia sztabowe, czyli tabletop exercise, w których uczestnicy omawiają scenariusz przy stole, oraz ćwiczenia funkcjonalne, w których wykonują swoje zadania w symulowanym środowisku ^[2].
• Sprawdzać odtwarzanie kopii na środowisku testowym (staging). Dokumentacja WordPressa zaleca, by automatyczne kopie od czasu do czasu uzupełnić kopią ręczną i upewnić się, że proces działa ^[7].
• Uwzględnić scenariusz ransomware, w którym zaszyfrowane są jednocześnie serwer i dostępne z niego kopie.

Historia i przykłady

SP 800-34 Rev. 1 ukazał się w maju 2010 roku ^[2]. Polski słownik NSC 7298 w wersji 1.0 z 1 września 2021 roku ujednolicił przekład: „Business Continuity Plan” to „plan ciągłości działania”, a „Disaster Recovery Plan” to „plan odtworzenia po katastrofie” ^[1]. Ustawę nowelizującą KSC, która wprowadziła obecne brzmienie art. 8, ogłoszono w Dzienniku Ustaw 2 marca 2026 roku jako poz. 252 ^[4].