Zaktualizowano: 3 lipca 2026
Czym jest zarządzanie ciągłością działania BCM i dlaczego tradycyjne podejście nie wystarczy? Business Continuity Management (BCM) to system zarządzający zdolnością organizacji do kontynuowania krytycznych operacji w trakcie zakłóceń – od awarii infrastruktury, przez klęski żywiołowe, po celowe cyberataki. Kluczowe parametry BCM to RTO (Recovery Time Objective – czas odtworzenia usługi) i RPO (Recovery Point Objective – akceptowalna utrata danych).
Tradycyjne plany BCM były budowane pod awarie sprzętowe lub klęski żywiołowe z zakładanym, ograniczonym blast radiusem. Cyberataki – ransomware, wipery, ataki APT – łamią te założenia: przyczyna awarii może być nieznana przez dni, środowisko odtworzenia może być skompromitowane razem ze środowiskiem produkcyjnym, a zakłócenie może dotyczyć jednocześnie systemów, tożsamości i komunikacji.
BCM a cyberataki – w skrócie:
- Według Sophos State of Ransomware 2024 średni przestój po ataku ransomware wyniósł 22 dni – firmy z przetestowanymi planami BCM i izolowanymi backupami odtwarzają się znacznie szybciej
- DORA (art. 11-12) nakłada na instytucje finansowe wymóg udokumentowanej polityki ciągłości ICT z celami odtworzenia i testowanymi uzgodnieniami backupu
- NIS2 art. 21 wymaga ciągłości działania, zarządzania backupami, disaster recovery i zarządzania kryzysowego jako minimalnych środków zarządzania ryzykiem
- Backup podłączony do domeny produkcyjnej jest szyfrowany razem ze środowiskiem produkcyjnym podczas ransomware – immutable lub offline backup jest wymogiem, nie opcją
- BCM musi uwzględniać scenariusze ataków na dostawców (jak MOVEit 2023, który dotknął ponad 2700 organizacji przez jeden produkt)
- Patronusec wspiera organizacje w budowie programów BCM odpornych na cyberataki – od BIA i analizy scenariuszy, przez plany BCP/DRP, po testowanie i zgodność z DORA i NIS2
Spis treści
Czym różni się tradycyjny BCM od BCM odpornego na cyberataki?
Tradycyjny BCM zakłada trzy rzeczy, których cyberataki nie gwarantują. Po pierwsze – że przyczyna zakłócenia jest znana. W ransomware lub ataku APT przyczyna może być nieznana przez dni lub tygodnie. Po drugie – że środowisko odtworzenia jest nienaruszone. Backup podłączony do domeny produkcyjnej jest zaszyfrowany razem ze środowiskiem. Po trzecie – że zakłócenie jest lokalne. Atak na dostawcę kaskaduje na klientów, którzy nic złego nie zrobili.
Kluczowe różnice:
| Tradycyjny BCM | BCM odporny na cyberataki |
|---|---|
| Scenario: awaria sprzętowa, klęska żywiołowa | Scenario: ransomware, wiper, atak APT, supply chain |
| Przyczyna znana od razu | Przyczyna może być nieznana przez dni |
| Środowisko odtworzenia nienaruszone | Backup może być zaszyfrowany/zniszczony |
| Blast radius ograniczony | Atak może objąć IT, OT, komunikację jednocześnie |
| Recovery: przywróć z backupu | Recovery: najpierw odizoluj, ustal zakres, potem przywróć |
| Tożsamość: zakładamy integridad AD | Tożsamość może być skompromitowana – odtwarzanie zaczynaj od Identity |
Implikacje dla architektury BCM:
Plany BCM muszą zawierać scenariusze cyber. BIA (Business Impact Analysis) musi identyfikować nie tylko „co jest krytyczne” ale też „co nie może być niedostępne przez X godzin podczas cyberataku”. Plan DR musi określać sekwencję odtwarzania przy założeniu, że Active Directory i systemy zarządzania mogą być skompromitowane.
Patronusec Insight: Z naszej praktyki z klientami wynika, że większość planów BCM nie zawiera odpowiedzi na fundamentalne pytanie cyberincydentu: „Od czego zacząć odtwarzanie jeśli nie wiadomo, co jest skompromitowane?”. Odpowiedź na to pytanie musi być udokumentowana i przetestowana przed incydentem. W ramach usługi vCISO pomagamy klientom przeprowadzić tabletop exercises dla scenariuszy ransomware – symulacje decyzyjne, które ujawniają luki w planach zanim pojawi się realny incydent.
Jak BIA (Business Impact Analysis) powinna wyglądać dla scenariuszy cyberataków?
Business Impact Analysis to podstawa BCM – bez niej nie wiesz, co chronić w pierwszej kolejności. Dla scenariuszy cyber BIA musi wyjść poza tradycyjne pytania „co jest krytyczne” i zadać pytania specyficzne dla cyberincydentów.
Kluczowe pytania BIA dla scenariuszy cyber:
Dla każdego procesu biznesowego:
- Jaki jest maksymalny tolerowany czas niedostępności (MTPD)?
- Jaka jest akceptowalna utrata danych (RPO)?
- Czy proces może działać ręcznie jeśli systemy IT są niedostępne?
- Jakie zewnętrzne zależności (dostawcy, API, SaaS) mogłyby zaatakować ten proces?
- Czy tożsamość (Active Directory) jest wymagana do działania tego procesu?
Specyficzne pytania dla scenariuszy ransomware:
- Czy mamy offline lub immutable backup tego systemu?
- Ile czasu zajmie odtworzenie z takiego backupu (znamy to z testu)?
- Czy procedury operacyjne dla tego procesu istnieją w formie papierowej lub offline?
- Kto ma uprawnienia do decyzji o płatności lub odmowie płatności okupu?
Dokumentacja wymagana przez DORA i NIS2:
DORA art. 11.5 wymaga udokumentowanych „polityk i procedur dotyczących tworzenia kopii zapasowych oraz procedur i metod odtwarzania i przywracania” z jasno zdefiniowanymi celami. NIS2 art. 21.2 wymaga „planów ciągłości działania i zarządzania kryzysowego”.
Chcesz sprawdzić, czy Twój obecny plan BCM przetrwa atak ransomware?
Patronusec przeprowadza tabletop exercises dla scenariuszy cyberataków – symulacje decyzyjne z zarządem i zespołem IT identyfikujące luki w planach BCM/DRP. W ciągu jednego dnia warsztatowego zyskujesz listę konkretnych działań do wdrożenia.
Jak spełnić wymogi DORA i NIS2 dotyczące ciągłości działania?
DORA i NIS2 nakładają konkretne wymogi na zarządzanie ciągłością działania BCM, które wykraczają poza tradycyjne podejście.
DORA (Digital Operational Resilience Act) – wymogi BCM
DORA art. 11 (Polityka ciągłości działalności ICT) wymaga:
- Udokumentowanej polityki ciągłości ICT zatwierdzanej przez organ zarządzający
- Planu ciągłości działalności ICT i planów reagowania i odtwarzania
- Testowania planów co najmniej raz w roku
- Wdrożenia „redundantnych zdolności ICT” dla krytycznych procesów
DORA art. 12 (Plany przywracania sprawności po awarii) wymaga:
- Polityki backupu z zdefiniowanymi RPO i częstotliwością backupu
- Procedur odtwarzania i przywracania z gwarantowanymi RTO
- Regularnego testowania backupu i odtwarzania
- Bezpiecznej izolacji backupu od sieci produkcyjnej
NIS2 (Dyrektywa NIS2) – wymogi BCM:
NIS2 art. 21.2 wymaga od podmiotów kluczowych i ważnych wdrożenia środków obejmujących:
- Ciągłość działania, w tym zarządzanie kopiami zapasowymi i przywracanie działalności po katastrofie
- Zarządzanie incydentami bezpieczeństwa
- Zarządzanie kryzysowe
NIS2 nie definiuje konkretnych RTO/RPO – te są ustalane przez organizację na podstawie BIA i oceny ryzyka. Jednak krajowe organy transponujące mogą dodawać bardziej szczegółowe wymagania.
Patronusec Insight: Różnica między DORA a NIS2 w kontekście BCM jest często źródłem zamieszania. DORA jest bardziej precyzyjna i sektorowa (dotyczy głównie instytucji finansowych i ICT providers) – ma konkretne wymagania dotyczące testowania i dokumentacji. NIS2 jest szersza i mniej precyzyjna – pozostawia więcej swobody organizacji. Dla organizacji objętych obiema regulacjami (np. fintech podlegający pod NIS2 i DORA) rekomendujemy zacząć od DORA jako bardziej wymagającej – spełnienie DORA zazwyczaj implikuje spełnienie NIS2. Rozmawiamy o tym podczas bezpłatnej konsultacji vCISO.
Jak testować plany BCM i co wymaga DORA?
Test BCM który nigdy nie był przeprowadzony to dokument, nie zabezpieczenie. DORA art. 11.6 wymaga testowania planów ciągłości ICT co najmniej raz w roku.
Rodzaje testów BCM:
Przegląd dokumentacyjny (Document Review): Weryfikacja, czy plany są aktualne, kompletne i spójne z aktualną architekturą. Nie testuje rzeczywistego działania. Minimalna wartość dla cyber resilience.
Tabletop Exercise: Symulacja decyzyjna – uczestnicy (zarząd, IT, biznes) dyskutują scenariusz bez uruchamiania rzeczywistych systemów. Identyfikuje luki w procesach decyzyjnych, komunikacji i eskalacji. Szczególnie wartościowy dla scenariuszy ransomware i crisis communication.
Simulation Exercise: Uruchomienie procedur BCP/DRP w kontrolowanym środowisku testowym. Weryfikuje, czy procedury działają w praktyce, nie tylko na papierze.
Full Failover Test: Rzeczywiste przełączenie na środowisko DR. Najtrudniejszy do zorganizowania, ale daje pewność, że system działa. Wymaga okna serwisowego i szczegółowego planowania.
Co DORA wymaga od testów:
DORA art. 11.6 precyzuje, że testy muszą być „oparte na scenariuszach” i uwzględniać wnioski z poprzednich incydentów. Wyniki testów muszą być raportowane do organu zarządzającego. Podmioty istotne muszą przeprowadzać TLPT co 3 lata jako najgłębszy poziom testowania.
FAQ – Zarządzanie ciągłością działania BCM
Czym się różni BCP od DRP?
BCP (Business Continuity Plan) to szerszy plan utrzymywania krytycznych funkcji biznesowych podczas zakłóceń – obejmuje procesy, komunikację, alternatywne lokalizacje i zasoby ludzkie. DRP (Disaster Recovery Plan) to bardziej techniczny plan odtwarzania systemów IT i infrastruktury po awarii. DRP jest częścią BCP – BCP definiuje „co musimy zachować działające”, DRP definiuje „jak przywrócimy systemy IT które to umożliwiają”.
Jak często powinienem testować backup?
Backup musi być testowany co najmniej raz w roku – DORA wymaga corocznych testów, ISO 27001 (Aneks A, A.5.30) i dobre praktyki operacyjne sugerują częstsze testy dla krytycznych systemów. Praktyczna rekomendacja: krytyczne systemy (baza danych z danymi klientów, systemy płatnicze) – test odtwarzania co kwartał. Pozostałe – co roku. Test musi być udokumentowany.
Czy muszę mieć osobne środowisko DR?
Nie jest to wymóg bezwzględny, ale praktyczna konieczność dla systemów z niskim RTO. Dla systemów z RTO poniżej 4-8 godzin zazwyczaj wymagane jest środowisko DR (hot standby lub warm standby). Dla systemów z RTO 24+ godzin możliwe jest odtwarzanie z backupu bez dedykowanego środowiska DR. Decyzja powinna wynikać z BIA.
Co zrobić gdy backup jest zaszyfrowany przez ransomware?
Jeśli backup był połączony z siecią produkcyjną, może być zaszyfrowany. W takiej sytuacji: (1) sprawdź czy masz offline lub immutable backup (tape, object storage z object lock, air-gapped), (2) skontaktuj się z dostawcą rozwiązania backup – niektóre narzędzia mają wersjonowanie niemodyfikowalne, (3) sprawdź cloud provider snapshots (np. AWS S3 Glacier Vault Lock), (4) rozważ skontaktowanie się z firmą IR – w niektórych przypadkach możliwe jest częściowe odtworzenie zaszyfrowanych danych. To jest dokładnie sytuacja, której BCM powinien zapobiegać przez izolację backupu.
Ile kosztuje projekt BCM z Patronusec?
Zakres projektu BCM obejmuje BIA, identyfikację scenariuszy, tworzenie planów BCP/DRP i tabletop exercises. Koszt zależy od wielkości organizacji, liczby krytycznych procesów i poziomu dojrzałości BCM. Patronusec wycenia po bezpłatnej rozmowie. W modelu vCISO BCM jest jedną z funkcji prowadzoną przez nas ciągle.
Czy ISO 22301 jest wymagany czy wystarczy DORA/NIS2?
ISO 22301 to standard BCM – certyfikacja nie jest wymagana przez DORA ani NIS2, ale może być pomocna jako demonstracja dojrzałości. Wiele organizacji wdraża BCM zgodnie z ISO 22301 jako framework, bez certyfikacji. DORA i NIS2 definiują minimalne wymagania – ISO 22301 dostarcza bardziej kompletnego frameworku zarządczego.
Zarządzanie ciągłością działania (BCM) – bezpłatna konsultacja
Patronusec wspiera organizacje w budowie programów BCM odpornych na cyberataki – od BIA i analizy scenariuszy cyber, przez plany BCP/DRP, po testowanie i dokumentację wymaganą przez DORA i NIS2.
W bezpłatnej 30-minutowej konsultacji pomożemy Ci:
- Ocenić aktualne luki w programie BCM względem wymagań DORA i/lub NIS2
- Zidentyfikować krytyczne scenariusze cyber, których Twój plan BCM może nie uwzględniać
- Zaplanować projekt aktualizacji BCM lub tabletop exercise
- Wybrać model wsparcia: projekt jednorazowy lub ciągłe wsparcie vCISO
Bezpłatna konsultacja | vCISO – zarządzanie BCM | ISO 27001 wdrożenie | DORA compliance | NIS2 wdrożenie
