ISO 22301 a SZBI i NIS2 – jak połączyć BCP, DRP i ciągłość działania?

ISO 22301 a NIS2 opisują dwa różne, ale uzupełniające się poziomy odporności organizacji. NIS2 i ustawa o krajowym systemie cyberbezpieczeństwa wymagają ciągłości działania, zarządzania kopiami zapasowymi, odtwarzania systemów i reagowania kryzysowego. ISO 22301 pokazuje natomiast, jak zbudować system, w którym BCP i DRP wynikają z analizy wpływu na biznes, mają właścicieli, mierzalne cele oraz są regularnie testowane.

ISO 22301 a NIS2 – skąd wynika obowiązek ciągłości działania?

Art. 21 ust. 2 lit. c dyrektywy NIS2 wymienia ciągłość działania, taką jak zarządzanie kopiami zapasowymi i odtwarzanie awaryjne, a także zarządzanie kryzysowe. Polski ustawodawca rozwinął ten obszar w art. 8 ust. 1 pkt 2 lit. f UoKSC. Podmiot kluczowy lub ważny ma wdrażać, dokumentować, testować i utrzymywać plany ciągłości działania, plany awaryjne oraz plany odtworzenia działalności.

Wymóg nie kończy się zatem na utworzeniu pliku. Organizacja powinna potrafić wykazać, że zna krytyczne procesy i zależności, przyjęła kolejność odtwarzania, zapewniła zasoby, przeprowadziła ćwiczenia i poprawiła rozwiązania, które nie zadziałały zgodnie z założeniami. Ochrona ma obejmować nie tylko dostępność, ale również poufność, integralność i autentyczność informacji podczas pracy awaryjnej.

Aktualnie opublikowaną podstawą pozostaje ISO 22301:2019 wraz z poprawką Amd 1:2024. ISO prowadzi prace nad kolejną edycją. Dlatego dokumentacja i artykuły wewnętrzne powinny wskazywać wersję normy, według której działa organizacja, a nie traktować wymagań jako zbioru niezmiennych numerów punktów.

BCP, DRP, backup i zarządzanie kryzysowe – czym się różnią?

Pojęcia bywają używane zamiennie, co prowadzi do luk odpowiedzialności. Kopia danych nie zapewnia działania procesu, a odtworzony serwer nie pomoże, jeżeli organizacja nie ma personelu, dostępu do budynku, łączności, decyzji biznesowej albo działającego dostawcy. BCP jest szerszy od DRP i powinien łączyć środki organizacyjne, techniczne, lokalowe oraz komunikacyjne.

Jak połączyć SZBI z ISO 22301?

System Zarządzania Bezpieczeństwem Informacji chroni informacje oraz systemy w oparciu o ryzyko. System zarządzania ciągłością działania według ISO 22301 koncentruje się na zdolności organizacji do dostarczania produktów i usług na zaakceptowanym poziomie podczas zakłócenia. Zakresy nakładają się, ale nie są identyczne.

Wspólne mogą być: kontekst organizacji, interesariusze, wymagania prawne, polityki, role, kompetencje, nadzór nad dokumentami, audyty wewnętrzne, przeglądy kierownictwa i działania korygujące. Osobne pozostają między innymi analiza wpływu na biznes, strategie ciągłości i szczegółowe rozwiązania zastępcze. Integracja nie oznacza połączenia wszystkiego w jeden wielki dokument.

Praktycznym łącznikiem jest mapa zależności. Dla każdej usługi objętej KSC należy wskazać procesy, aplikacje, dane, infrastrukturę, personel, dostawców i lokalizacje. Dzięki temu BCP nie odrywa się od SZBI, a DRP nie jest przygotowywany bez wiedzy o skutkach biznesowych. Ta sama mapa powinna zasilać ocenę ryzyka, analizę dostawców i ćwiczenia incydentowe.

BIA, RTO, RPO i MTPD – jakie parametry powinien zatwierdzić biznes?

Business Impact Analysis pozwala ustalić, jak rosną skutki zakłócenia w czasie. Nie jest tym samym co analiza ryzyka. Analiza ryzyka pyta o prawdopodobieństwo i skutek scenariusza, natomiast BIA bada konsekwencje niedostępności procesu oraz moment, po którym szkoda staje się nieakceptowalna.

Parametry nie powinny być ustalane wyłącznie przez IT. Właściciel procesu zna konsekwencje dla klientów, umów, bezpieczeństwa, finansów i regulacji. IT ocenia wykonalność oraz koszt. Zarząd rozstrzyga, czy koszt wymaganej odporności jest proporcjonalny do ryzyka i zatwierdza ryzyko rezydualne.

Wartości w tabeli są jedynie przykładem, a nie uniwersalną rekomendacją. Parametry muszą wynikać z rzeczywistej BIA, umów, wymagań sektorowych, zależności i możliwości technologicznych. Nieprawidłowe jest wpisanie niskiego RTO do dokumentu bez zapewnienia architektury, personelu i umowy z dostawcą, które pozwalają ten cel osiągnąć.

Jak zbudować spójne BCP i DRP?

BCP powinien zaczynać się od jasnych kryteriów aktywacji. Musi wskazywać osobę uprawnioną do uruchomienia planu, skład zespołu, alternatywne kanały komunikacji, procesy objęte planem, minimalny poziom działania, zasoby zastępcze oraz warunki powrotu do normalnej pracy. Instrukcja powinna być dostępna również wtedy, gdy główna sieć lub repozytorium dokumentów nie działa.

DRP przekłada cele biznesowe na kolejność technicznego odtworzenia. Powinien obejmować architekturę zależności, źródła konfiguracji, lokalizacje kopii, dane uwierzytelniające dostępne awaryjnie, wymagane kompetencje, procedury walidacji oraz kryteria przekazania systemu biznesowi. Odtworzenie jest zakończone dopiero wtedy, gdy właściciel potwierdzi użyteczność usługi, a nie w chwili uruchomienia serwera.

BCP, DRP i procedura incydentowa powinny działać równolegle. Zespół techniczny ogranicza skutki i odtwarza środowisko, właściciele procesów utrzymują usługę, a zespół formalnoprawny ocenia obowiązek zgłoszeń oraz komunikacji. Szczegółowe terminy raportowania opisuje poradnik Zgłoszenie incydentu NIS2 – 24 i 72 godziny.

Dostawcy chmurowi i outsourcing – kto odpowiada za odtworzenie?

Przeniesienie systemu do chmury nie przenosi całej odpowiedzialności za ciągłość. Dostawca może odpowiadać za dostępność infrastruktury, a klient nadal za konfigurację, kopie, tożsamość, eksport danych, integracje i tryb zastępczy procesu. Model współodpowiedzialności musi zostać przełożony na BCP, DRP oraz umowę.

Przed zaakceptowaniem parametrów RTO i RPO należy porównać je z SLA, czasami reakcji i możliwościami technicznymi dostawcy. Umowa powinna regulować powiadomienie o zdarzeniu, współpracę przy odtworzeniu, dostęp do dowodów, testy, podwykonawców, zakończenie usługi i odzyskanie danych. Pomocna jest analiza opisana w materiale Umowa z dostawcą IT NIS2 – 12 klauzul.

Jak testować ciągłość działania i dokumentować wyniki?

Test ma dostarczyć dowodu, że plan działa w określonych warunkach. Jego zakres powinien odpowiadać ryzyku. Nie każdy test wymaga wyłączenia produkcji. Organizacja może zacząć od przeglądu scenariuszowego, następnie wykonać test komunikacji, odtworzenie pojedynczego systemu w środowisku izolowanym, test pracy zastępczej i wreszcie ćwiczenie obejmujące kilka zespołów oraz dostawcę.

Protokół testu powinien zawierać cel, zakres, scenariusz, uczestników, przyjęte kryteria sukcesu, rzeczywiste czasy, odstępstwa, zebrane dowody i decyzję o wyniku. Każda luka powinna otrzymać właściciela, termin i priorytet, a po jej zamknięciu należy zweryfikować skuteczność działania. Sam protokół bez realizacji zaleceń pokazuje, że organizacja zna problem, ale go nie usunęła.

Podczas kontroli znaczenie mogą mieć aktualne plany, zatwierdzenia, BIA, rejestr testów, wyniki odtworzeń, raporty z ćwiczeń, działania korygujące, umowy i dowody przeglądów zarządczych. Pełną mapę polityk, procedur i zapisów zawiera artykuł Dokumentacja SZBI – jakie dokumenty musi posiadać firma?.

Powrót do normalnego działania jest częścią planu

Organizacja może skutecznie uruchomić tryb awaryjny, a mimo to narazić się na kolejne zakłócenie podczas powrotu do normalnej pracy. Dane zapisane ręcznie lub w systemie zastępczym trzeba uzgodnić, tymczasowe konta i uprawnienia wycofać, a zmiany konfiguracji przenieść do właściwego środowiska. Plan powinien określać, kto podejmuje decyzję o zakończeniu trybu awaryjnego i jakie warunki muszą być wcześniej spełnione.

Odbiór techniczny nie jest równoznaczny z odbiorem biznesowym. Administrator może potwierdzić działanie serwera i bazy danych, lecz właściciel procesu powinien sprawdzić kompletność transakcji, integracje, raportowanie, dostęp użytkowników oraz możliwość wykonania najważniejszych operacji. Warto przygotować krótką listę kryteriów odbioru dla każdego procesu krytycznego i dołączać ją do protokołu odtworzenia.

Po zdarzeniu potrzebny jest również przegląd obejmujący przyczynę, przebieg, rzeczywiste czasy, decyzje, koszty, komunikację i skuteczność dostawców. Wnioski powinny trafić do rejestru ryzyka, planu postępowania z ryzykiem i raportu dla zarządu. Jeżeli incydent był poważny, te same informacje mogą zasilać sprawozdanie końcowe dla CSIRT, ale dokument wewnętrzny i ustawowe zgłoszenie nie muszą mieć identycznego zakresu.

W tym miejscu ISO 22301 a NIS2 łączą się szczególnie wyraźnie. Norma wspiera powtarzalny cykl oceny i doskonalenia, a przepisy wymagają utrzymywania oraz testowania środków. Zamknięcie incydentu bez aktualizacji planu, ponownego testu i decyzji dotyczącej ryzyka pozostawia organizację z tym samym problemem, który doprowadził do zakłócenia.

Jak wdrożyć wspólny model ISO 22301, SZBI i NIS2?

Najlepiej rozpocząć od zakresu usług objętych KSC i mapy zależności. Następnie organizacja przeprowadza BIA, uzgadnia cele odtworzenia, ocenia istniejące zabezpieczenia oraz wybiera strategie ciągłości. Dopiero na tej podstawie powstają plany. Odwrotna kolejność zwykle prowadzi do dokumentów opartych na założeniach, których biznes i technologia nigdy nie zatwierdziły.

Wdrożenie można podzielić na sześć rezultatów: zatwierdzony zakres, BIA, strategie ciągłości, BCP i DRP, wykonane testy oraz rejestr usprawnień. Każdy rezultat powinien mieć właściciela i decyzję zarządu. Certyfikacja może być osobnym celem, ale zgodność z KSC/NIS2 wymaga również obowiązków niewynikających z samej normy, takich jak właściwa komunikacja z CSIRT, raportowanie incydentów i krajowe zasady dokumentacyjne.

Model ISO 22301 a NIS2 powinien być proporcjonalny. Mniejsza organizacja może utrzymywać krótsze plany i łączyć role, o ile pozostają jasne zastępstwa, priorytety i dowody testów. Rozbudowana grupa kapitałowa zwykle potrzebuje planów dla poszczególnych usług oraz wspólnego mechanizmu koordynacji, ponieważ awaria jednego dostawcy albo centralnej platformy może równocześnie dotknąć kilka spółek.

Checklista gotowości BCP i DRP

Zaznacz elementy, które organizacja może potwierdzić dowodami. Wynik ma charakter orientacyjny i nie zastępuje analizy prawnej ani audytu.

Najczęstsze błędy

Pierwszym błędem jest sprowadzenie ciągłości do backupu. Drugim jest przyjęcie RTO i RPO bez BIA oraz bez potwierdzenia, czy infrastruktura i umowy pozwalają je osiągnąć. Trzecim jest brak właściciela biznesowego: dokument przygotowuje IT, ale nikt nie ustala minimalnego poziomu działania usługi.

Kolejne problemy to plan dostępny wyłącznie w niedostępnym systemie, nieaktualne kontakty, nieuwzględnienie dostawców, brak procedury powrotu z trybu awaryjnego i test ograniczony do dyskusji. Ryzykowne jest również traktowanie pomyślnego uruchomienia serwera jako zakończenia DRP bez sprawdzenia danych, integracji, uprawnień i funkcji biznesowych.

Plan powinien zmieniać się wraz z organizacją. Nowy system, migracja do chmury, zmiana dostawcy, przejęcie spółki, praca zdalna albo incydent mogą zmienić zależności i wymagane czasy. Aktualizacja dokumentu bez ponownego testu nie daje pewności, że nowe rozwiązanie zadziała.

Najczęściej zadawane pytania

Podsumowanie

ISO 22301 a NIS2 nie są konkurencyjnymi rozwiązaniami. NIS2 i UoKSC określają wymagany rezultat prawny oraz obszary zabezpieczeń, a ISO 22301 dostarcza metody zarządzania ciągłością. SZBI spina te działania z ryzykiem bezpieczeństwa informacji, dokumentacją, dostawcami, incydentami i nadzorem zarządu.

Skuteczny model zaczyna się od usług i BIA, nie od szablonu dokumentu. Następnie organizacja uzgadnia RTO i RPO, wybiera strategie, buduje BCP i DRP, testuje je oraz rozlicza działania korygujące. Dopiero taki cykl pozwala wykazać, że plany są utrzymywane i działają, a nie tylko istnieją.