KSC2 - Kopie zapasowe a ciągłość działania - dlaczego sam backup nie wystarcza?

W skrócieSam backup, czyli kopia zapasowa, nie wystarcza do ciągłości działania, bo odtwarza dane, a nie działającą firmę. Ustawa o krajowym systemie cyberbezpieczeństwa (KSC) wymaga planów ciągłości i odtworzenia, które są wdrożone, udokumentowane i testowane. Liczy się czas odtworzenia całego procesu, zależności między systemami i regularny test z zapisanym wynikiem.

W przykładzie, który rozkładamy w tym tekście na godziny, kopie danych były kompletne i atak ich nie dosięgnął. Odtworzenie systemu ERP (zintegrowanego systemu do zamówień, wysyłek i faktur) i tak trwało 70 godzin, choć zarząd zatwierdził cel 24 godzin. Opóźnienie wzięło się głównie z tego, czego nikt wcześniej nie sprawdził: klucz do szyfrowanych kopii leżał na serwerze zaszyfrowanym przez ransomware, kopii usługi katalogowej nigdy nie odtwarzano, licencja wymagała kontaktu z producentem, a kolejność uruchamiania ustalano na bieżąco.

Ustawa o KSC nie używa w art. 8 słów „kopia zapasowa” ani skrótów RTO i RPO, czyli docelowego czasu i docelowego punktu odtworzenia (wyjaśniamy je niżej). Wymaga za to od podmiotów kluczowych i ważnych wdrażania, dokumentowania, testowania i utrzymywania planów ciągłości działania oraz planów odtworzenia (art. 8 ust. 1 pkt 2 lit. f). Podmiot ważny będący podmiotem publicznym nie stosuje art. 8 ust. 1, tylko wymagania z załącznika nr 4 (art. 8 ust. 3). Kto podlega ustawie i do kiedy wdrożyć obowiązki, wyjaśnia nasz przewodnik po NIS2 i ustawie o KSC.

Pokazujemy, czym kopia różni się od planu ciągłości i planu odtworzenia, jak ustalić RTO i RPO, które zależności sprawdzić, jak chronić kopie przed ransomware (złośliwym oprogramowaniem szyfrującym dane dla okupu) i jak testować odtwarzanie. Decyzje zarządu w pierwszych godzinach ataku opisujemy osobno, w artykule o tym, co powinien zrobić zarząd w pierwszych godzinach incydentu.

Kopia zapasowa, plan ciągłości (BCP) i plan odtworzenia (DRP): czym się różnią

Kopia zapasowa to kopia danych, a często też konfiguracji i obrazów systemów, z której można je przywrócić. Odpowiada na pytanie, czy jest z czego odtworzyć. Nie odpowiada na pytania, w jakiej kolejności, kto to zrobi i jak firma pracuje, zanim systemy wrócą.

Plan ciągłości działania (BCP, od ang. business continuity plan) opisuje, jak firma utrzymuje lub wznawia kluczowe procesy, gdy systemy nie działają: tryb ręczny, zastępcze miejsce pracy, priorytety, komunikacja. Plan odtworzenia (DRP, od ang. disaster recovery plan) opisuje, jak przywrócić systemy informacyjne po poważnym zdarzeniu: kolejność, zasoby, osoby, punkty kontrolne. Ministerstwo Cyfryzacji, opisując art. 8 ust. 1 pkt 2 lit. f, wymienia trzy rodzaje planów: BCP, plany awaryjne (ISCP, od ang. information system contingency plan) i DRP (odpowiedź 3.3, stanowisko niewiążące). Plan awaryjny, jak wskazuje jego angielska nazwa, dotyczy systemu informacyjnego: co robić, gdy dany system przestanie działać.

W uproszczeniu zależność wygląda tak: kopia jest zasobem, z którego korzysta plan odtworzenia, a z planu odtworzenia korzysta plan ciągłości. Firma, która ma kopie, ale nie ma planów, ma dane i nie wie, co z nimi zrobić w pierwszej dobie.

Co ustawa o KSC mówi o kopiach i ciągłości działania

Podstawą jest art. 8 ust. 1 pkt 2 lit. f. System zarządzania bezpieczeństwem informacji (SZBI) ma zapewniać „wdrażanie, dokumentowanie, testowanie i utrzymywanie planów ciągłości działania umożliwiających ciągłe i niezakłócone świadczenie usługi”, a także planów awaryjnych oraz planów odtworzenia działalności, które pozwalają odtworzyć system informacyjny „po zdarzeniu, które spowodowało straty przekraczające zdolności podmiotu do odbudowy za pomocą własnych środków”. W przepisie testowanie stoi obok wdrażania i dokumentowania. Wnioskujemy z tego, że plan, którego nikt nie sprawdził, nie wypełnia przepisu w całości.

Kopie pojawiają się pośrednio. SZBI obejmuje mechanizmy zapewniające poufność, integralność, dostępność i autentyczność danych (art. 8 ust. 1 pkt 5 lit. a), a Ministerstwo Cyfryzacji pisze przy tym przepisie, że podmiot „powinien przykładowo dokonywać kopii zapasowej” (odpowiedź 3.3). Dokumentacja normatywna obejmuje dokumentację systemu zarządzania ciągłością działania (art. 10 ust. 3 pkt 3). CSIRT, czyli zespół reagowania na incydenty bezpieczeństwa komputerowego, nie przeprowadzi oceny bezpieczeństwa, jeżeli podmiot nie ma kopii bezpieczeństwa badanego systemu (art. 36b ust. 5 pkt 1). Przy incydencie krytycznym minister może poleceniem zabezpieczającym nakazać przegląd planów ciągłości działania, planów awaryjnych i planów odtworzenia (art. 67g ust. 10 pkt 2). Przepisy o poleceniu zabezpieczającym objął wniosek Prezydenta do Trybunału Konstytucyjnego (sprawa K 19/26, w toku według stanu na 12.10.2026).

Ustawa jest przy tym neutralna technologicznie i nie wskazuje konkretnych klas systemów, w tym systemów do kopii zapasowych, których wdrożenie byłoby obowiązkowe (odpowiedź 3.42 Ministerstwa Cyfryzacji). Poradnik NASK-PIB „Od wymagań do działania” (NASK-PIB to Naukowa i Akademicka Sieć Komputerowa, Państwowy Instytut Badawczy) z września 2026 r., który nie jest stanowiskiem ministerstwa, wymienia wśród typowych błędów traktowanie kopii zapasowych jako wystarczającego zabezpieczenia bez testowania ich odtwarzania (s. 43).

Dwie grupy mają wymagania bardziej szczegółowe. Podmiot ważny będący podmiotem publicznym stosuje SZBI według załącznika nr 4, który wymienia m.in. „wykonywanie zapasowych kopii danych odseparowanych logicznie i fizycznie” od danych produkcyjnych oraz „testowanie pod kątem kompletności i możliwości odtworzenia danych zawartych w zapasowych kopiach” (pkt I.10-11). Podmioty z art. 8b ust. 1 ustawy, m.in. dostawcy usług chmurowych, centrów przetwarzania danych i usług zarządzanych, stosują rozporządzenie wykonawcze Komisji (UE) 2024/2690. Jego załącznik wymaga planów kopii obejmujących czas przywrócenia normalnego działania i kompletność kopii (także konfiguracji i danych w chmurze), przechowywania kopii poza siecią systemu i w wystarczającej odległości, regularnych kontroli integralności oraz regularnych testów odzyskiwania z dokumentowaniem wyników (pkt 4.2.2, 4.2.3 i 4.2.6). Dla pozostałych firm to dobry wzór, ale nie obowiązek. Dyrektywa (UE) 2022/2555, zwana NIS2, wymienia wśród środków „ciągłość działania, np. zarządzanie kopiami zapasowymi i przywracanie normalnego działania po wystąpieniu sytuacji nadzwyczajnej, i zarządzanie kryzysowe” (art. 21 ust. 2 lit. c NIS2), ale polską firmę wiąże ustawa, nie dyrektywa.

RTO i RPO: dwa parametry, które zatwierdza zarząd

RTO (od ang. recovery time objective) to docelowy czas odtworzenia: jak długo proces może nie działać, zanim strata stanie się nie do przyjęcia. RPO (od ang. recovery point objective) to docelowy punkt odtworzenia: ile danych, liczonych w czasie wstecz od awarii, firma może stracić. RPO 4 godziny oznacza, że kopie muszą powstawać co najmniej co 4 godziny. RTO 24 godziny oznacza, że po dobie od awarii proces znów działa: nie tylko serwer, ale cały łańcuch od systemu, przez dane, po użytkowników i integracje.

W polskiej ustawie tych pojęć nie ma. Rozporządzenie 2024/2690 wymaga od podmiotów z art. 8b ust. 1, by plan ciągłości zawierał, w stosownych przypadkach, „cele w zakresie przywrócenia normalnego działania” (pkt 4.1.2 lit. f), by plany kopii obejmowały „czas przywrócenia normalnego działania” (pkt 4.2.2 lit. a) i by wymogi ciągłości wynikały z analizy wpływu na działalność (BIA, od ang. business impact analysis, pkt 4.1.3). RTO i RPO to praktyczny sposób zapisania takich celów liczbami. To nasz wniosek, nie przepis.

Kto ustala liczby? Właściciel procesu, czyli osoba odpowiedzialna za sprzedaż, produkcję czy płace, a zatwierdza zarząd. Kierownik podmiotu, czyli w spółce członkowie zarządu, podejmuje decyzje w zakresie SZBI i planuje środki finansowe na cyberbezpieczeństwo (art. 8d pkt 1 i 2), a skrócenie RTO ma swoją cenę: zapasowy sprzęt, licencje, ludzie w gotowości. Dział IT podaje, ile trwa odtworzenie dziś i ile kosztuje skrócenie, ale nie decyduje za zarząd, ile przestoju firma zniesie.

Przykład z założeniami dla spółki produkcyjnej zatrudniającej 180 osób:

Zależności: dlaczego kopia jednego systemu nie uruchomi firmy

System ERP nie działa sam. Żeby użytkownik zalogował się i wystawił fakturę, muszą działać:

• tożsamość i katalog: usługa katalogowa z kontami i grupami, uwierzytelnianie wieloskładnikowe (MFA), certyfikaty,
• DNS i sieć: system nazw domen (DNS), adresacja, przełączniki, zapory, połączenia VPN, czyli szyfrowane tunele do zakładu i do chmury,
• licencje: serwery licencji i aktywacje, które mogą wymagać kontaktu z producentem,
• klucze i hasła: klucz do zaszyfrowanych kopii, hasła do konsoli kopii i do platformy maszyn wirtualnych, przechowywane poza systemami, które mogą paść,
• ludzie: co najmniej dwie osoby, które choć raz przeprowadziły odtworzenie, oraz instrukcja napisana tak, żeby wykonał ją ktoś spoza zespołu,
• dostawcy: wsparcie producenta, dostawca chmury, firma IT, z numerami alarmowymi i godzinami pracy zapisanymi w umowie,
• integracje: elektroniczna wymiana dokumentów z klientami (EDI), bankowość, drukarki etykiet, systemy przewoźników.

Z zależności wynika kolejność uruchamiania. Rozporządzenie 2024/2690 każe zapisać w planie ciągłości, w stosownych przypadkach, „kolejność przywracania działalności” (pkt 4.1.2 lit. e), a testy odzyskiwania mają obejmować kopie, procesy i wiedzę potrzebną do skutecznego odzyskiwania (pkt 4.2.6). Dla firm spoza tego rozporządzenia to wzór dobrej praktyki. Ministerstwo Cyfryzacji przy monitorowaniu w trybie ciągłym wymienia także krytyczne pliki konfiguracyjne i kopie zapasowe (odpowiedź 3.3).

Przykład awarii: kopie spełniły RPO, a odtworzenie trwało 70 godzin

Przykład jest fikcyjny, a wszystkie liczby to założenia. Spółka produkcyjna zatrudniająca 180 osób wytwarza urządzenia elektryczne i jest podmiotem ważnym (sektor produkcji z załącznika nr 2 do ustawy). Zarząd zatwierdził dla procesu zamówień i wysyłki RTO 24 godziny i RPO 4 godziny. Kopie powstawały co 4 godziny, były szyfrowane i trafiały do repozytorium w osobnej sieci. W nocy z niedzieli na poniedziałek, o 2:00, ransomware zaszyfrował serwery wirtualne, w tym usługę katalogową i serwer ERP. Ostatnia kopia pochodziła z północy, więc spółka straciła 2 godziny danych, mniej niż zakładało RPO. Repozytorium kopii atak ominął.

Wynik: 70 godzin wobec RTO 24 godziny, czyli 46 godzin ponad cel. Z siedmiu etapów tylko jeden dotyczył samego przenoszenia danych (etap 5). Resztę czasu zabrało to, czego kopia nie obejmuje albo czego nikt nie przetestował: klucz w złym miejscu, kopia usługi katalogowej, której nigdy nie odtwarzano, licencje i integracje oraz kolejność ustalana na bieżąco. Gdyby spółka zrobiła wcześniej pełny test odtworzenia procesu, zobaczyłaby te 70 godzin w spokojnych warunkach, a nie w trakcie ataku.

Po incydencie spółka przygotowała plan, który mieści się w RTO (to znowu założenia): decyzja 6 godzin, przygotowana wcześniej czysta infrastruktura 4 godziny, klucz w dwóch miejscach offline 0,5 godziny, przetestowane odtworzenie usługi katalogowej 3 godziny, kopia ERP trzymana także lokalnie w osobnej sieci 6 godzin, licencje i integracje według instrukcji 2 godziny, weryfikacja według listy kontrolnej 2,5 godziny. Razem 24 godziny. Taki plan jest wiarygodny dopiero wtedy, gdy potwierdzi go test.

Kopie odseparowane i niezmienialne, reguła 3-2-1

Kopia, którą może skasować albo zaszyfrować to samo konto administratora, które przejął napastnik, nie chroni przed ransomware. Dlatego liczy się separacja. Kopia odseparowana to taka, której nie da się zmienić z sieci produkcyjnej: inna sieć, osobne poświadczenia, osobna konsola z uwierzytelnianiem wieloskładnikowym, czasem nośnik odłączony od sieci (offline). Kopia niezmienialna (ang. immutable) to kopia, której przez ustalony czas nie da się zmienić ani usunąć, także z konta administratora.

Reguła 3-2-1 to praktyka branżowa, nie przepis: co najmniej trzy kopie danych (dane produkcyjne i dwie kopie zapasowe), na dwóch różnych rodzajach nośników lub w dwóch różnych systemach, z czego jedna poza siedzibą. Przy ransomware ważniejsze od liczby kopii jest to, czy przynajmniej jedna leży poza zasięgiem kont, które mógł przejąć napastnik.

Co na to przepisy? Ustawa o KSC nie używa pojęć kopii niezmienialnej ani reguły 3-2-1. Dla podmiotu ważnego będącego podmiotem publicznym załącznik nr 4 wymaga odseparowania kopii logicznie i fizycznie (pkt I.10), a Ministerstwo Cyfryzacji wyjaśnia, że chodzi o to, by kopia nie była narażona na te same ryzyka co dane produkcyjne, i że ustawa nie wskazuje obowiązku przechowywania kopii zapasowych w innych budynkach (odpowiedź 3.41). Dla podmiotów z art. 8b ust. 1 rozporządzenie 2024/2690 wymaga przechowywania kopii w miejscu, które nie znajduje się w tej samej sieci co system i leży w wystarczającej odległości, oraz fizycznej i logicznej kontroli dostępu do kopii (pkt 4.2.2 lit. c i d).

Gdy kopie robi dostawca chmury albo firma IT, o separację, czas odtworzenia i testy trzeba zapytać przed podpisaniem umowy i zapisać je w umowie. Ministerstwo Cyfryzacji zauważa, że wykonywanie kopii zapasowych może być usługą zarządzaną albo usługą zarządzaną w zakresie cyberbezpieczeństwa, zależnie od kontekstu (odpowiedź 1.40), a kierownik podmiotu odpowiada za obowiązki także wtedy, gdy ich wykonanie powierzył innej osobie (art. 8c ust. 3). Listę pytań do dostawców daje artykuł o tym, o co zapytać firmę IT, hosting i dostawcę chmury.

Test odtwarzania: zakres, częstotliwość i dokumentacja wyniku

Test odtwarzania sprawdza, czy z kopii da się przywrócić działanie w zakładanym czasie. Ma kilka poziomów, a częstotliwości w tabeli to nasza propozycja, nie wymóg:

Ustawa nie określa częstotliwości testów. Rozporządzenie 2024/2690, które stosują podmioty z art. 8b ust. 1, mówi o regularnych kontrolach integralności i regularnych testach odzyskiwania (pkt 4.2.3 i 4.2.6) oraz o testowaniu planów ciągłości w planowanych odstępach czasu i po poważnych incydentach lub znaczących zmianach (pkt 4.1.4).

Test zakończony sukcesem to nie „kopia się odtworzyła”. Proponujemy pięć kryteriów. Proces działa w czasie nie dłuższym niż RTO, mierzonym od startu do zgody właściciela procesu. Utrata danych nie przekracza RPO. Dane są kompletne i spójne, np. zgadza się liczba rekordów i ostatnie transakcje. Odtworzenie wykonała według instrukcji osoba inna niż jej autor. Wynik i problemy trafiły do protokołu.

Protokół testu to dowód, że plan jest testowany, a nie tylko zapisany. Dokumentację operacyjną stanowią zapisy poświadczające wykonywanie czynności wymaganych przez dokumentację normatywną (art. 10 ust. 4), a rozporządzenie 2024/2690 każe dokumentować wyniki testów i w razie potrzeby podejmować działania naprawcze (pkt 4.2.6). Ministerstwo Cyfryzacji przypomina, że wymagane jest udowodnienie stosowania przepisów, a nie przedstawienie formalnie poprawnych dokumentów (odpowiedź 11.6). Test techniczny dobrze uzupełnić ćwiczeniem zarządu: scenariusz z wstrzyknięciami i pytaniami opisujemy w artykule o tym, jak przeprowadzić ćwiczenie cyberataku dla zarządu.

Od czego zacząć: pięć kroków na najbliższy kwartał

1. Procesy krytyczne i analiza wpływu. Które procesy przynoszą przychód albo chronią ludzi i ile kosztuje każda godzina ich przestoju. Koszt podają finanse i właściciele procesów, nie dział IT.
2. RTO i RPO zatwierdzone przez zarząd dla każdego procesu krytycznego, razem z budżetem na ich osiągnięcie.
3. Mapa zależności i kolejność uruchamiania, klucze i hasła offline w dwóch miejscach, instrukcja odtworzenia dla kogoś spoza zespołu.
4. Kopie odseparowane, w tym co najmniej jedna niezmienialna lub offline, z osobnymi poświadczeniami i alertami.
5. Pełny test odtworzenia jednego procesu, protokół, plan poprawek i powtórka po poprawkach.

Wynik tych prac trafia do dokumentacji systemu zarządzania ciągłością działania, która jest częścią dokumentacji normatywnej (art. 10 ust. 3 pkt 3). Jakie jeszcze dokumenty przygotować, pokazujemy w artykule o tym, jakie dokumenty przygotować do wdrożenia KSC.

Podstawa prawna i źródła

• art. 8 ust. 1 pkt 2 lit. f ustawy o KSC - plany ciągłości działania, plany awaryjne i plany odtworzenia działalności
• art. 8 ust. 1 pkt 5 lit. a ustawy o KSC - mechanizmy poufności, integralności, dostępności i autentyczności danych
• art. 8b ust. 1 ustawy o KSC - podmioty stosujące rozporządzenie wykonawcze Komisji (UE) 2024/2690
• art. 8c ust. 3 oraz art. 8d pkt 1 i 2 ustawy o KSC - odpowiedzialność, decyzje i budżet kierownika podmiotu
• art. 5 ust. 2 pkt 2 i załącznik nr 2 ustawy o KSC - podmiot ważny (status spółki z przykładu)
• art. 10 ust. 3 pkt 3 i ust. 4 ustawy o KSC - dokumentacja systemu zarządzania ciągłością działania, dokumentacja operacyjna
• art. 36b ust. 5 pkt 1 ustawy o KSC - ocena bezpieczeństwa a kopia bezpieczeństwa systemu
• art. 67g ust. 10 pkt 2 ustawy o KSC - nakaz przeglądu planów (przedmiot sprawy K 19/26 przed Trybunałem Konstytucyjnym)
• art. 8 ust. 3 i załącznik nr 4 pkt I.10-12 ustawy o KSC - kopie odseparowane, testowanie kopii i procedury w podmiocie ważnym będącym podmiotem publicznym
• art. 21 ust. 2 lit. c dyrektywy NIS2 - ciągłość działania i zarządzanie kopiami zapasowymi
• rozporządzenie wykonawcze Komisji (UE) 2024/2690, załącznik pkt 4.1.2-4.1.4, 4.2.2, 4.2.3 i 4.2.6 - plan ciągłości, kopie, testy
• Ministerstwo Cyfryzacji, odpowiedzi 1.40, 3.3, 3.41, 3.42 i 11.6 (stanowisko niewiążące)
• Ustawa o krajowym systemie cyberbezpieczeństwa, tekst ujednolicony ze stanem na 8.10.2026 (Sejm, ISAP)
• Dyrektywa (UE) 2022/2555 (NIS2) w EUR-Lex
• Rozporządzenie wykonawcze Komisji (UE) 2024/2690 w EUR-Lex
• Ministerstwo Cyfryzacji, pytania i odpowiedzi do znowelizowanej ustawy o KSC, aktualizacja październik 2026
• NASK-PIB, „Od wymagań do działania”, poradnik do znowelizowanej ustawy o KSC, wrzesień 2026