Plan ciągłości działania (BCP) i plan odtwarzania po awarii (DRP): co wpisać i czego wymaga NIS2

Plan ciągłości działania (business continuity plan, BCP) mówi, jak organizacja utrzymuje najważniejsze usługi, gdy coś przestaje działać. Plan odtwarzania po awarii (disaster recovery plan, DRP) mówi, jak przywrócić systemy informatyczne i dane do stanu sprzed zdarzenia. Ustawa o krajowym systemie cyberbezpieczeństwa wymaga od podmiotów kluczowych i ważnych obu dokumentów: w art. 8 ust. 1 pkt 2 lit. f wymienia wdrażanie, dokumentowanie, testowanie i utrzymywanie planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności. Poniżej: definicje, struktura dokumentu, testy i podstawy prawne według stanu z 2026 r.

Czym różni się BCP od DRP

BCP mówi, jak dalej świadczyć usługę, gdy brakuje systemu, budynku, ludzi albo dostawcy. DRP mówi, jak odbudować infrastrukturę IT i dane, i jest w dużej mierze dokumentem technicznym.

Ustawa o KSC opisuje plan odtworzenia działalności jako plan umożliwiający odtworzenie systemu informacyjnego „po zdarzeniu, które spowodowało straty przekraczające zdolności podmiotu do odbudowy za pomocą własnych środków” (art. 8 ust. 1 pkt 2 lit. f). DRP ma więc działać także wtedy, gdy zwykłe procedury administratora nie wystarczają.

Oba plany należą do jednej całości. Normy ISO nazywają ją systemem zarządzania ciągłością działania (BCMS). Wymagania dla takiego systemu zawiera ISO 22301:2019, a ISO/IEC 27031:2025 opisuje gotowość ICT na potrzeby ciągłości działania, czyli obszar, który w praktyce pokrywa DRP. Obie normy są dobrowolne. Ani ustawa o KSC, ani NIS2 nie wymagają certyfikacji na zgodność z nimi.

Pojęcia, które trzeba znać: BIA, RTO, RPO, MTPD

Każdy plan ciągłości działania opiera się na analizie wpływu i kilku miarach czasu. Definicje MTPD, RTO i RPO podajemy w omówieniu własnym za słownikiem ISO 22300:2025:

• BIA (business impact analysis), analiza wpływu na działalność. Proces oceny, co się stanie, gdy dana usługa lub czynność zostanie przerwana: jakie straty finansowe, prawne, wizerunkowe i operacyjne pojawią się po godzinie, dniu, tygodniu. Z BIA wynikają trzy pozostałe wartości.
• MTPD (maximum tolerable period of disruption), czasem MTD. Czas, po którym skutki braku produktu, usługi lub czynności stają się nie do przyjęcia.
• RTO (recovery time objective). Czas, w którym trzeba wznowić czynność na określonym minimalnym poziomie. RTO musi być krótsze niż MTPD.
• RPO (recovery point objective). Punkt, do którego trzeba odtworzyć informacje i dane, żeby czynność mogła działać po wznowieniu. W praktyce: ile danych z ostatnich godzin można stracić.

Przykład (fikcyjny): gabinet lekarski ustala w BIA, że bez systemu rejestracji wytrzyma najwyżej dwa dni robocze (MTPD), przez które będzie zapisywał pacjentów na papierowych listach. Ustala więc RTO systemu na jeden dzień roboczy, a RPO na cztery godziny. Z tego wynika, że kopia zapasowa raz na dobę nie wystarczy.

Rozporządzenie wykonawcze Komisji (UE) 2024/2690 również wymaga przeprowadzenia BIA i ustalenia na jej podstawie wymogów ciągłości dla systemów (pkt 4.1.3 załącznika).

Czego wymagają NIS2, ustawa o KSC i RODO

NIS2: art. 21 ust. 2 lit. c

Dyrektywa NIS2 wymienia w art. 21 ust. 2 minimalne elementy środków zarządzania ryzykiem. Lit. c brzmi: „ciągłość działania, np. zarządzanie kopiami zapasowymi i przywracanie normalnego działania po wystąpieniu sytuacji nadzwyczajnej, i zarządzanie kryzysowe”. Ten jeden przepis obejmuje BCP, kopie zapasowe z DRP i zarządzanie kryzysowe.

Ustawa o KSC: art. 8 ust. 1 pkt 2 lit. f i art. 10

Polska ustawa (w brzmieniu nadanym nowelizacją z 23 stycznia 2026 r., Dz.U. 2026 poz. 252) przenosi ten wymóg do systemu zarządzania bezpieczeństwem informacji. Art. 8 ust. 1 pkt 2 lit. f obejmuje:

1. wdrażanie, dokumentowanie, testowanie i utrzymywanie planów ciągłości działania, które umożliwiają ciągłe i niezakłócone świadczenie usługi oraz zapewniają poufność, integralność, dostępność i autentyczność informacji,
2. plany awaryjne,
3. plany odtworzenia działalności, które umożliwiają odtworzenie systemu informacyjnego po zdarzeniu przekraczającym zdolności podmiotu do odbudowy własnymi środkami.

Sam dokument nie wystarcza, bo ustawa mówi też o testowaniu i utrzymywaniu. Art. 10 ust. 3 pkt 3 zalicza „dokumentację systemu zarządzania ciągłością działania” do dokumentacji normatywnej. Z kolei art. 10 ust. 4 wymaga dokumentacji operacyjnej, czyli zapisów, że czynności z dokumentacji normatywnej faktycznie wykonano. Protokół z testu odtworzenia jest właśnie takim zapisem. Miejsce tych dokumentów w całym systemie opisujemy w artykule o SZBI i polityce bezpieczeństwa informacji.

Podmiot ważny będący podmiotem publicznym, np. wiele jednostek samorządu, nie stosuje art. 8 ust. 1, tylko wymogi z załącznika nr 4 do ustawy (art. 8 ust. 3). Ten załącznik w części I wymaga m.in. wykonywania kopii zapasowych odseparowanych logicznie i fizycznie (pkt 10), testowania kompletności i możliwości odtworzenia danych z kopii (pkt 11) oraz przygotowania i testowania procedury na wypadek awarii lub incydentu (pkt 12).

W razie incydentu krytycznego minister właściwy do spraw informatyzacji może też poleceniem zabezpieczającym nakazać przegląd tych planów pod kątem danej podatności (art. 67g ust. 10 pkt 2).

Za wykonanie obowiązków z art. 8 odpowiada kierownik podmiotu (art. 8c), także wtedy, gdy powierzył je innej osobie. Jeśli nie wiesz jeszcze, czy Twoja organizacja jest podmiotem kluczowym lub ważnym, zacznij od artykułu NIS2 i ustawa o KSC: kogo dotyczy.

Dostawcy usług cyfrowych: rozporządzenie 2024/2690

Dostawcy usług DNS, chmurowych, centrów przetwarzania danych, usług zarządzanych i kilku innych kategorii stosują wprost rozporządzenie 2024/2690 (art. 8b ust. 1 ustawy o KSC). Pkt 4 jego załącznika wylicza elementy planu ciągłości, kopii zapasowych i zarządzania kryzysowego. Dla innych organizacji to dobry szkielet dokumentu i korzystamy z niego niżej.

RODO: art. 32 ust. 1 lit. b i c

Jeśli w systemach są dane osobowe, ciągłości działania wymaga też RODO. Art. 32 ust. 1 lit. b mówi o zdolności do ciągłego zapewnienia poufności, integralności, dostępności i odporności systemów i usług przetwarzania. Lit. c dotyczy zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego. Lit. d dodaje regularne testowanie skuteczności środków. Jak to sprawdzić, opisuje przewodnik audyt RODO krok po kroku.

Dla sektora finansowego osobne wymogi ma DORA: art. 11 rozporządzenia 2022/2554 nakłada obowiązek strategii ciągłości działania w zakresie ICT, testowanych planów i analizy wpływu na działalność. Omawiamy je w tekście DORA: rozporządzenie i wymogi.

art. 8 ust. 1 pkt 2 lit. f

przepis ustawy o KSC o planach ciągłości działania, planach awaryjnych i planach odtworzenia działalności

Dz.U. 2026 poz. 252

3.04.2027

termin wdrożenia obowiązków z rozdziału 3 dla podmiotów objętych ustawą od jej wejścia w życie

Art. 33 ust. 1 ustawy z 23.01.2026

2 lata

minimalny okres przechowywania dokumentacji bezpieczeństwa od jej wycofania z użytkowania

Art. 10 ust. 7 ustawy o KSC

300%

wynagrodzenia: górna granica kary dla kierownika podmiotu za niewykonanie obowiązków z art. 8; pierwsze kary od 3.04.2028

Art. 73a ust. 1 pkt 2 i ust. 4 ustawy o KSC, art. 35 ustawy z 23.01.2026

Jak napisać plan ciągłości działania krok po kroku

Kroki zakładają, że organizacja ma już wstępną analizę ryzyka; jak ją przygotować, opisujemy w tekście o macierzy ryzyka i rejestrze ryzyka.

Krok 1: ustal zakres i usługi objęte planem

Zacznij od usług, które organizacja świadczy na zewnątrz (w ustawie o KSC to „usługa” podmiotu kluczowego lub ważnego), a potem dopisz procesy wewnętrzne, bez których te usługi stają: płace, księgowość, poczta, dostęp do sieci. Zapisz granice: lokalizacje, systemy, dostawców. Sprawdzenie: każda usługa ma przypisanego właściciela z imienia i nazwiska.

Krok 2: przeprowadź analizę wpływu na działalność

Celem jest MTPD, RTO i RPO dla każdej usługi. Zapytaj właściciela, co się stanie po 4 godzinach, 1 dniu, 3 dniach i tygodniu przestoju. Oceń skutki finansowe, prawne (np. terminy ustawowe), dla klientów i dla bezpieczeństwa ludzi. Spisz zależności: systemy, dane, ludzi z unikalną wiedzą, dostawców. Wartości RTO i RPO zatwierdza kierownictwo, bo to decyzja o tym, jakie ryzyko organizacja przyjmuje. Sprawdzenie: RTO każdej usługi jest krótsze od jej MTPD, a RTO systemów, od których zależy, nie jest dłuższe niż RTO usługi.

Krok 3: wybierz strategie ciągłości i odtwarzania

Dla usług wybierz tryb zastępczy: praca ręczna, inna lokalizacja, praca zdalna, przekierowanie do partnera. Dla systemów wybierz sposób odtworzenia: kopia zapasowa z odtworzeniem na nowym sprzęcie, środowisko zapasowe, replikacja. Częstotliwość kopii porównaj z RPO. Według pkt 4.2.2 rozporządzenia 2024/2690 plan kopii obejmuje m.in. przechowywanie ich poza siecią systemu i z dala od głównej lokalizacji, kontrolę dostępu i okresy przechowywania. Sprawdzenie: dla każdej usługi istnieje strategia, a jej koszt kierownictwo zaakceptowało.

Krok 4: zapisz plan według stałej struktury

Strukturę opisujemy w następnej sekcji. Pisz krótko i operacyjnie: kto, co, w jakiej kolejności, z jakiego telefonu, tak żeby plan zrozumiał zastępca, który go nie pisał. Sprawdzenie: plan jest dostępny poza systemami, które mogą przestać działać (wersja papierowa lub kopia offline).

Krok 5: przetestuj plan

Rodzaje testów opisujemy niżej. Pierwszy test może być prosty, byle był udokumentowany.

Krok 6: wyznacz rytm przeglądów

Ustal stały termin przeglądu (np. raz w roku) i zdarzenia, które wymuszają przegląd wcześniej: poważny incydent, zmiana systemu, zmiana dostawcy, reorganizacja. Tak samo ujmuje to pkt 4.1.4 rozporządzenia 2024/2690. Sprawdzenie: dokument ma numer wersji i historię zmian, czego wymaga też art. 10 ust. 6 pkt 3 ustawy o KSC.

Co wpisać do planu: struktura dokumentu

Wiele osób szuka gotowego wzoru planu ciągłości działania. Wzór pomaga jako spis treści. Treść musi wynikać z BIA konkretnej organizacji. Poniższa struktura opiera się na elementach z pkt 4.1.2 i 4.3.2 załącznika do rozporządzenia 2024/2690, uzupełnionych o elementy praktyczne.

Progi aktywacji. Zapisz mierzalny warunek i osobę, która ma prawo ogłosić aktywację bez zwoływania zarządu.

Komunikacja kryzysowa. Zaplanuj kanał, który nie zależy od infrastruktury organizacji: listę telefonów na papierze, grupę w komunikatorze na prywatnych urządzeniach, zapasowe konto poczty. Obowiązki zgłoszeniowe wobec CSIRT to osobny proces, który plan powinien tylko wskazać z odesłaniem do procedury obsługi incydentów.

Kontakty do dostawców. Oprócz numeru infolinii wpisz numer umowy, poziom wsparcia i czas reakcji z umowy. O ryzyku po stronie dostawców piszemy w artykule atak na łańcuch dostaw.

Powrót do normalnego trybu. Dane wprowadzone w trybie ręcznym trzeba przenieść do systemu, a po cyberataku trzeba upewnić się, że odtworzone środowisko jest czyste.

Ransomware jako scenariusz bazowy

Jeśli testujesz tylko jeden scenariusz, wybierz ransomware. Sprawdza on prawie cały plan naraz: niedostępność wielu systemów jednocześnie, możliwą utratę kopii zapasowych dostępnych z sieci, konieczność komunikacji bez firmowej poczty i decyzję, od którego momentu odtwarzać dane. Przebieg takiego ataku i to, dlaczego kopie zapasowe bywają jego celem, opisujemy w artykule ransomware: jak działa atak.

Jak testować plan ciągłości działania

Plan sprawdza się na trzech poziomach, od najtańszego do najbardziej wymagającego.

Częstotliwości w tabeli to nasza propozycja. Przepisy nie podają odstępów, mówią o testowaniu (art. 8 ust. 1 pkt 2 lit. f ustawy o KSC) i regularnych testach (pkt 4.2.6 załącznika do rozporządzenia 2024/2690, art. 32 ust. 1 lit. d RODO). Odstępy dobierz do wyników BIA i analizy ryzyka.

Test odtworzenia ma największą wartość dowodową. Pkt 4.2.6 rozporządzenia 2024/2690 wymaga regularnych testów odzyskiwania kopii zapasowych, dokumentowania wyników i podejmowania działań naprawczych. Protokół z testu powinien zawierać: datę, system, źródło kopii, zmierzony czas odtworzenia, punkt w czasie, do którego odtworzono dane, problemy i działania naprawcze. Jeśli zmierzony czas wynosi osiem godzin, a w planie zapisano dwie, trzeba zmienić strategię albo RTO.

Najczęstsze błędy w planach ciągłości

Kopia zapasowa, której nikt nie odtwarzał. Wykonanie kopii nie dowodzi, że da się z niej odtworzyć system. Kopia może być niekompletna, uszkodzona albo zależeć od klucza czy konfiguracji, które zginęły razem z serwerem. Załącznik nr 4 do ustawy o KSC wprost wymaga testów kompletności i możliwości odtworzenia danych (pkt I.11).

RTO wpisane przez IT bez rozmowy z biznesem. Wtedy plan opisuje to, co IT potrafi dziś zrobić, a potrzeby organizacji zostają niezbadane. RTO i RPO wynikają z BIA i powinny być zatwierdzone przez kierownictwo.

Kopie w tej samej sieci co system produkcyjny. Jeśli atakujący ma dostęp do sieci, ma też dostęp do kopii. Rozporządzenie 2024/2690 (pkt 4.2.2 lit. c) i załącznik nr 4 do ustawy o KSC (pkt I.10) wymagają odseparowania kopii.

Brak dowodów. Bez protokołów z testów trudno wykazać, że plan był testowany, a ustawa tego wymaga. Plany ciągłości działania są jednym z dokumentów, o które pyta audyt cyberbezpieczeństwa wymagany ustawą o KSC.

Jak sprawdzić gotowość w SelfAudycie

SelfAudyt to narzędzie do samooceny zgodności z ustawą o KSC, NIS2, RODO i ISO/IEC 27001:2022. Nie jest audytem zewnętrznym ani certyfikatem. W obszarze ciągłości działania pyta m.in., czy w ostatnich 6 miesiącach organizacja odtworzyła system z kopii zapasowej i sprawdziła, ile to trwało. Luka trafia do rejestru ryzyk i planu naprawczego z terminem i osobą odpowiedzialną. Wśród szablonów dokumentów jest szablon planu ciągłości działania, a dokumenty z szablonów starsze niż 6 miesięcy trafiają na listę do odświeżenia. Orientacyjny obraz da szybki test 8 pytań, a przed audytem lub kontrolą przyda się moduł przygotowania do kontroli.

Najczęściej zadawane pytania

Czy plan ciągłości działania jest obowiązkowy?

Dla podmiotów kluczowych i ważnych tak. Art. 8 ust. 1 pkt 2 lit. f ustawy o KSC wymaga wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania, planów awaryjnych i planów odtworzenia działalności. Podmioty ważne będące podmiotami publicznymi stosują zamiast tego załącznik nr 4, który wymaga m.in. testowania procedury na wypadek awarii lub incydentu i testowania odtwarzania danych z kopii.

Czym różni się BCP od DRP?

BCP opisuje, jak utrzymać usługi i procesy organizacji w trakcie zakłócenia, w tym tryby zastępcze i komunikację kryzysową. DRP opisuje, jak odtworzyć systemy informatyczne i dane. DRP jest zwykle częścią szerszego zarządzania ciągłością działania, a w ustawie o KSC odpowiada mu plan odtworzenia działalności.

Jak często testować plan ciągłości działania?

Przepisy nie podają konkretnej częstotliwości. Ustawa o KSC wymaga testowania planów, a rozporządzenie 2024/2690 mówi o testach w planowanych odstępach czasu i po poważnych incydentach lub znaczących zmianach. Rozsądnym minimum jest coroczne ćwiczenie sztabowe i regularne testy odtworzenia krytycznych systemów z kopii, z pomiarem czasu.

Czy wystarczy pobrać wzór planu ciągłości działania?

Wzór porządkuje strukturę, ale nie zastępuje analizy wpływu na działalność. Wartości RTO i RPO, kolejność odtwarzania, kontakty i procedury zastępcze muszą wynikać z sytuacji konkretnej organizacji.

Zastrzeżenie

Ten artykuł ma charakter informacyjny i opisuje stan prawny na 24 października 2026 r. Nie jest poradą prawną. Zakres obowiązków konkretnej organizacji zależy od jej statusu w ustawie o KSC, sektora i przepisów szczególnych. Samoocena w SelfAudycie nie zastępuje audytu bezpieczeństwa, opinii prawnej ani certyfikacji. Definicje z norm ISO podajemy w omówieniu własnym na podstawie publicznie dostępnych informacji ISO, a nie pełnej treści norm.

Źródła

• Ustawa z dnia 23 stycznia 2026 r. o zmianie ustawy o krajowym systemie cyberbezpieczeństwa oraz niektórych innych ustaw (Dz.U. 2026 poz. 252) — Dziennik Ustaw RP, 2 marca 2026 (art. 8 ust. 1 pkt 2 lit. f, art. 8 ust. 3, art. 8b, art. 8c, art. 10, art. 67g, art. 73a, załącznik nr 4; art. 33 i 35 ustawy zmieniającej)
• Dz.U. 2026 poz. 252 w Internetowym Systemie Aktów Prawnych — Sejm RP
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 — EUR-Lex
• Rozporządzenie wykonawcze Komisji (UE) 2024/2690, załącznik pkt 4 — EUR-Lex
• Rozporządzenie (UE) 2016/679 (RODO), art. 32 — EUR-Lex
• Rozporządzenie (UE) 2022/2554 (DORA), art. 11 — EUR-Lex
• ISO 22301:2019 Security and resilience — Business continuity management systems — Requirements — ISO
• ISO 22300:2025 Security and resilience — Vocabulary — ISO
• ISO/IEC 27031:2025 Cybersecurity — Information and communication technology readiness for business continuity — ISO