Ciągłość działania firmy – jak przygotować plan na awarie i sytuacje kryzysowe?

Ciągłość działania nie polega na przewidzeniu każdej możliwej awarii. Jej celem jest przygotowanie firmy tak, aby podczas zakłócenia utrzymała najważniejsze procesy na akceptowalnym poziomie, ograniczyła straty i możliwie szybko wróciła do normalnej pracy.

Z tego artykułu dowiesz się, jak przeprowadzić analizę wpływu na biznes, określić RTO i RPO, wybrać strategie awaryjne, przygotować plan ciągłości działania oraz sprawdzić go podczas testów. Poznasz także różnice między BCP, disaster recovery, zarządzaniem kryzysowym i reagowaniem na incydenty.

Czym jest ciągłość działania firmy?

Ciągłość działania, określana również jako Business Continuity, to zdolność organizacji do kontynuowania dostarczania kluczowych produktów i usług podczas awarii, incydentu lub sytuacji kryzysowej.

Nie oznacza to, że wszystkie procesy muszą działać bez przerwy. W praktyce firma ustala:

• które działania są krytyczne,
• jaki minimalny poziom obsługi trzeba utrzymać,
• jak długo proces może pozostawać niedostępny,
• ile danych można utracić,
• jakie zasoby są konieczne do wznowienia pracy,
• kto podejmuje decyzje w sytuacji kryzysowej,
• jak przebiega powrót do normalnego trybu działania.

Plan ciągłości działania, czyli Business Continuity Plan lub BCP, jest dokumentem operacyjnym opisującym sposób postępowania przed zakłóceniem, w jego trakcie i po jego zakończeniu.

Ciągłość działania a odporność organizacyjna

Ciągłość działania koncentruje się na utrzymaniu i odtworzeniu najważniejszych procesów. Odporność organizacyjna jest pojęciem szerszym. Obejmuje również zdolność firmy do adaptacji, podejmowania decyzji w warunkach niepewności i zmiany modelu działania po kryzysie.

Firma może mieć poprawnie przygotowany plan BCP, ale nadal nie być odporna, jeśli:

• decyzje zależą od jednej osoby,
• kluczowa wiedza nie jest udokumentowana,
• dostawców nie można zastąpić,
• pracownicy nie znają procedur,
• planów nie testuje się w praktyce,
• organizacja nie wyciąga wniosków z incydentów.

BCP, BCM, DRP i zarządzanie kryzysowe – najważniejsze różnice

Pojęcia związane z ciągłością działania często są używane zamiennie, mimo że mają inne znaczenie.

Pojęcie	Znaczenie	Główne pytanie
BCM	Business Continuity Management, czyli system zarządzania ciągłością działania	Jak stale zarządzać odpornością firmy?
BCP	Business Continuity Plan, czyli plan ciągłości działania	Jak utrzymać najważniejsze procesy podczas zakłócenia?
DRP	Disaster Recovery Plan, czyli plan odtworzenia środowiska IT	Jak odtworzyć systemy, dane i infrastrukturę techniczną?
Incident Response	Reagowanie na incydenty, najczęściej cyberbezpieczeństwa	Jak wykryć, ograniczyć i usunąć incydent?
Crisis Management	Zarządzanie kryzysowe	Jak podejmować decyzje i koordynować organizację w kryzysie?
Emergency Response	Reagowanie awaryjne	Jak chronić życie, zdrowie, środowisko i mienie?

DRP nie zastępuje planu ciągłości działania. Odtworzenie serwerów nie rozwiązuje problemu, jeśli firma nie ma dostępu do budynku, pracownicy są niedostępni albo kluczowy dostawca przestał realizować zamówienia.

Podobnie BCP nie zastępuje procedur bezpieczeństwa. W przypadku pożaru pierwszeństwo mają ewakuacja i ochrona życia, a dopiero później uruchomienie procesów awaryjnych.

Jakie zdarzenia powinien obejmować plan ciągłości działania?

Plan powinien być oparty przede wszystkim na skutkach zakłócenia, a nie na zamkniętej liście zagrożeń. Firma może nie przewidzieć konkretnej przyczyny awarii, ale może przygotować się na utratę określonego zasobu.

Najczęstsze kategorie zakłóceń to:

• niedostępność systemów informatycznych,
• utrata lub uszkodzenie danych,
• atak ransomware,
• awaria zasilania lub łączności,
• brak dostępu do biura, magazynu albo zakładu,
• niedostępność pracowników,
• awaria maszyn lub linii produkcyjnej,
• przerwanie łańcucha dostaw,
• niewypłacalność kluczowego kontrahenta,
• zakłócenia transportu i logistyki,
• kryzys reputacyjny,
• skażenie, pożar, zalanie lub katastrofa budowlana,
• epidemia lub masowa absencja,
• naruszenie ochrony danych,
• konflikt geopolityczny lub nagła zmiana regulacyjna.

Praktyczniejsze od tworzenia osobnej procedury na każdy scenariusz jest przygotowanie planów dla skutków takich jak:

1. brak ludzi,
2. brak lokalizacji,
3. brak technologii,
4. brak danych,
5. brak dostawcy,
6. brak komunikacji,
7. brak mediów lub infrastruktury technicznej.

Takie podejście pozwala wykorzystać te same rozwiązania w wielu różnych sytuacjach.

Od czego zacząć przygotowanie planu ciągłości działania?

Punktem wyjścia nie powinien być zakup dodatkowego serwera ani skopiowanie gotowego szablonu BCP. Najpierw należy ustalić kontekst organizacji i zakres programu.

Określ zakres

Zakres może obejmować:

• całą organizację,
• wybraną spółkę,
• określoną lokalizację,
• linię biznesową,
• usługę świadczoną klientom,
• proces podlegający wymaganiom regulacyjnym.

Na początku warto odpowiedzieć na kilka pytań:

• Jakie produkty i usługi są najważniejsze?
• Których klientów dotknie przerwa?
• Jakie zobowiązania umowne musi spełnić firma?
• Jakie przepisy mają zastosowanie?
• Które lokalizacje, systemy i podmioty zewnętrzne są w zakresie?
• Kto zatwierdza poziom akceptowanego ryzyka?

Wyznacz właściciela programu

Za ciągłość działania nie powinien odpowiadać wyłącznie dział IT. Potrzebny jest właściciel programu posiadający mandat kierownictwa i możliwość angażowania właścicieli procesów.

Typowy podział odpowiedzialności obejmuje:

• zarząd – akceptacja ryzyka, priorytetów i budżetu,
• koordynator BCM – utrzymanie metodyki i planów,
• właściciele procesów – określenie wymagań biznesowych,
• IT – odtworzenie systemów, infrastruktury i danych,
• bezpieczeństwo – obsługa incydentów i zagrożeń,
• HR – dostępność pracowników i komunikacja wewnętrzna,
• administracja – budynki, media i miejsca zastępcze,
• zakupy – ciągłość dostawców,
• komunikacja i PR – przekazy dla klientów, mediów i partnerów,
• dział prawny lub compliance – obowiązki regulacyjne i umowne.

Dla każdej roli należy wskazać zastępcę. Plan zależny od jednej osoby zawiera pojedynczy punkt awarii.

Analiza wpływu na biznes, czyli BIA

Business Impact Analysis pozwala ustalić, które procesy są krytyczne i jak zmieniają się skutki ich niedostępności w czasie. BIA stanowi podstawę do określenia priorytetów odtworzenia.

Co należy analizować?

Dla każdego procesu warto zebrać co najmniej:

• nazwę i właściciela procesu,
• dostarczany produkt lub usługę,
• odbiorców procesu,
• okresy szczególnej wrażliwości,
• skutki przerwy po kilku godzinach i dniach,
• zależności od ludzi, technologii i lokalizacji,
• wymagane dane,
• kluczowych dostawców,
• minimalną liczbę pracowników,
• ręczne procedury zastępcze,
• wymagany czas wznowienia,
• wymagany punkt odtworzenia danych.

Skutki należy oceniać w kilku wymiarach:

• finansowym,
• operacyjnym,
• prawnym i regulacyjnym,
• umownym,
• reputacyjnym,
• dotyczącym bezpieczeństwa ludzi,
• dotyczącym klientów i partnerów,
• środowiskowym.

RTO, RPO, MTPD i minimalny poziom działania

W analizie ciągłości działania stosuje się kilka podstawowych parametrów.

RTO – Recovery Time Objective

Docelowy czas wznowienia procesu lub systemu po zakłóceniu. RTO wynoszące cztery godziny oznacza, że rozwiązanie powinno pozwolić na przywrócenie działania w ciągu maksymalnie czterech godzin.

RPO – Recovery Point Objective

Maksymalna akceptowana utrata danych wyrażona w czasie. RPO wynoszące 30 minut oznacza, że po awarii firma powinna odtworzyć dane nie starsze niż 30 minut przed zdarzeniem.

MTPD – Maximum Tolerable Period of Disruption

Najdłuższy czas zakłócenia, po którym skutki stają się nieakceptowalne dla organizacji.

MBCO – Minimum Business Continuity Objective

Minimalny akceptowany poziom dostarczania produktu lub usługi podczas zakłócenia.

RTO powinno być krótsze niż maksymalny tolerowany czas przerwy. Musi również uwzględniać czas potrzebny na wykrycie zdarzenia, decyzję o aktywacji planu i uruchomienie zasobów zastępczych.

Przykład określenia parametrów

Sklep internetowy może przyjąć następujące wymagania:

• platforma sprzedażowa: RTO 2 godziny, RPO 15 minut,
• system magazynowy: RTO 4 godziny, RPO 1 godzina,
• księgowość: RTO 48 godzin, RPO 24 godziny,
• raportowanie zarządcze: RTO 5 dni, RPO 24 godziny.

Nie każdy system wymaga więc dostępności w trybie 24/7. Priorytety powinny wynikać ze skutków biznesowych, a nie z przekonania właściciela systemu o jego ważności.

Ocena ryzyka i scenariusze kryzysowe

BIA odpowiada na pytanie, co się stanie, gdy proces przestanie działać. Ocena ryzyka pomaga ustalić, dlaczego może do tego dojść i jakie zabezpieczenia warto wdrożyć.

Jak przeprowadzić ocenę ryzyka?

Podstawowy proces obejmuje:

1. identyfikację zagrożeń,
2. wskazanie podatności,
3. ocenę prawdopodobieństwa,
4. ocenę wpływu,
5. analizę istniejących zabezpieczeń,
6. określenie ryzyka rezydualnego,
7. wybór sposobu postępowania z ryzykiem.

Ryzyko można:

• ograniczyć,
• przenieść, np. przez ubezpieczenie lub umowę,
• unikać,
• zaakceptować.

Ubezpieczenie może zmniejszyć skutek finansowy, ale nie odtworzy relacji z klientem ani nie uruchomi procesu. Nie jest więc zamiennikiem planu ciągłości działania.

Scenariusze, które warto przećwiczyć

Dobrze przygotowany program powinien obejmować między innymi:

• ransomware blokujący systemy i kopie online,
• awarię dostawcy chmurowego,
• całkowitą utratę łączności,
• brak dostępu do głównej lokalizacji,
• jednoczesną niedostępność kilku kluczowych osób,
• uszkodzenie systemu ERP,
• utratę danych po błędzie administratora,
• przerwanie dostaw krytycznego komponentu,
• ujawnienie poufnych danych,
• kryzys medialny związany z awarią usługi.

Warto uwzględniać zdarzenia złożone. Przykładem jest cyberatak przeprowadzony w okresie zwiększonej sprzedaży, przy ograniczonej dostępności pracowników i jednoczesnych problemach dostawcy.

Strategie ciągłości działania

Strategia określa, w jaki sposób firma spełni wymagania ustalone podczas BIA. Powinna być wybrana przed napisaniem szczegółowej procedury.

Strategie dotyczące pracowników

Możliwe rozwiązania to:

• wyznaczenie zastępców,
• szkolenie krzyżowe pracowników,
• dokumentowanie wiedzy operacyjnej,
• podział zespołów między lokalizacje,
• praca zdalna,
• umowy z agencjami pracy,
• utrzymywanie listy osób z kluczowymi uprawnieniami,
• rotacja ról i obowiązków.

Należy sprawdzić nie tylko liczbę pracowników, ale też dostępność kompetencji, pełnomocnictw, tokenów, certyfikatów i uprawnień systemowych.

Strategie dotyczące lokalizacji

Firma może wykorzystać:

• pracę zdalną,
• drugą własną lokalizację,
• przestrzeń coworkingową,
• umowę na biuro zastępcze,
• wzajemną pomoc między oddziałami,
• relokację produkcji lub magazynowania.

Miejsce zastępcze powinno mieć dostęp do sprzętu, sieci, dokumentów i wymaganych zabezpieczeń. Sam adres rezerwowego biura nie jest jeszcze strategią ciągłości.

Strategie technologiczne

Najczęstsze rozwiązania obejmują:

• redundancję urządzeń i łączy,
• klaster wysokiej dostępności,
• replikację danych,
• zapasowe centrum przetwarzania,
• rozwiązania wielostrefowe lub wieloregionowe,
• usługę disaster recovery,
• ręczne procedury zastępcze,
• odtworzenie z kopii zapasowych.

Im krótsze RTO i RPO, tym zwykle wyższy koszt rozwiązania. Wymaganie zerowej utraty danych oraz natychmiastowego przełączenia powinno być zarezerwowane dla procesów, które rzeczywiście tego potrzebują.

Strategie dotyczące dostawców

W przypadku krytycznych dostaw warto rozważyć:

• drugiego zatwierdzonego dostawcę,
• zapas bezpieczeństwa,
• dostawy z różnych regionów,
• alternatywne komponenty,
• możliwość przeniesienia produkcji,
• umowne czasy reakcji i odtworzenia,
• dostęp do danych po zakończeniu współpracy,
• regularną ocenę kondycji dostawcy.

Dwóch dostawców nie zapewnia odporności, jeśli korzystają z tego samego producenta, centrum danych, operatora logistycznego albo podwykonawcy.

Kopie zapasowe i odtwarzanie danych

Backup jest jednym z elementów ciągłości działania, ale sam w sobie nie gwarantuje możliwości wznowienia pracy.

Reguła 3-2-1-1-0

Praktycznym modelem organizacji kopii zapasowych jest:

• co najmniej 3 kopie danych,
• na 2 różnych typach nośników lub platform,
• 1 kopia poza główną lokalizacją,
• 1 kopia offline, odłączona lub niemodyfikowalna,
• 0 błędów potwierdzonych podczas testu odtworzeniowego.

Kopie powinny być:

• szyfrowane,
• chronione przed zmianą i usunięciem,
• objęte kontrolą dostępu,
• monitorowane,
• przechowywane zgodnie z retencją,
• regularnie odtwarzane testowo.

Synchronizacja nie zawsze jest backupem. Błędne usunięcie, zaszyfrowanie albo uszkodzenie danych może zostać automatycznie przeniesione do środowiska zapasowego.

Co powinien zawierać plan disaster recovery?

Plan DR powinien określać:

• kolejność odtwarzania systemów,
• zależności między aplikacjami,
• lokalizację kopii i instrukcji,
• sposób uzyskania awaryjnego dostępu,
• osoby uprawnione do uruchomienia procedury,
• parametry RTO i RPO,
• wymagania dotyczące sieci i tożsamości,
• sposób weryfikacji integralności danych,
• kryteria powrotu do środowiska podstawowego.

Trzeba uwzględnić usługi bazowe, takie jak DNS, katalog użytkowników, uwierzytelnianie, certyfikaty, zarządzanie kluczami, monitoring i dostęp administratorów. Odtworzenie aplikacji bez tych zależności może być niemożliwe.

Co powinien zawierać plan ciągłości działania?

Plan powinien być na tyle krótki, aby można było z niego korzystać pod presją czasu, a jednocześnie wystarczająco konkretny, aby ograniczyć improwizację.

Minimalna struktura BCP

Dobry plan obejmuje:

1. cel i zakres,
2. kryteria aktywacji,
3. role oraz odpowiedzialności,
4. dane kontaktowe i zastępstwa,
5. listę procesów krytycznych,
6. wymagane RTO, RPO i minimalny poziom działania,
7. procedury awaryjne,
8. zasoby i zależności,
9. zasady komunikacji,
10. ścieżkę eskalacji,
11. sposób dokumentowania decyzji,
12. plan odtworzenia i powrotu do normalnej pracy,
13. datę przeglądu oraz historię zmian.

Kryteria aktywacji i eskalacji

Plan powinien wskazywać, kto może go aktywować i na podstawie jakich przesłanek. Przykładowe kryteria to:

• przewidywane przekroczenie RTO,
• brak dostępu do lokalizacji,
• niedostępność kluczowego systemu,
• istotne zagrożenie dla klientów,
• ryzyko naruszenia obowiązków prawnych,
• konieczność zaangażowania wielu działów,
• duże zainteresowanie mediów,
• zdarzenie zagrażające życiu lub zdrowiu.

Warto stosować poziomy incydentu, np. operacyjny, poważny i kryzysowy. Każdy poziom powinien uruchamiać określony skład zespołu, rytm raportowania i zakres uprawnień.

Lista kontaktowa

Lista kontaktowa musi działać również wtedy, gdy niedostępne są firmowe systemy. Powinna obejmować:

• członków zespołu kryzysowego,
• zastępców,
• administratorów,
• właścicieli procesów,
• dostawców,
• operatorów infrastruktury,
• ubezpieczyciela,
• kancelarię lub doradców,
• kontakty do służb i organów właściwych dla organizacji.

Dane należy chronić, aktualizować i udostępniać tylko osobom, które rzeczywiście ich potrzebują.

Zespół kryzysowy i podejmowanie decyzji

Zespół kryzysowy powinien być niewielki i mieć jasno określone uprawnienia. Zbyt wiele osób utrudnia podejmowanie decyzji, a zbyt mało zwiększa ryzyko pominięcia ważnej perspektywy.

Typowy skład obejmuje:

• lidera kryzysowego,
• koordynatora operacyjnego,
• przedstawiciela IT lub bezpieczeństwa,
• przedstawiciela biznesu,
• HR,
• komunikację,
• prawo lub compliance,
• osobę prowadzącą rejestr decyzji.

Zespół powinien pracować w ustalonym rytmie. Każde spotkanie może obejmować:

1. aktualny stan zdarzenia,
2. wpływ na ludzi, klientów i procesy,
3. podjęte działania,
4. najważniejsze ryzyka,
5. decyzje wymagane od zespołu,
6. właścicieli zadań i terminy,
7. termin kolejnej aktualizacji.

W sytuacji kryzysowej należy prowadzić dziennik zdarzeń. Powinien zawierać czas, źródło informacji, decyzję, osobę zatwierdzającą i uzasadnienie.

Komunikacja kryzysowa

Brak informacji szybko prowadzi do plotek, sprzecznych komunikatów i utraty zaufania. Plan komunikacji powinien obejmować pracowników, klientów, partnerów, dostawców, organy publiczne i media.

Co przygotować przed kryzysem?

Warto opracować:

• alternatywne kanały komunikacji,
• listy dystrybucyjne,
• szablony komunikatów,
• zasady akceptacji treści,
• listę rzeczników,
• stronę statusową,
• komunikaty dla najważniejszych scenariuszy,
• procedurę monitorowania pytań i reakcji odbiorców.

Komunikat kryzysowy powinien odpowiadać na pytania:

• co się wydarzyło,
• kogo dotyczy sytuacja,
• co robi firma,
• co powinien zrobić odbiorca,
• kiedy pojawi się kolejna aktualizacja.

Nie należy publikować niepotwierdzonych przyczyn ani deklarować terminu przywrócenia usługi, jeśli zespół nie ma wystarczających danych.

Ciągłość łańcucha dostaw

Dostawcy mogą być równie krytyczni jak własne systemy i pracownicy. Ocena powinna uwzględniać nie tylko wartość zakupów, ale także możliwość zastąpienia usługi.

Dla kluczowych podmiotów warto sprawdzić:

• czas potrzebny na zmianę dostawcy,
• zależność od podwykonawców,
• lokalizację infrastruktury i produkcji,
• plany ciągłości działania,
• wyniki testów,
• zdolność do zgłoszenia incydentu,
• możliwość odzyskania danych,
• warunki rozwiązania umowy,
• plan wyjścia i migracji.

W umowach można określić wymagania dotyczące:

• dostępności,
• czasu reakcji,
• czasu odtworzenia,
• informowania o incydentach,
• testów ciągłości,
• kopii i zwrotu danych,
• korzystania z podwykonawców,
• współpracy podczas kryzysu.

SLA nie gwarantuje ciągłości. Kara umowna może zrekompensować część strat, ale nie przywróci usługi klientom.

Tabela decyzyjna: jaki plan uruchomić?

Sytuacja	Pierwszy priorytet	Plan wiodący	Dodatkowe działania	Przykładowe kryterium eskalacji
Pożar lub zagrożenie życia	Ochrona ludzi i ewakuacja	Plan reagowania awaryjnego	BCP dla lokalizacji, komunikacja kryzysowa	Brak dostępu do obiektu po zakończeniu akcji
Awaria pojedynczej aplikacji	Ograniczenie skutków operacyjnych	Procedura obsługi incydentu IT	DRP, jeśli naprawa przekroczy RTO	Przewidywane przekroczenie RTO
Awaria centrum danych	Utrzymanie usług krytycznych	DRP	BCP procesów zależnych, komunikacja	Brak możliwości szybkiego odtworzenia lokalnego
Atak ransomware	Izolacja i ograniczenie rozprzestrzeniania	Plan reagowania na incydenty	DRP, BCP, procedury prawne i komunikacyjne	Zaszyfrowanie systemów krytycznych lub kopii
Niedostępność biura	Ochrona ludzi i uruchomienie pracy zastępczej	BCP lokalizacyjny	Praca zdalna, relokacja zespołu	Niedostępność dłuższa niż tolerancja procesu
Brak kluczowych pracowników	Utrzymanie minimalnej obsady	BCP personalny	Zastępstwa, zmiana priorytetów, outsourcing	Brak wymaganych kompetencji lub uprawnień
Awaria dostawcy chmurowego	Utrzymanie procesów krytycznych	BCP i plan dostawcy	Tryb ręczny, przełączenie, komunikacja	Awaria przekracza uzgodnione RTO
Utrata danych	Zatrzymanie dalszych zmian i zabezpieczenie dowodów	DRP	Ocena naruszenia, odtworzenie z kopii	Utrata przekracza RPO
Przerwanie dostaw	Ochrona produkcji i obsługi klientów	Plan ciągłości łańcucha dostaw	Zapas, drugi dostawca, zamienniki	Wyczerpanie zapasu przed wznowieniem dostaw
Kryzys medialny	Spójna i szybka komunikacja	Plan komunikacji kryzysowej	Zespół kryzysowy, analiza prawna	Istotne ryzyko reputacyjne lub zainteresowanie mediów

Testowanie planu ciągłości działania

Nieprzetestowany plan jest zbiorem założeń. Testy pokazują, czy dane kontaktowe, procedury, zasoby i czasy odtworzenia są realistyczne.

Rodzaje testów

Przegląd dokumentacji

Weryfikacja kompletności planu, danych kontaktowych i zgodności z aktualną organizacją.

Test powiadamiania

Sprawdzenie, czy można skontaktować się z członkami zespołu i ich zastępcami.

Ćwiczenie typu tabletop

Uczestnicy omawiają działania dla przygotowanego scenariusza. To dobry sposób na sprawdzenie decyzji i współpracy między działami.

Test techniczny

Obejmuje odtworzenie danych, przełączenie usługi albo uruchomienie środowiska zapasowego.

Symulacja operacyjna

Wybrane zespoły realizują proces z użyciem procedur zastępczych.

Pełny test

Firma przełącza rzeczywiste procesy lub infrastrukturę. Taki test daje najwięcej informacji, ale wymaga starannego przygotowania i kontroli ryzyka.

Jak często testować BCP?

Częstotliwość powinna zależeć od krytyczności procesu i tempa zmian. Praktyczny model zakłada:

• aktualizację danych kontaktowych co kwartał,
• ćwiczenie scenariuszowe co najmniej raz w roku,
• regularne testy odtwarzania kopii,
• test po istotnej zmianie systemu, lokalizacji lub dostawcy,
• dodatkowy przegląd po każdym poważnym incydencie.

Procesy o krótkim RTO lub wysokim wpływie mogą wymagać testów kilka razy w roku.

Co mierzyć podczas testów?

Warto rejestrować:

• czas wykrycia zdarzenia,
• czas eskalacji,
• czas aktywacji planu,
• czas powiadomienia zespołu,
• faktyczny czas wznowienia,
• osiągnięty punkt odtworzenia danych,
• liczbę nieaktualnych kontaktów,
• liczbę niespełnionych założeń,
• skuteczność procedur ręcznych,
• czas powrotu do normalnej pracy.

Po ćwiczeniu należy przygotować listę działań naprawczych z właścicielami i terminami. Sam raport bez realizacji zaleceń nie zwiększa odporności.

Powrót do normalnego działania

Wznowienie procesu w trybie awaryjnym nie kończy obsługi kryzysu. Potrzebny jest plan powrotu do standardowego środowiska.

Powinien on określać:

• kryteria zakończenia trybu awaryjnego,
• sposób synchronizacji danych,
• kontrolę kompletności transakcji,
• kolejność wyłączania rozwiązań tymczasowych,
• informowanie klientów i pracowników,
• rozliczenie zaległych zadań,
• potwierdzenie bezpieczeństwa środowiska,
• formalne zamknięcie zdarzenia.

Przed powrotem trzeba sprawdzić, czy przyczyna awarii została usunięta. Zbyt szybkie przełączenie może doprowadzić do ponownego incydentu.

Wymagania prawne, umowne i standardy

Zakres obowiązków zależy od branży, rodzaju usług, skali firmy i przetwarzanych danych. Szczególne wymagania mogą dotyczyć między innymi finansów, ochrony zdrowia, energetyki, transportu, telekomunikacji, infrastruktury cyfrowej i administracji.

Przy projektowaniu programu należy uwzględnić:

• ochronę danych osobowych,
• cyberbezpieczeństwo,
• bezpieczeństwo pracowników,
• wymagania sektorowe,
• obowiązki raportowania incydentów,
• warunki umów z klientami,
• wymagania ubezpieczeniowe,
• wymagania dotyczące dokumentacji i retencji.

W przypadku naruszenia ochrony danych osobowych może obowiązywać termin 72 godzin na zgłoszenie naruszenia organowi nadzorczemu, jeśli spełnione są przesłanki zgłoszenia. Nie należy jednak traktować 72 godzin jako dopuszczalnego czasu reakcji operacyjnej. Analiza i ograniczanie skutków powinny rozpocząć się niezwłocznie.

Punktem odniesienia dla systemowego zarządzania ciągłością działania jest ISO 22301. W obszarze IT przydatne są także standardy i dobre praktyki dotyczące bezpieczeństwa informacji, zarządzania incydentami, kopii zapasowych oraz odtwarzania po awarii.

Sama zgodność ze standardem nie gwarantuje skuteczności planu. Najważniejsze pozostają realne zdolności operacyjne potwierdzone testami.

Liczby i statystyki dotyczące ciągłości działania

Dane z globalnych analiz pokazują skalę potencjalnych skutków awarii i cyberincydentów:

• średni globalny koszt naruszenia danych raportowany w 2024 roku wyniósł około 4,88 mln USD,
• średni czas identyfikacji i opanowania naruszenia danych liczono w 2024 roku na około 258 dni,
• w globalnych badaniach poważnych awarii centrów danych ponad dwie trzecie incydentów wiązało się z kosztami przekraczającymi 100 tys. USD,
• około 16% analizowanych poważnych awarii generowało koszty przekraczające 1 mln USD,
• 72 godziny to istotny termin prawny związany z określonymi zgłoszeniami naruszeń ochrony danych, a nie zalecany czas odtworzenia systemu.

Wartości globalne nie powinny być bezpośrednio przenoszone do budżetu konkretnej firmy. Koszt przerwy zależy od branży, skali działalności, sezonowości, kar umownych, liczby klientów i czasu niedostępności.

Jak obliczyć własny koszt przestoju?

Uproszczony model może uwzględniać:

Koszt przestoju = utracona marża + koszty dodatkowe + kary i rekompensaty + koszt odtworzenia + koszt zaległości + oszacowany wpływ reputacyjny

Do kalkulacji warto dodać:

• sprzedaż przypadającą na godzinę,
• wynagrodzenia pracowników, którzy nie mogą pracować,
• koszt pracy awaryjnej i nadgodzin,
• koszt zewnętrznych ekspertów,
• utracone lub opóźnione transakcje,
• koszt pozyskania klientów, którzy zrezygnowali,
• kary umowne i regulacyjne,
• koszty komunikacji i obsługi reklamacji.

Wewnętrzne wskaźniki skuteczności BCM

Organizacja może monitorować:

• odsetek procesów objętych aktualną analizą BIA,
• odsetek planów z wyznaczonym właścicielem i zastępcą,
• odsetek testów zakończonych osiągnięciem RTO,
• odsetek odtworzeń spełniających RPO,
• skuteczność testów kopii zapasowych,
• czas aktywacji zespołu kryzysowego,
• liczbę niezamkniętych działań po testach,
• odsetek krytycznych dostawców poddanych ocenie,
• odsetek pracowników przeszkolonych z procedur,
• liczbę pojedynczych punktów awarii bez planu ograniczenia ryzyka.

Najczęstsze błędy przy tworzeniu BCP

Plan przygotowany wyłącznie przez IT

Ciągłość działania dotyczy procesów biznesowych, pracowników, lokalizacji, dostawców i komunikacji. IT jest kluczowym uczestnikiem, ale nie powinno samodzielnie definiować priorytetów biznesowych.

Nierealistyczne RTO i RPO

Wymagania „zero przestoju” i „zero utraty danych” brzmią bezpiecznie, lecz mogą wymagać kosztownej architektury. Parametry powinny wynikać z BIA i być uzgodnione z właścicielem budżetu.

Brak uwzględnienia zależności

System może zostać odtworzony, ale nadal nie działać bez katalogu użytkowników, sieci, certyfikatów, danych z innej aplikacji albo dostępu dostawcy.

Przechowywanie planu tylko w niedostępnym systemie

Jeśli BCP znajduje się wyłącznie w firmowym środowisku, może być niedostępny podczas cyberataku lub awarii. Kontrolowana kopia powinna być dostępna również poza podstawową infrastrukturą.

Brak zastępców

Nieobecność jednej osoby nie może uniemożliwiać uruchomienia procedury, wykonania płatności, kontaktu z dostawcą lub odtworzenia systemu.

Testowanie wyłącznie na papierze

Ćwiczenia dyskusyjne są potrzebne, ale nie potwierdzają, że kopię można odtworzyć, pracownicy połączą się z systemem zastępczym, a procedura ręczna obsłuży rzeczywisty wolumen.

Brak aktualizacji po zmianach

Plan może stracić aktualność po migracji do chmury, zmianie dostawcy, reorganizacji, przejęciu spółki, wdrożeniu nowego ERP lub zmianie lokalizacji.

Mity dotyczące ciągłości działania

„Backup oznacza, że mamy ciągłość działania”

Backup odpowiada głównie na potrzebę odtworzenia danych. Nie zapewnia pracowników, komunikacji, miejsca pracy, systemów zastępczych ani ciągłości dostaw.

„Chmura nie ulega awariom”

Usługi chmurowe zwiększają możliwości budowania odporności, ale nadal mogą być niedostępne. Problemem może być region, konfiguracja, konto klienta, tożsamość, sieć lub zależność od jednej usługi.

„Mała firma nie potrzebuje BCP”

Małe firmy często mają mniej zasobów i więcej pojedynczych punktów awarii. Plan może być prostszy, ale powinien obejmować krytyczne procesy, dane, dostawców, kontakty i zastępstwa.

„Plan wystarczy napisać raz”

BCP jest elementem cyklu zarządzania. Musi być aktualizowany po zmianach, testach i incydentach.

„Każdy proces musi zostać odtworzony natychmiast”

Procesy mają różną krytyczność. Priorytetyzacja pozwala przeznaczyć ograniczone zasoby na działania o największym wpływie.

Jak wdrożyć ciągłość działania krok po kroku?

Praktyczny plan wdrożenia może wyglądać następująco:

1. uzyskaj mandat zarządu i wyznacz właściciela BCM,
2. określ zakres organizacyjny oraz regulacyjny,
3. zinwentaryzuj produkty, usługi i procesy,
4. przeprowadź analizę BIA,
5. określ RTO, RPO, MTPD i minimalny poziom działania,
6. zidentyfikuj zależności i pojedyncze punkty awarii,
7. przeprowadź ocenę ryzyka,
8. wybierz strategie ciągłości,
9. przygotuj BCP, DRP i plan komunikacji,
10. uzgodnij role, zastępstwa i uprawnienia,
11. zabezpiecz kopie planów oraz dane kontaktowe,
12. przeszkol pracowników,
13. przeprowadź ćwiczenie scenariuszowe,
14. wykonaj test techniczny odtworzenia,
15. usuń wykryte luki,
16. ustal cykl przeglądów i raportowania do kierownictwa.

W małej organizacji pierwsza wersja planu może obejmować kilka najważniejszych procesów i scenariuszy. Lepiej wdrożyć prosty, przetestowany plan niż tworzyć przez wiele miesięcy rozbudowaną dokumentację, której nikt nie potrafi użyć.

Powiązane obszary, które warto rozwijać

Strona poświęcona ciągłości działania powinna prowadzić do bardziej szczegółowych materiałów dotyczących:

• analizy wpływu na biznes BIA,
• wyznaczania RTO i RPO,
• przygotowania planu disaster recovery,
• zasad tworzenia kopii zapasowych,
• reagowania na ransomware,
• komunikacji kryzysowej,
• oceny ciągłości działania dostawców,
• testów i ćwiczeń BCP,
• zarządzania incydentami,
• wymagań ISO 22301,
• planowania pracy z lokalizacji zastępczej,
• budowania zespołu zarządzania kryzysowego.

FAQ – ciągłość działania firmy

Co to jest plan ciągłości działania?

Plan ciągłości działania to zestaw ról, zasad i procedur umożliwiających utrzymanie lub szybkie wznowienie najważniejszych procesów podczas awarii albo kryzysu.

Kto powinien odpowiadać za BCP?

Program powinien mieć właściciela posiadającego wsparcie zarządu. Za poszczególne plany odpowiadają właściciele procesów, natomiast IT, HR, administracja, zakupy, bezpieczeństwo i komunikacja wspierają ich w swoich obszarach.

Czy BCP jest obowiązkowy?

Obowiązek zależy od branży, rodzaju organizacji, przepisów i umów. Nawet jeśli firma nie podlega bezpośredniemu wymaganiu przygotowania BCP, klienci, ubezpieczyciele lub partnerzy mogą oczekiwać potwierdzenia zdolności do utrzymania usług.

Jak długi powinien być plan ciągłości działania?

Nie ma jednej prawidłowej długości. Plan powinien być zwięzły i użyteczny podczas kryzysu. Rozbudowane instrukcje techniczne można umieścić w załącznikach lub osobnych procedurach.

Jak często aktualizować BCP?

Co najmniej raz w roku oraz po istotnej zmianie organizacyjnej, technologicznej, lokalizacyjnej lub dostawczej. Dane kontaktowe warto weryfikować częściej.

Jak często testować kopie zapasowe?

Częstotliwość powinna wynikać z krytyczności danych i RPO. Kluczowe jest regularne wykonywanie pełnych testów odtworzenia, a nie wyłącznie sprawdzanie, czy zadanie backupu zakończyło się komunikatem o sukcesie.

Czym różni się RTO od RPO?

RTO określa docelowy czas wznowienia działania. RPO określa maksymalną akceptowaną utratę danych wyrażoną w czasie.

Czy RTO oznacza gwarantowany czas przywrócenia?

Nie. RTO jest wymaganiem projektowym i celem. Jego wykonalność należy potwierdzić poprzez odpowiednią strategię, zasoby i testy.

Czy plan awaryjny może opierać się na pracy ręcznej?

Tak, jeśli ręczny tryb pozwala utrzymać minimalny poziom działania i został przetestowany. Trzeba jednak uwzględnić jego przepustowość, ryzyko błędów i późniejsze wprowadzenie danych do systemu.

Co jest najważniejsze w pierwszych godzinach kryzysu?

Ochrona ludzi, ocena sytuacji, ograniczenie skutków, uruchomienie właściwego zespołu, zachowanie wiarygodnych informacji i utrzymanie procesów o najwyższym priorytecie.

Jak sprawdzić, czy plan jest skuteczny?

Należy przeprowadzać ćwiczenia scenariuszowe, testy powiadamiania, odtwarzanie kopii, przełączenia techniczne i symulacje operacyjne. Wyniki powinny być mierzone względem RTO, RPO i minimalnego poziomu działania.

Ile kosztuje przygotowanie ciągłości działania?

Koszt zależy od skali firmy, liczby procesów, wymaganych czasów odtworzenia i przyjętych strategii. Najdroższe są zwykle rozwiązania zapewniające bardzo krótkie RTO, minimalne RPO oraz pełną redundancję. Wydatki należy porównywać z możliwym kosztem przestoju.

Od jakich procesów zacząć?

Od tych, których przerwanie najszybciej zagraża ludziom, klientom, płynności finansowej, zgodności z prawem lub realizacji kluczowych usług. Kolejność powinna wynikać z analizy BIA.

Podsumowanie

Skuteczna ciągłość działania łączy analizę biznesową, zarządzanie ryzykiem, odporność technologiczną, przygotowanie pracowników, nadzór nad dostawcami i komunikację kryzysową. Najważniejszym rezultatem nie jest dokument, lecz potwierdzona zdolność organizacji do działania pod presją.

Dobry program BCM powinien odpowiadać na cztery pytania: co jest krytyczne, jak długo może nie działać, jak zostanie wznowione i czy wybrane rozwiązanie zostało sprawdzone. Jeżeli firma nie potrafi udzielić na nie konkretnych odpowiedzi, jej plan wymaga dalszego przygotowania lub testów.