Audyt ciągłości działania (BCP/DR), NIS2 art. 21(2)(c) + RODO art. 32

Październik 2023 r. Polska Grupa Energetyczna ofiarą ransomware. Wrzesień 2024 r. atak ransomware na MOL Polska zatrzymuje produkcję na trzy dni. Listopad 2024 r. ALAB Laboratoria, kompromitacja danych medycznych 200 000+ pacjentów, naruszenie RODO. Każdy z tych przypadków miał dwa wspólne mianowniki: po pierwsze, atak udał się, bo zabezpieczenia prewencyjne miały luki. Po drugie, czas powrotu do operacyjności okazał się znacznie dłuższy niż firmy zakładały, bo backupy albo nie istniały w pełnym zakresie, albo zostały zaszyfrowane razem z systemami produkcyjnymi, albo nie były testowane.

NIS2 art. 21 ust. 2 lit. c wymaga “ciągłości działania, takich jak zarządzanie kopiami zapasowymi, odzyskiwanie po awarii oraz zarządzanie kryzysowe”. RODO art. 32 ust. 1 lit. b wymaga “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 dodaje “zdolności do szybkiego przywrócenia dostępności danych osobowych i dostępu do nich w razie incydentu fizycznego lub technicznego”.

Audyt ciągłości działania w 2026 r. jest audytem trzech wymiarów jednocześnie: zdolności technicznej (czy backupy faktycznie się przywracają), zdolności proceduralnej (czy zespół wie, co robić), oraz odporności specyficznej na ransomware (immutable backups, air-gapped copies). Ten tekst jest pełną metodyką dla każdego z trzech wymiarów.

Trzy poziomy odporności, BCP, DR, BIA

Business Impact Analysis (BIA). Punkt wyjścia. Identyfikuje krytyczne procesy biznesowe, ich zależności od systemów IT, dopuszczalne czasy przerwy (RTO, Recovery Time Objective) i dopuszczalne utraty danych (RPO, Recovery Point Objective). Bez BIA pozostałe dokumenty są zawieszone w próżni.

Business Continuity Plan (BCP). Plan zachowania ciągłości operacji biznesowych. Obejmuje: alternatywne lokalizacje pracy, procesy manualne fall-back, komunikację z klientami i partnerami, łańcuch decyzyjny w kryzysie.

Disaster Recovery Plan (DR). Plan techniczny przywracania systemów IT. Obejmuje: kolejność przywracania (które systemy pierwsze), procedury per system, lokalizacje backupów, role zespołu, eskalację.

Audyt zaczyna się od weryfikacji, czy te trzy dokumenty istnieją, są aktualne (minimum z ostatnich 12 miesięcy), są ze sobą spójne. Brak któregokolwiek = poważne ustalenie.

Obszar 1: Strategia backupów, fundament

Reguła 3-2-1. Standard branżowy: 3 kopie danych, 2 różne nośniki/typy storage, 1 off-site. Współczesne rozszerzenie 3-2-1-1-0: dodatkowo 1 immutable (offline lub air-gapped) i 0 błędów weryfikacji.

Co audytor sprawdza.

• Polityka backupów per system krytyczny
• Częstotliwość backupów (idealnie: ciągła replikacja dla bazy + dzienne pełne)
• Lokalizacje (on-site, off-site geograficzne, cloud, co najmniej 2 z 3)
• Szyfrowanie backupów (zawsze!)
• Retencja (zgodna z BIA, zwykle 30 dni dzienne, 12 mies. miesięczne, 7 lat dla wymogów prawnych)

Standard 2026, odporność na ransomware:

• Immutable backups (WORM, Write Once Read Many) jako obowiązkowe dla danych krytycznych
• Air-gapped copies (offline, fizycznie odłączone) dla strategicznych danych
• Cloud backups z immutable retention (np. AWS S3 Object Lock, Azure Immutable Blob Storage)

Częste luki.

• Backupy w tej samej infrastrukturze co produkcja (ransomware zaszyfruje oba).
• Backupy szyfrowane kluczem, który leży obok serwera produkcyjnego.
• “Mamy backup” oznacza w praktyce snapshot RAID, co nie chroni przed ransomware ani błędem ludzkim.
• Brak dokumentacji jakie dokładnie systemy są backupowane.
• Retencja krótka (7-14 dni), niewystarczająca dla wykrycia incydentu pre-encryption.

Obszar 2: Test odtwarzania, kluczowy moment audytu

Reguła kardynalna: backup, który nie został nigdy przywrócony, nie istnieje. Audytor zawsze testuje praktycznie.

Test 1: pełne odtworzenie wybranego systemu. Audytor wybiera jeden system krytyczny (np. bazę klientów). Prosi o przywrócenie z backupu sprzed 7 dni do środowiska izolowanego (sandbox). Mierzy: czas, czy proces działa, czy dane są spójne, czy aplikacja po odtworzeniu działa.

Test 2: punkt w czasie (point-in-time recovery). Audytor wybiera konkretny moment z ostatnich 14 dni (np. “9 maja 2026 o 14:30”) i prosi o odtworzenie stanu bazy z tego momentu. Sprawdza, czy granularność backupu pozwala na PITR (Point-In-Time Recovery).

Test 3: weryfikacja integralności. Audytor prosi o raport z ostatniego testu integralności backupów. Czy automatyczna weryfikacja działa? Czy są case’y “backup zapisany, ale uszkodzony”?

Test 4: ransomware scenario. Audytor symuluje scenariusz: “Cały produkcyjny storage jest zaszyfrowany przez ransomware. Pokażcie procedurę przywrócenia z immutable backup”. Mierzy: czas decyzyjny, czas techniczny, kompletność procedury.

Częste obserwacje.

• Backup się przywraca, ale dane są z poprzedniego dnia o godz. 23:00, utracone 18 godzin transakcji.
• Backup się przywraca, ale aplikacja nie wstaje, bo wymaga manualnej rekonfiguracji.
• “Mamy backup, ale nigdy nie testowaliśmy odtwarzania”, najczęstsze.
• Test odtwarzania robi się raz w roku z fanfarami, ale nikt nie weryfikuje, czy z każdego backupu w międzyczasie da się przywrócić.

Standardy 2026.

• Test odtwarzania pełnego DR minimum raz w roku (idealnie kwartalnie).
• Automatyczna weryfikacja integralności każdego backupu.
• Test point-in-time recovery raz na kwartał.
• Test ransomware scenario raz na pół roku.

Obszar 3: RTO i RPO, kwantyfikacja oczekiwań

Recovery Time Objective (RTO), maksymalny dopuszczalny czas przerwy. Recovery Point Objective (RPO), maksymalna dopuszczalna utrata danych. Bez tych liczb BCP/DR są życzeniami.

Przykład realistycznych RTO/RPO dla średniej firmy 2026:

System	Krytyczność	RTO	RPO
System ERP (finanse)	krytyczny	4 godziny	15 minut
CRM	krytyczny	8 godzin	1 godzina
System kadrowo-płacowy	wysoki	24 godziny	4 godziny
Magazyn dokumentów	średni	48 godzin	24 godziny
Intranet	niski	5 dni	24 godziny

Co audytor sprawdza.

• Czy RTO i RPO są zdefiniowane per system krytyczny (zgodne z BIA).
• Czy realne testy potwierdzają osiągalność tych RTO/RPO.
• Czy strategia backupów pasuje do RPO (jeśli RPO = 15 minut, dziennej kopii pełnej nie wystarczy, potrzeba ciągłej replikacji).

Częsta luka. RTO/RPO są napisane w BCP, ale nigdy nie były zweryfikowane praktycznie. Test pokazuje: prawdziwe RTO jest 4× dłuższe niż zadeklarowane.

Obszar 4: Plan komunikacji kryzysowej

Techniczny DR bez komunikacji kryzysowej = wpadnięcie w drugą katastrofę (utratę zaufania klientów i partnerów).

Co audytor sprawdza.

• Plan komunikacji kryzysowej (kto, kogo, kiedy, jakim kanałem)
• Lista kluczowych interesariuszy z aktualnymi kontaktami
• Szablony komunikatów (do klientów, partnerów, mediów, regulatorów)
• Procedury akceptacji treści w trybie awaryjnym
• Alternatywne kanały komunikacji (jeśli e-mail i Slack są niedostępne)

Test: symulacja stołowa scenariusza wymagającego komunikacji zewnętrznej. Audytor obserwuje: czas reakcji, jakość treści, kompletność listy odbiorców.

Obszar 5: Łańcuch decyzyjny w kryzysie

W kryzysie nie ma czasu na “kto decyduje”. To musi być wiadome.

Co audytor sprawdza.

• Lista decyzji wymagających autoryzacji (np. ogłoszenie sytuacji kryzysowej, decyzja o płaceniu okupu, decyzja o przywróceniu z backupu, decyzja o powiadomieniu mediów).
• Lista osób uprawnionych do każdej decyzji + fall-back person.
• Procedura eskalacji w nocy / weekendy / święta.
• Realne dane kontaktowe (telefon prywatny członka zarządu, nie tylko mail służbowy).

Test: “Zadzwoń teraz do osoby, która ma autoryzować decyzję o przywróceniu systemu kadrowego o 3:00 w nocy. Pokażcie, że telefon jest aktualny.”

Macierz oceny dojrzałości BCP/DR

Element	Poziom 1	Poziom 2	Poziom 3 (min NIS2)	Poziom 4	Poziom 5
BIA	nieaktualna lub brak	częściowa	kompletna, aktualna roczna	+ kwartalna walidacja	+ ciągłe monitorowanie zależności
BCP/DR docs	minimalne	są, niepełne	kompletne, spójne, aktualne	+ automatyczne testy	+ ciągłe doskonalenie
Backupy	są, 3-2-1 nieprzestrzegane	3-2-1 wdrożone	+ immutable dla krytycznych	+ kwartalne testy	+ chaos engineering
Testy odtwarzania	nigdy	jednorazowe	roczne pełne	kwartalne	ciągłe automatyczne
RTO/RPO	nieokreślone	są w dokumencie	są i zweryfikowane	+ monitoring real-time	+ optymalizowane ciągle
Komunikacja kryzysowa	brak planu	plan jest	+ przetestowany	+ alternatywne kanały	+ automatyzowane szablony

Format ustalenia

Ustalenie BCP-03 (klasyfikacja: krytyczne): Backupy systemu kadrowo-płacowego nie były testowane od momentu wdrożenia (czerwiec 2022 r., 4 lata). RTO zadeklarowany w BCP: 24 godziny. Brak dowodów na realną osiągalność tego RTO.

Dowody: (1) Wywiad z dyrektorem IT i administratorem systemu; (2) Brak raportów z testów odtwarzania w archiwum; (3) Polityka BCP wymaga rocznych testów, niewykonywane.

Ryzyko prawne i operacyjne: Naruszenie NIS2 art. 21(2)(c) i RODO art. 32(1)(c). W przypadku katastrofy (ransomware, awaria storage) brak gwarancji odtworzenia danych pracowników. Konsekwencje finansowe i prawne (terminy wypłat, ZUS, US).

Rekomendacja korygująca: (1) Test odtwarzania pełnego do izolowanego środowiska, w 30 dni; (2) Pomiar realnego RTO i RPO; (3) Jeśli RTO/RPO niewystarczające, modyfikacja strategii backupów; (4) Kalendaryzacja kwartalnych testów. Odpowiedzialny: dyrektor IT + administrator.

Trzy pytania kontrolne dla zarządu

Pierwsze. Kiedy ostatnio testowaliśmy odtwarzanie systemów krytycznych i z jakim wynikiem? Odpowiedź “nigdy” lub “nie pamiętam” = brak BCP w praktyce.

Drugie. Co się stanie, jeśli ransomware zaszyfruje całą produkcję dziś wieczorem? Konkretna procedura z czasami, czy spekulacja?

Trzecie. Kto budzi członka zarządu o 3:00 w nocy przy krytycznym incydencie i czy ten numer jest aktualny?

Esencja

Audyt ciągłości działania weryfikuje trzy wymiary: techniczny (czy backupy się przywracają), proceduralny (czy zespół wie, co robić), ransomware-resilience (czy mamy immutable i air-gapped).

Backup, który nie został przywrócony, nie istnieje. Audytor zawsze testuje praktycznie, pełne odtworzenie wybranego systemu, point-in-time recovery, scenariusz ransomware. Rezultaty pokazują różnice między dokumentem a rzeczywistością.

RTO i RPO bez weryfikacji są życzeniami. Realne testy pokazują, że deklarowane czasy są często 4× przeoptymistyczne. Bez zweryfikowanych liczb BCP nie jest narzędziem zarządczym.

Reguła 3-2-1-1-0 (3 kopie, 2 nośniki, 1 off-site, 1 immutable, 0 błędów) to standard 2026 dla podmiotu kluczowego NIS2. Immutable backups (WORM) są mandatory dla danych krytycznych. Brak = ekspozycja na ransomware bez realnej obrony.

Plan komunikacji kryzysowej i łańcuch decyzyjny są równie ważne, co backup. Techniczny DR bez warstwy ludzkiej i komunikacyjnej powoduje, że firma “ma backup”, ale traci miesiące, by go efektywnie wykorzystać.

Większość polskich firm średnich jest dziś na poziomie 1-2 dojrzałości. NIS2 wymaga poziomu 3 dla podmiotów kluczowych. Realny test odtwarzania, to godzina, która oddziela poziom 2 od poziomu 3.

---

• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 21 ust. 2 lit. (c). https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 (RODO), art. 32 ust. 1 lit. (b)(c). https://eur-lex.europa.eu/eli/reg/2016/679/oj
• ISO 22301:2019. Security and resilience, Business continuity management systems, Requirements. International Organization for Standardization.
• ISO 22313:2020. Security and resilience, Business continuity management systems, Guidance on the use of ISO 22301.
• NIST SP 800-34 Rev. 1 (2010). Contingency Planning Guide for Federal Information Systems. https://doi.org/10.6028/NIST.SP.800-34r1
• NIST SP 800-184 (2016). Guide for Cybersecurity Event Recovery. https://doi.org/10.6028/NIST.SP.800-184
• ENISA (2024). Ransomware: Attacks and Mitigation Strategies. https://www.enisa.europa.eu/publications
• CISA (2023). Stop Ransomware Guide. https://www.cisa.gov/stopransomware
• CSIRT NASK / CERT Polska. Raporty o ransomware w Polsce (2022-2024). https://www.cert.pl/publikacje/
• Veeam. Data Protection Trends Report 2024. https://www.veeam.com/wp-data-protection-trends.html