Plan ciągłości działania —
wdrożyć, udokumentować, przetestować
Ustawa o krajowym systemie cyberbezpieczeństwa wymaga wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania, planów awaryjnych oraz planów odtworzenia działalności. Wynika to z art. 8 ust. 1 pkt 2 lit. f i dotyczy podmiotów kluczowych oraz ważnych. Przepis wymienia trzy różne dokumenty, bo odpowiadają na trzy różne momenty: jak działać dalej mimo zakłócenia, co zrobić natychmiast po zdarzeniu i jak odbudować system po stracie przekraczającej własne możliwości. Słowo „testowanie" jest w tym przepisie równie ważne jak „wdrażanie" — plan nieprzetestowany nie spełnia wymagania.
Rozróżnienie
Trzy plany, trzy różne momenty
Ustawa wymienia je osobno, więc audytor będzie szukał trzech zakresów — choć mogą być zawarte w jednym dokumencie.
| Plan | Odpowiada na pytanie | Zawartość |
|---|---|---|
| Plan ciągłości działania (BCP) | Jak świadczyć usługę mimo zakłócenia? | Procesy krytyczne, rozwiązania zastępcze, minimalne zasoby, role i ścieżki decyzyjne |
| Plan awaryjny | Co zrobić w pierwszych godzinach? | Procedury natychmiastowe, powiadamianie, zabezpieczenie dowodów, komunikacja wewnętrzna i zewnętrzna |
| Plan odtworzenia (DRP) | Jak odbudować system po stracie? | Kolejność odtwarzania, kopie zapasowe, parametry czasowe, zależności techniczne |
Podstawa
Analiza wpływu na działalność (BIA)
Identyfikacja procesów
Wypisz procesy realizowane przez organizację i wskaż te, których przerwanie najszybciej uderza w odbiorców usługi — mieszkańców, pacjentów, klientów.
Skutki przerwania w czasie
Dla każdego procesu oceń, co się stanie po godzinie, dniu i tygodniu przestoju: skutki prawne, finansowe, wizerunkowe i dla bezpieczeństwa ludzi.
Parametry czasowe
Ustal maksymalny akceptowalny czas przerwy i dopuszczalny zakres utraty danych. To te dwie wartości determinują wymagania wobec kopii zapasowych i rozwiązań zapasowych — a nie odwrotnie.
Zasoby minimalne
Określ, co jest niezbędne do uruchomienia procesu w trybie awaryjnym: ludzie, systemy, dane, dostawcy, lokalizacja.
Priorytety odtwarzania
Ułóż kolejność przywracania systemów wynikającą z zależności. Odtwarzanie systemu dziedzinowego przed uwierzytelnianiem i siecią nie ma sensu.
Testowanie
Plan, którego nikt nie sprawdził, nie istnieje
Ustawa wymaga testowania planów wprost. To wymaganie jest ignorowane najczęściej ze wszystkich i najłatwiej je zweryfikować podczas kontroli — wystarczy poprosić o protokół z ostatniego testu.
Testy można prowadzić na kilku poziomach, od najtańszego do najbardziej wiarygodnego:
Przegląd dokumentacji — sprawdzenie aktualności danych kontaktowych, ról i zależności. Minimum, które wykrywa najbardziej podstawowe błędy, na przykład numer telefonu osoby, która odeszła dwa lata temu.
Ćwiczenie sztabowe — omówienie scenariusza przy stole z osobami pełniącymi role w planie. Wykrywa luki decyzyjne i sprzeczne założenia, nie wymaga przerywania pracy.
Test techniczny — faktyczne odtworzenie systemu z kopii zapasowej w środowisku testowym. Jedyny sposób, by sprawdzić, czy kopie w ogóle działają i ile realnie trwa odtworzenie.
Z każdego testu powstaje protokół z wnioskami i listą poprawek do planu. To właśnie ten dokument, a nie sam plan, jest najmocniejszym dowodem spełnienia wymagania.
Częste błędy
Czego nie robić
Plan pisany pod audyt
Dokument powstał, bo wymagał go audytor, i nikt poza jego autorem go nie zna. W sytuacji kryzysowej nikt po niego nie sięgnie.
Kopie bez testu odtworzenia
Kopie zapasowe wykonują się poprawnie od lat, ale nigdy nie sprawdzono, czy da się z nich cokolwiek odtworzyć.
Parametry z sufitu
Deklarowany czas odtworzenia wynika z życzeń, a nie z testu. Przy prawdziwej awarii różnica bywa wielokrotna.
Brak wersji offline
Plan ciągłości działania dostępny wyłącznie w systemie, który właśnie przestał działać.
Pominięci dostawcy
Plan zakłada wsparcie dostawcy, ale umowa nie gwarantuje żadnego czasu reakcji.
Jednorazowy wysiłek
Plan sprzed pięciu lat opisujący systemy, których już nie ma, i ludzi, którzy już nie pracują.
Parametry
RTO i RPO — dwie liczby, które wyznaczają wszystko
Analiza wpływu na działalność kończy się dwiema wartościami dla każdego procesu krytycznego. To one decydują o kosztach rozwiązań technicznych, więc warto ustalić je świadomie, a nie przepisać z cudzego dokumentu.
RTO (Recovery Time Objective) to maksymalny akceptowalny czas przerwy — po jakim czasie proces musi znów działać, zanim skutki staną się nieakceptowalne. Dla obsługi interesantów w urzędzie może to być jeden dzień roboczy, dla systemu ratunkowego w szpitalu — minuty.
RPO (Recovery Point Objective) to dopuszczalna utrata danych wyrażona w czasie — ile godzin pracy organizacja jest w stanie odtworzyć ręcznie lub bezpowrotnie stracić. RPO wynoszące osiem godzin oznacza, że kopia wykonywana raz na dobę jest niewystarczająca.
Typowy błąd polega na deklarowaniu wartości ambitnych bez pokrycia w rozwiązaniach. Jeżeli plan mówi o czterech godzinach odtworzenia, a jedyny test odtworzenia trwał dwa dni, audytor zapisze niezgodność — i będzie miał rację, bo w kryzysie liczy się czas realny, nie deklarowany.
Druga strona tego samego błędu to przesada w drugą stronę: wyśrubowane parametry dla procesów, które spokojnie zniosą dobę przerwy, generują koszt infrastruktury bez żadnej korzyści.
Scenariusze
Cztery scenariusze, które trzeba opisać
Plan napisany ogólnie nie pomaga w kryzysie. Te cztery scenariusze pokrywają większość realnych zdarzeń w polskich organizacjach.
| Scenariusz | Co przestaje działać | Co musi być w planie |
|---|---|---|
| Ransomware | Systemy i dane zaszyfrowane, często razem z kopiami online | Odcięcie sieci, kopie offline lub niemodyfikowalne, kolejność odtwarzania, decyzja o zgłoszeniu do CSIRT i UODO |
| Awaria serwerowni | Infrastruktura w jednej lokalizacji: zasilanie, chłodzenie, sprzęt | Lokalizacja zapasowa lub tryb pracy ograniczonej, czas dostawy sprzętu, priorytety odtwarzania |
| Utrata dostępu do lokalizacji | Budynek niedostępny: pożar, zalanie, decyzja służb | Praca zdalna, dostęp do dokumentów papierowych, obsługa interesantów w trybie zastępczym |
| Awaria kluczowego dostawcy | System dziedzinowy, hosting lub łącze u dostawcy zewnętrznego | Ścieżka eskalacji, gwarantowany czas reakcji z umowy, tryb ręczny na czas przerwy |
Zawartość
Co musi znaleźć się w planie
Plan ciągłości działania, który przechodzi audyt i jednocześnie da się go użyć, zawiera:
- wykaz procesów krytycznych z parametrami czasowymi z analizy wpływu na działalność,
- role i zastępstwa — kto podejmuje decyzję o uruchomieniu planu i kto go zastępuje,
- dane kontaktowe osób, dostawców i służb, w wersji dostępnej bez firmowych systemów,
- procedury dla każdego scenariusza z konkretnymi krokami, nie ogólnymi zaleceniami,
- zasady komunikacji — kto informuje pracowników, odbiorców usługi i media,
- kryteria powrotu do normalnej pracy i tryb zamknięcia sytuacji kryzysowej,
- harmonogram testów wraz z miejscem na protokoły i wnioski.
Osobna uwaga o formie: plan musi być dostępny wtedy, gdy systemy nie działają. Wersja wyłącznie w intranecie albo w systemie, który właśnie padł, jest bezużyteczna. Praktyka to aktualny wydruk u osób pełniących role kryzysowe albo kopia na niezależnym nośniku.
W LYNX360
Ciągłość działania w systemie
Rejestr procesów krytycznych
Procesy z parametrami czasowymi i przypisanymi właścicielami.
Analiza wpływu na działalność
BIA prowadzona w systemie, powiązana z rejestrem ryzyk i zasobami.
Plany i wersje
Plany ciągłości, awaryjne i odtworzenia z historią zmian i datą ostatniego przeglądu.
Harmonogram testów
Terminy testów z przypomnieniami oraz miejsce na protokoły i wnioski.
Powiązanie z incydentami
Uruchomienie planu jest rejestrowane przy incydencie — powstaje realny materiał do wniosków.
Zgodność z ISO 22301
Struktura odpowiadająca wymaganiom normy zarządzania ciągłością działania.
Najczęściej zadawane pytania
FAQ
Czym różni się plan ciągłości działania od planu odtworzenia?
Plan ciągłości działania odpowiada na pytanie, jak świadczyć usługę mimo zakłócenia — opisuje rozwiązania zastępcze i minimalne zasoby. Plan odtworzenia dotyczy odbudowy systemu po zdarzeniu, które spowodowało straty przekraczające zdolność podmiotu do odbudowy własnymi środkami, i skupia się na kolejności przywracania, kopiach zapasowych i parametrach czasowych. Ustawa o krajowym systemie cyberbezpieczeństwa wymienia oba plany, a dodatkowo plan awaryjny.
Czy plan ciągłości działania trzeba testować?
Tak, wymaga tego wprost art. 8 ust. 1 pkt 2 lit. f ustawy o krajowym systemie cyberbezpieczeństwa, który mówi o wdrażaniu, dokumentowaniu, testowaniu i utrzymywaniu planów. Test może mieć formę przeglądu dokumentacji, ćwiczenia sztabowego albo faktycznego odtworzenia systemu z kopii — najważniejsze, by powstał protokół z wnioskami i poprawkami.
Jak często testować plany ciągłości działania?
Przepis nie wskazuje częstotliwości. Praktyką, która broni się przy kontroli, jest test co najmniej raz w roku oraz dodatkowo po każdej istotnej zmianie w systemach lub organizacji. Warto powiązać cykl testów z rocznym audytem bezpieczeństwa informacji.
Czym jest analiza wpływu na działalność (BIA)?
To ustalenie, które procesy są krytyczne i jak szybko ich przerwanie zaczyna szkodzić organizacji i odbiorcom usługi. Wynikiem BIA są dwa parametry: maksymalny akceptowalny czas przerwy oraz dopuszczalny zakres utraty danych. To one wyznaczają wymagania wobec kopii zapasowych i rozwiązań zapasowych — bez BIA te wymagania są zgadywane.
Czy kopie zapasowe wystarczą zamiast planu ciągłości działania?
Nie. Kopie zapasowe są jednym ze środków, ale nie odpowiadają na pytanie, jak organizacja ma działać w czasie przestoju, kto podejmuje decyzje, jak komunikuje się z odbiorcami usługi i w jakiej kolejności przywraca systemy. Kopia bez przetestowanego odtworzenia bywa zresztą złudzeniem bezpieczeństwa.
Powiązane tematy
Czytaj dalej
Aplikacja SZBI
Ryzyko, ciągłość działania i incydenty w jednym systemie.
Zarządzanie incydentami
Rejestr incydentów z terminami 24h i 72h.
LYNX360 dla szpitali
Ciągłość działania systemów medycznych i danych pacjentów.
Ostatni przegląd treści: