Ciągłość działania (BCMS). ISO 22301 od czego zacząć.
No to o czymś, o czym wszyscy myślą dopiero po awarii. Plan ciągłości działania nie jest grubym segregatorem, tylko odpowiedzią na jedno pytanie: co robimy, gdy padnie.
No i znacie ten moment: pada kluczowy system, a ktoś pyta “mamy jakiś plan?”. Plan zwykle jest, w segregatorze, nieaktualny, nikt go nie czytał. BCMS, czyli system zarządzania ciągłością działania wg ISO 22301, robi z tego coś żywego: wiesz co jest krytyczne, jak szybko musi wrócić i kto co robi.
TL;DR
- BCMS zaczyna się od BIA, czyli analizy wpływu na działalność, nie od pisania planów
- Kluczowe parametry: RTO (jak szybko odtworzyć) i RPO (ile danych możesz stracić)
- Plan BCP bez testów to fikcja; ćwiczenie tabletop wykrywa dziury zanim zrobi to awaria
- DORA i NIS2 i tak wymagają ciągłości działania, więc to nie jest wybór "czy", tylko "jak"
Krok 1: BIA, czyli co jest naprawdę krytyczne
Zanim napiszesz jakikolwiek plan, robisz analizę wpływu na działalność. Dla każdego procesu pytasz: ile kosztuje godzina przestoju, po jakim czasie robi się dramat, od czego ten proces zależy. Z tego wychodzą priorytety. Bez BIA piszesz plany dla wszystkiego po równo, a budżet i czas masz na garstkę rzeczy naprawdę ważnych.
Krok 2: RTO i RPO, dwie liczby które rządzą
RTO to czas, w jakim proces musi wrócić. RPO to ile danych możesz stracić (czyli jak często musisz robić backupy). Te dwie liczby ustawiasz per proces na podstawie BIA, a potem konfrontujesz z rzeczywistością.
Krok 3: plany BCP i DRP
Dopiero teraz piszesz plany. BCP (Business Continuity Plan) mówi jak działa biznes w trybie awaryjnym. DRP (Disaster Recovery Plan) mówi jak technicznie odtworzyć systemy. Konkretne kroki, role, kontakty. Krótko i wykonalnie, nie esej.
Krok 4: testy, bo plan bez testu to życzenie
Ćwiczenie tabletop, test odtworzenia, scenariusz “padło data center”. Test wykrywa, że telefon do kluczowej osoby jest nieaktualny, a backup nie odtwarza się tak szybko jak zakładałeś. Lepiej dowiedzieć się tego na ćwiczeniu niż o 3 nad ranem.
Jak to spiąć z resztą
Ciągłość działania nie żyje obok zgodności. RTO z BIA to ten sam parametr, którego pilnuje DORA. Plany i testy to dowody, których szuka audytor ISO. Dlatego trzymamy to razem.
W module ISO 22301 masz BIA z RTO/RPO, plany BCP, scenariusze i harmonogram testów w jednym miejscu, a moduł DORA sam podnosi rękę, gdy umowa z dostawcą nie zdąży z Twoim RTO. Pełny warsztat ciągłości i ISMS siedzi w module CISO. Bez segregatora, z aktualnymi danymi.
Pisał ktoś z zespołu RealSec. Jak chcesz pogadać o tym konkretnie ; napisz do nas.