Plan ciągłości działania IT (BCP/DRP) —jak stworzyć i wdrożyć w firmie 10–100 osób

Wyobraź sobie poniedziałkowy poranek: przychodzisz do firmy, pracownicy nie mogą zalogować się do systemów, serwer plików nie odpowiada, a na ekranach widnieje komunikat żądający okupu w kryptowalucie. Co robisz? Kogo dzwonisz w pierwszej kolejności? Gdzie są kopie zapasowe? Ile czasu zajmie przywrócenie danych? Jeśli nie znasz odpowiedzi na te pytania z pamięci — nie masz planu ciągłości działania.

To nie jest scenariusz z thrillera. Według danych IBM Security, w 2025 roku ponad 7 000 ataków ransomware dotknęło polskie firmy. Średni koszt przestoju dla MŚP wynosi 73 000 zł dziennie. Plan ciągłości działania IT to nie luksus dla korporacji — to absolutna konieczność dla każdej firmy, która nie chce stracić danych, klientów i reputacji w jeden poranek.

Co to jest BCP i DRP? Różnica, której nie możesz ignorować

Terminy BCP i DRP są często używane zamiennie, co prowadzi do nieporozumień i luk w ochronie firmy. Oto precyzyjna definicja każdego z nich:

BCP — Business Continuity Plan (Plan ciągłości działania) to kompleksowy dokument opisujący, jak cała organizacja funkcjonuje w sytuacji kryzysowej. BCP obejmuje nie tylko IT, ale też procesy biznesowe, komunikację z klientami i dostawcami, role i odpowiedzialności pracowników, alternatywne lokalizacje pracy, zasady podejmowania decyzji pod presją czasu. To "mapa przetrwania" całej firmy w kryzysie.

DRP — Disaster Recovery Plan (Plan odtwarzania po awarii) to techniczny element BCP, skupiony wyłącznie na odtworzeniu infrastruktury IT. DRP odpowiada na pytania: jak przywrócić serwery? W jakiej kolejności uruchamiać systemy? Gdzie jest zapasowa kopia danych? Kto ma dostęp do backupu? Ile czasu zajmie migracja na środowisko awaryjne?

Kluczowy wniosek: DRP bez BCP to jak sprawny silnik bez karoserii. Technicznie odtworzysz serwery, ale firma może nie wiedzieć jak działać w czasie odtwarzania. Dobre rozwiązanie to zawsze oba dokumenty razem, wzajemnie się uzupełniające.

Dlaczego NIS2 wymaga planu ciągłości działania?

Dyrektywa NIS2 (Network and Information Security Directive 2), transponowana do polskiego prawa ustawą z, nakłada na szerokie grono podmiotów konkretne wymogi w zakresie zarządzania ciągłością działania. Dotyczy to zarówno podmiotów kluczowych (energetyka, banki, transport, ochrona zdrowia), jak i podmiotów ważnych — w tym wielu firm z sektora MŚP działających w usługach cyfrowych, dostawach, produkcji i administracji.

Artykuł 21 dyrektywy NIS2 wprost wymaga od podmiotów objętych regulacją wdrożenia:

• Planów ciągłości działania obejmujących zarządzanie kopiami zapasowymi, odtwarzanie po awarii i zarządzanie kryzysowe
• Procedur zarządzania incydentami — wykrywanie, reagowanie, raportowanie do CSIRT w ciągu 24 godzin od poważnego incydentu
• Regularnych testów planów i oceny ich skuteczności
• Szkolenia personelu odpowiedzialnego za realizację planów

Co istotne — NIS2 nie wymaga perfekcyjnego planu od pierwszego dnia. Wymaga jednak, aby firma podjęła adekwatne, proporcjonalne środki zarządzania ryzykiem. Dla MŚP oznacza to zazwyczaj: udokumentowany BCP/DRP, cykliczne testy backupu oraz procedure reagowania na incydenty. Brak jakiegokolwiek dokumentu to najgorsza pozycja startowa.

Analiza ryzyk IT — od czego zacząć (RTO, RPO, MTTR)

Zanim napiszesz plan, musisz zrozumieć, czego tak naprawdę się boisz i co jest dla Ciebie krytyczne. Analiza ryzyk to fundament każdego dobrego BCP. Składa się z dwóch etapów: inwentaryzacji systemów i zdefiniowania parametrów odtworzeniowych.

Trzy kluczowe wskaźniki: RTO, RPO, MTTR

RTO — Recovery Time Objective to maksymalny akceptowalny czas, przez jaki system może być niedostępny. Jeśli RTO dla Twojego systemu ERP wynosi 4 godziny, oznacza to, że po 4 godzinach od awarii system musi działać. RTO definiujesz jako właściciel firmy — bazując na realnych kosztach przestoju.

RPO — Recovery Point Objective to maksymalny wiek danych, które możesz utracić. RPO = 1 godzina oznacza, że backup musi być co najwyżej godzinny — możesz stracić maksymalnie godzinę transakcji. RPO = 24 godziny to backup dzienny — tracisz cały dzień pracy. Im niższe RPO, tym droższa infrastruktura replikacji danych.

MTTR — Mean Time To Recover to statystyczny, realny czas odtworzenia mierzony podczas testów lub rzeczywistych incydentów. MTTR powinien być niższy niż RTO. Jeśli Twoje RTO wynosi 4 godziny, ale MTTR w testach wychodzi 7 godzin — masz poważny problem i musisz zainwestować w infrastrukturę lub procedury.

Analiza ryzyk powinna objąć wszystkie krytyczne systemy IT: serwery plików, ERP, CRM, system pocztowy, strona www i e-commerce (jeśli dotyczy), systemy kasowe i POS, infrastrukturę sieciową i łączność internetową. Dla każdego systemu określasz RTO i RPO, a następnie weryfikujesz, czy obecna infrastruktura te parametry spełnia.

7 kluczowych elementów planu BCP/DRP

Skuteczny plan ciągłości działania nie jest dokumentem jednorazowym. To żywy zestaw procedur, który musi być regularnie testowany, aktualizowany i znany kluczowym pracownikom. Oto 7 elementów, bez których żaden BCP nie spełni swojego zadania:

1. Inwentaryzacja zasobów IT i mapowanie zależności — kompletna lista serwerów, stacji roboczych, licencji, dostawców usług chmurowych, połączeń sieciowych. Mapowanie, które systemy od których zależą (np. CRM wymaga bazy danych na serwerze X i SMTP serwera Y).
2. Analiza BIA (Business Impact Analysis) — ocena wpływu awarii poszczególnych systemów na działalność firmy. BIA pozwala ustalić priorytety odtwarzania: co uruchomić pierwsze? Bez BIA odtwarzasz systemy po kolei zamiast po priorytecie.
3. Strategia backupu i replikacji — harmonogram, lokalizacja (3-2-1: 3 kopie, 2 media, 1 off-site), szyfrowanie backupów, testy przywracania co najmniej raz na kwartał. Backup który nie był testowany to backup który nie istnieje.
4. Procedury reagowania na incydenty — krok po kroku: kto co robi w ciągu pierwszych 15 minut, godziny, doby. Numery telefonów, loginów, instrukcje dla każdej roli. Muszą działać nawet gdy kluczowy pracownik IT jest niedostępny.
5. Plan komunikacji kryzysowej — szablony wiadomości do pracowników, klientów, dostawców i (jeśli wymaga NIS2) do CSIRT. Kto jest rzecznikiem prasowym? Kto nie powinien komentować incydentu publicznie?
6. Środowisko awaryjne (failover) — czy masz gotowy backup serwer lub środowisko chmurowe do uruchomienia w razie awarii? Czy pracownicy mogą pracować zdalnie jeśli biuro jest niedostępne? Czy łącze internetowe jest zdublowane?
7. Harmonogram testów i przeglądów — pełny test DR co rok, testy tablicowe co kwartał, automatyczna weryfikacja backupu ciągle. Po każdym teście aktualizacja planu. Dokumentacja testów jako dowód zgodności z NIS2.

Scenariusze awarii i plany reakcji

Każdy plan musi być konkretny — nie "reaguj na incydenty" tylko "w przypadku ataku ransomware wykonaj kroki 1–12 z załącznika B". Poniżej tabela z najczęstszymi scenariuszami awarii w firmach 10–100 pracowników, typowym czasem przestoju bez planu i możliwym RTO przy dobrym BCP:

Testy planu ciągłości działania — jak i jak często?

Plan, który nigdy nie był testowany, nie jest planem — jest dokumentem. Testy BCP/DRP to jedyny sposób na weryfikację, czy Twoje procedury, czas reakcji i infrastruktura spełniają założone parametry RTO i RPO. Istnieją trzy główne typy testów:

1. Testy tablicowe (Tabletop Exercises)

Najtańsza i najłatwiejsza do przeprowadzenia forma testu. Kluczowi pracownicy zbierają się w sali konferencyjnej i "przechodzą przez" wybrany scenariusz awarii werbalnie. Moderator zadaje pytania: "Co robisz teraz?", "Kogo dzwonisz?", "Gdzie jest backup?". Celem jest identyfikacja luk w wiedzy, procedurach i komunikacji — bez realnego zakłócania systemów. Zalecana częstotliwość: co kwartał, czas: 2–3 godziny.

2. Testy funkcjonalne komponentów (Component Tests)

Testowanie konkretnych elementów infrastruktury: przywrócenie pojedynczego serwera z backupu, uruchomienie środowiska failover, przetestowanie zapasowego łącza internetowego, symulacja przełączenia pracy na tryb zdalny. Nie testujemy całego scenariusza — tylko konkretny element. Zalecana częstotliwość: co miesiąc dla backupu, co kwartał dla pozostałych.

3. Pełny test odtworzeniowy (Full DR Drill)

Symulacja pełnej awarii — odłączamy serwer produkcyjny i próbujemy w realnym czasie uruchomić środowisko awaryjne. Mierzymy dokładny czas odtworzenia (MTTR) i porównujemy z RTO. To najbardziej kosztowny test, ale jedyny który faktycznie potwierdza gotowość organizacji. Zalecana częstotliwość: minimum raz w roku. Przed testem — zawsze informacja dla pracowników i klientów o planowanym oknie serwisowym.

"Test BCP, który ujawnił że backupy nie działają, jest wart tyle samo co sukces — bo pozwolił naprawić problem zanim nastąpiła prawdziwa awaria." — Roman Kwiatkowski, CTO DSX.PL

BCP w DSX.PL — co oferujemy i ile to kosztuje

W DSX.PL oferujemy trzy poziomy zaangażowania w zakresie planu ciągłości działania. Dostosowujemy zakres do wielkości firmy, branży i wymogów regulacyjnych. Wszystkie ceny są podane netto, do kwot należy doliczyć VAT 23%.

Dojazd do klienta powyżej 15 km od Szczecina: 1,50 zł netto/km + 200 zł/h za czas dojazdu. Klientów w Szczecinie obsługujemy bez dopłat za dojazd.

Zespół DSX.PL

Specjaliści ds. bezpieczeństwa IT i ciągłości działania · Szczecin

Wdrażamy plany ciągłości działania IT dla firm z sektora MŚP w Szczecinie i całym województwie zachodniopomorskim. Pomagamy firmom spełniać wymogi NIS2 i ISO 22301 bez biurokratycznego bałaganu — konkretne dokumenty, sprawdzona infrastruktura, przeszkolony personel.