Plan ciągłości działania - wzór i przykład wypełnienia
Plan ciągłości działania (BCP) opisuje, jak firma utrzyma albo szybko przywróci najważniejsze usługi po zdarzeniu, które je przerywa: awarii systemu, ataku ransomware, pożarze czy utracie dostawcy. Dyrektywa NIS2 wymienia ciągłość działania, w tym zarządzanie kopiami zapasowymi, przywracanie normalnego działania i zarządzanie kryzysowe, wśród minimalnych środków (art. 21 ust. 2 lit. c), a ustawa o krajowym systemie cyberbezpieczeństwa wymaga wdrażania, dokumentowania, testowania i utrzymywania takich planów.
Przygotował: Ireneusz Kozera, audytor wiodący ISOStan prawny na: Następny przegląd: Licencja CC BY 4.0
Plan ciągłości działania, plan awaryjny i plan odtworzenia
Art. 8 ust. 1 pkt 2 lit. f ustawy o krajowym systemie cyberbezpieczeństwa w brzmieniu z nowelizacji z 23 stycznia 2026 r. (Dz.U. 2026 poz. 252) wymienia trzy rodzaje planów. Plany ciągłości działania mają umożliwiać ciągłe i niezakłócone świadczenie usługi i zapewniać poufność, integralność, dostępność i autentyczność informacji. Obok nich ustawa wymienia plany awaryjne oraz plany odtworzenia działalności, które pozwalają odtworzyć system informacyjny po zdarzeniu, które spowodowało straty przekraczające zdolności podmiotu do odbudowy własnymi środkami.
Plan ciągłości działania - wzór na tej stronie łączy te trzy elementy w jednym dokumencie z rozdziałami, co ułatwia utrzymanie w małej i średniej firmie. Większa organizacja może prowadzić je osobno, pod warunkiem że role, kontakty i priorytety usług są wszędzie te same.
| Plan | Na jakie pytanie odpowiada | Przykład zawartości |
|---|---|---|
| Plan ciągłości działania | Jak utrzymać usługę albo wrócić do niej w ustalonym czasie | Usługi krytyczne, czasy odtworzenia, obejścia ręczne, zespół kryzysowy |
| Plan awaryjny | Co robimy w pierwszych godzinach konkretnego zdarzenia | Scenariusze: ransomware, awaria serwerowni, utrata łącza, niedostępność dostawcy |
| Plan odtworzenia działalności | Jak odbudować systemy po dużej stracie, której nie da się usunąć własnymi zasobami | Kolejność odtwarzania, zasoby zastępcze, umowy z dostawcami, kopie poza główną lokalizacją |
Analiza wpływu na działalność przed planem
Plan zaczyna się od pytania, które usługi są krytyczne i jak długo firma może się bez nich obyć. Norma ISO 22301, która określa wymagania dla systemu zarządzania ciągłością działania, przewiduje analizę wpływu na działalność (BIA) i ocenę ryzyka jako podstawę strategii i planów. Ustawa o KSC wymaga z kolei systematycznego szacowania ryzyka incydentu i środków proporcjonalnych do tego ryzyka (art. 8 ust. 1 pkt 1 i 2).
Dla każdej usługi krytycznej ustala się dwa czasy: czas, w jakim usługa ma wrócić (RTO), i dopuszczalną utratę danych liczoną od ostatniej kopii (RPO). Od nich zależy wszystko dalej: jak często robić kopie zapasowe, czy potrzebna jest zapasowa lokalizacja i których dostawców trzeba objąć planem. Czasy ustala się z właścicielami usług i z klientami, a nie z samym działem IT.
Wzór planu ciągłości działania (struktura do wypełnienia)
To szablon struktury. Treść musi opisywać Twoją firmę, nie zakład wzorcowy.
| Nr | Pole | Co wpisać | Podstawa |
|---|---|---|---|
| 1 | Zakres planu i usługi krytyczne | Które usługi, systemy i lokalizacje obejmuje plan, w kolejności ważności dla klientów. | art. 8 ust. 1 pkt 2 lit. f ustawy o KSC |
| 2 | Właściciel planu i zespół kryzysowy | Kto uruchamia plan, kto kieruje działaniami, kto komunikuje się z klientami, z zastępcami i aktualnymi kontaktami. | |
| 3 | Wyniki analizy wpływu: RTO i RPO | Dla każdej usługi krytycznej czas przywrócenia i dopuszczalna utrata danych, uzgodnione z właścicielami usług. | art. 8 ust. 1 pkt 1 ustawy o KSC (szacowanie ryzyka) |
| 4 | Scenariusze zakłóceń | Zdarzenia, dla których plan ma gotowe działania, wybrane na podstawie szacowania ryzyka. | art. 21 ust. 2 NIS2 (podejście uwzględniające wszystkie zagrożenia) |
| 5 | Kryteria uruchomienia planu i eskalacja | Kiedy zdarzenie staje się sytuacją kryzysową i kto o tym decyduje. | |
| 6 | Komunikacja kryzysowa | Kto, kogo i jakim kanałem informuje: pracowników, klientów, dostawców, a w podmiocie kluczowym lub ważnym także właściwe organy według ustawy o KSC. | art. 21 ust. 2 lit. c i j NIS2 |
| 7 | Procedury przywracania | Kolejność odtwarzania systemów i odsyłacze do instrukcji technicznych. | art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (plany odtworzenia) |
| 8 | Kopie zapasowe | Co, jak często i gdzie jest kopiowane, jak kopie są chronione i jak sprawdza się odtwarzanie. | art. 21 ust. 2 lit. c NIS2 |
| 9 | Zasoby zastępcze i dostawcy | Zapasowa lokalizacja, sprzęt, łącza i umowy z dostawcami, od których zależy przywrócenie usług. | art. 21 ust. 2 lit. d NIS2; art. 8 ust. 1 pkt 2 lit. e ustawy o KSC |
| 10 | Testy i ćwiczenia | Jakie testy, jak często, kto je prowadzi i gdzie zapisuje się wyniki oraz wnioski. | art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (testowanie) |
| 11 | Przegląd i aktualizacja | Kiedy plan jest przeglądany i kto zatwierdza zmiany. Zmiany systemów, dostawców i osób wymagają aktualizacji kontaktów i procedur. | art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (utrzymywanie) |
Przykład wypełnienia: firma usług IT i hostingu
Przykład sp. z o.o. to fikcyjna firma, która zarządza infrastrukturą IT klientów i świadczy usługi hostingu. Czasy RTO i RPO oraz częstotliwości testów są przykładowe - własne ustala się z analizy wpływu na działalność i z umów z klientami.
| Pole | Przykład wypełnienia |
|---|---|
| 1. Zakres planu i usługi krytyczne | Hosting aplikacji klientów (krytyczna), poczta firmowa klientów (krytyczna), helpdesk (ważna), system fakturowania (wspierająca) |
| 2. Właściciel planu i zespół kryzysowy | Właściciel: dyrektor operacyjny. Zespół: kierownik infrastruktury (lider techniczny), kierownik helpdesku (komunikacja z klientami), prezes (decyzje biznesowe); zastępcy wskazani dla każdej roli |
| 3. Wyniki analizy wpływu: RTO i RPO | Hosting: RTO 4 godziny, RPO 1 godzina; poczta: RTO 8 godzin, RPO 4 godziny; fakturowanie: RTO 3 dni, RPO 24 godziny |
| 4. Scenariusze zakłóceń | Zaszyfrowanie serwerów przez ransomware; awaria zasilania w serwerowni; utrata łącza do kolokacji; niedostępność kluczowego dostawcy chmury |
| 5. Kryteria uruchomienia planu i eskalacja | Plan uruchamia lider techniczny, gdy usługa krytyczna jest niedostępna dłużej niż 30 minut albo zachodzi podejrzenie ataku; informuje właściciela planu w ciągu 15 minut |
| 6. Komunikacja kryzysowa | Komunikat do klientów na stronie statusu i e-mailem co 2 godziny; zapasowy kanał komunikacji zespołu poza firmową pocztą; ocena obowiązku zgłoszenia incydentu przez pełnomocnika ds. bezpieczeństwa |
| 7. Procedury przywracania | 1. sieć i tożsamość, 2. hosting aplikacji, 3. poczta, 4. helpdesk, 5. fakturowanie; instrukcje IT-REC-01 do IT-REC-05 |
| 8. Kopie zapasowe | Kopie co godzinę dla hostingu, codziennie dla pozostałych systemów; kopia niezmienialna w drugiej lokalizacji; test odtworzenia jednego systemu co miesiąc |
| 9. Zasoby zastępcze i dostawcy | Zapasowe środowisko u drugiego dostawcy kolokacji; umowa serwisowa z czasem reakcji 4 godziny; lista kontaktów awaryjnych dostawców |
| 10. Testy i ćwiczenia | Omówienie scenariusza ransomware przy stole - co pół roku; pełne przełączenie hostingu na zapasowe środowisko - raz w roku; raport z wnioskami do zarządu |
| 11. Przegląd i aktualizacja | Przegląd raz w roku i po każdym teście, incydencie albo zmianie dostawcy; zatwierdza zarząd. Wydanie 1 z 15.01.2027 |
Testy planu i kopie zapasowe
Ustawa wymaga planów testowanych i utrzymywanych, a nie tylko spisanych. Art. 8 nie podaje częstotliwości testów, więc ustala się ją w samym planie, zależnie od ryzyka i zmian w systemach. Test może mieć różną skalę: omówienie scenariusza przy stole z zespołem kryzysowym, odtworzenie jednego systemu z kopii w środowisku testowym albo pełne ćwiczenie z przełączeniem na zasoby zastępcze.
Kopie zapasowe są częścią ciągłości działania według art. 21 ust. 2 lit. c NIS2. Plan powinien mówić, które dane i systemy są kopiowane, jak często (zgodnie z RPO), gdzie przechowuje się kopie, jak chroni się je przed zaszyfrowaniem razem z systemem produkcyjnym i jak sprawdza się, że da się z nich odtworzyć dane. Wynik każdego testu odtworzenia zapisuje się razem z czasem, jaki zajął.
ISO 22301 jest normą wymagań, według której można certyfikować system zarządzania ciągłością działania. Obecne wydanie ISO opublikowała w październiku 2019 r. Plan ciągłości działania może być częścią takiego systemu albo systemu bezpieczeństwa informacji według ISO/IEC 27001.
Czego unikać przy wypełnianiu wzoru
Plan bez analizy wpływu i szacowania ryzyka
- Skutek
- Priorytety usług i czasy odtworzenia są przypadkowe, a środki nie odpowiadają ryzyku.
- Jak uniknąć
- Zanim napiszesz procedury, ustal z właścicielami usług RTO, RPO i najważniejsze scenariusze.
- Podstawa
- art. 8 ust. 1 pkt 1 i 2 ustawy o KSC; art. 21 ust. 1 NIS2
Plan, którego nikt nie testował
- Skutek
- Luki, np. brak haseł do konsoli zapasowej albo nieaktualny numer dostawcy, wychodzą dopiero w czasie prawdziwego zdarzenia.
- Jak uniknąć
- Zaplanuj testy różnej skali i zapisuj wyniki oraz wnioski.
- Podstawa
- art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (testowanie planów)
Kopie zapasowe bez sprawdzania odtwarzania
- Skutek
- Firma ma kopie, ale nie wie, czy da się z nich odtworzyć dane w czasie zgodnym z RTO.
- Jak uniknąć
- Regularnie odtwarzaj wybrane systemy z kopii i mierz czas.
- Podstawa
- art. 21 ust. 2 lit. c NIS2
Brak planu odtworzenia po dużej stracie
- Skutek
- Plan opisuje drobne awarie, ale nie mówi, co zrobić, gdy zniszczona jest cała lokalizacja albo wszystkie systemy są zaszyfrowane.
- Jak uniknąć
- Dodaj rozdział o odtworzeniu działalności z zasobów zastępczych i umów z dostawcami.
- Podstawa
- art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (plany odtworzenia działalności)
Pominięcie dostawców ICT
- Skutek
- Przywrócenie usługi zależy od dostawcy, którego plan nie obejmuje ani umowa nie zobowiązuje do wsparcia.
- Jak uniknąć
- Wpisz kluczowych dostawców do planu i sprawdź ich zobowiązania w umowach.
- Podstawa
- art. 21 ust. 2 lit. d NIS2; art. 8 ust. 1 pkt 2 lit. e ustawy o KSC
Nieaktualne role i kontakty
- Skutek
- W czasie zdarzenia zespół traci czas na szukanie osób, które odeszły z firmy albo zmieniły funkcję.
- Jak uniknąć
- Aktualizuj plan przy każdej zmianie kadrowej i sprawdzaj kontakty przy każdym teście.
- Podstawa
- art. 8 ust. 1 pkt 2 lit. f ustawy o KSC (utrzymywanie planów)
Kiedy wzór nie wystarczy
- firma jest podmiotem kluczowym albo ważnym i musi wykazać plany ciągłości, plany awaryjne i plany odtworzenia
- usługi zależą od kilku dostawców chmury i trzeba ustalić realne czasy odtworzenia
- plan ma być częścią systemu ISO/IEC 27001 albo certyfikacji ISO 22301
- po incydencie, który pokazał, że plan nie działał w praktyce
Najczęstsze pytania
Czy plan ciągłości działania jest obowiązkowy?
Dla podmiotów kluczowych i ważnych tak: ustawa o krajowym systemie cyberbezpieczeństwa wymaga wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania, planów awaryjnych i planów odtworzenia (art. 8 ust. 1 pkt 2 lit. f). Dla innych firm plan jest dobrowolny, ale często wymagają go klienci i normy systemów zarządzania.
Czym różni się plan ciągłości działania od planu odtworzenia po awarii?
Plan ciągłości działania obejmuje całą firmę: usługi, ludzi, lokalizacje, dostawców i komunikację. Plan odtworzenia skupia się na odbudowie systemów po dużej stracie. Ustawa o KSC wymienia oba rodzaje planów obok siebie.
Jak często testować plan ciągłości działania?
Art. 8 ustawy o KSC wymaga testowania, ale nie podaje częstotliwości. Ustal ją w planie na podstawie ryzyka i zmian w systemach, a po każdym teście zapisz wyniki i wnioski.
Co to są RTO i RPO?
RTO to czas, w jakim usługa ma wrócić do działania po zakłóceniu. RPO to dopuszczalna utrata danych liczona od ostatniej kopii zapasowej. Oba ustala się dla każdej usługi krytycznej w analizie wpływu na działalność.