Obowiązek informacyjny rodo
W większości organizacji plany ciągłości działania (BCP) i plany odtwarzania po awarii (DRP) powstają w odpowiedzi na konkretne wymagania. Czasami są oczekiwane przez klientów, czasami wynikają z wymagań audytowych, a coraz częściej są elementem przygotowań do spełnienia wymagań NIS2. Dokument zostaje opracowany, zatwierdzony i zapisany w systemie. Wszyscy mają poczucie, że organizacja jest przygotowana na sytuacje kryzysowe.
Problem polega na tym, że incydenty nie interesują się dokumentami. Awaria systemu, cyberatak, utrata danych czy niedostępność kluczowych usług bardzo szybko pokazują różnicę pomiędzy organizacją, która posiada plan, a organizacją, która potrafi z niego skorzystać. To właśnie dlatego NIS2 tak mocno akcentuje odporność operacyjną i zdolność do utrzymania lub przywrócenia działania po incydencie.
Choć pojęcia BCP i DRP bardzo często pojawiają się obok siebie, nie są tym samym. W praktyce odpowiadają na dwa różne pytania.
Plan ciągłości działania koncentruje się na funkcjonowaniu organizacji w czasie zakłócenia. Dotyczy ludzi, procesów, komunikacji i sposobu świadczenia usług wtedy, gdy normalne warunki pracy przestają istnieć. Z kolei plan odtwarzania po awarii skupia się na technologii – systemach, infrastrukturze, aplikacjach i danych, które trzeba przywrócić po incydencie.
To rozróżnienie jest niezwykle istotne. Można bardzo sprawnie odtworzyć system informatyczny, a jednocześnie nie być przygotowanym do utrzymania kluczowych procesów biznesowych. Można również mieć dobrze opisane procedury operacyjne, ale nie posiadać możliwości szybkiego odzyskania danych lub przywrócenia usług. W praktyce organizacja potrzebuje obu elementów jednocześnie – dopiero wtedy można mówić o realnej odporności.
Od kilku lat ransomware pozostaje jednym z najczęściej omawianych scenariuszy kryzysowych. Dzieje się tak nie bez powodu. Ten rodzaj incydentu bardzo szybko pokazuje, czy organizacja rzeczywiście jest przygotowana na sytuację awaryjną.
Wiele firm deklaruje, że posiada kopie zapasowe. Część z nich ma także procedury odtwarzania danych. Jednak prawdziwe pytania pojawiają się dopiero wtedy, gdy trzeba przejść od deklaracji do działania. Które systemy należy przywrócić jako pierwsze? Jak długo organizacja może funkcjonować bez kluczowych aplikacji? Kto podejmuje decyzje w sytuacji kryzysowej? Czy kopie zapasowe zostały kiedykolwiek sprawdzone pod kątem możliwości odtworzenia?
To właśnie odpowiedzi na te pytania decydują o tym, czy firma wróci do działania po kilku godzinach, kilku dniach czy może kilku tygodniach. Sam fakt posiadania kopii zapasowych nie oznacza jeszcze zdolności do odzyskania działalności.
Jednym z największych błędów spotykanych podczas audytów jest przekonanie, że przygotowanie dokumentacji oznacza gotowość organizacji. Tymczasem plan, który nigdy nie został przetestowany, pozostaje jedynie zestawem założeń.
Regularne ćwiczenia pokazują rzeczy, których nie widać podczas przeglądania dokumentów. Czasem okazuje się, że numery telefonów są nieaktualne. Innym razem brakuje dostępu do procedur lub osoby odpowiedzialne za podejmowanie decyzji nie wiedzą, jakie działania powinny wykonać. Zdarza się również, że systemy uznawane za krytyczne kilka lat temu nie są już najważniejsze dla organizacji, a dokumentacja nie nadążyła za zmianami biznesowymi.
Dlatego organizacje dojrzałe nie traktują testów jako obowiązku audytowego. Traktują je jako narzędzie weryfikacji własnej gotowości.
Jednym z najważniejszych wymagań NIS2 jest podejście oparte na ryzyku. Ta zasada powinna być widoczna również w obszarze ciągłości działania.
Jeżeli w rejestrze ryzyk pojawia się możliwość utraty danych, długotrwałej niedostępności systemów, awarii kluczowej aplikacji czy ataku ransomware, organizacja powinna być w stanie pokazać, jak zamierza poradzić sobie z takim scenariuszem. W przeciwnym razie analiza ryzyka pozostaje wyłącznie ćwiczeniem teoretycznym, które nie przekłada się na zdolność działania w sytuacji kryzysowej.
Można więc powiedzieć, że dobrze przygotowany BCP i DRP są naturalną konsekwencją procesu zarządzania ryzykiem. To właśnie tam ryzyka zamieniają się w konkretne działania.
W poprzednim wpisie mówiliśmy o odpowiedzialności za ryzyka w łańcuchu dostaw. W kontekście ciągłości działania temat ten pojawia się ponownie, ale z nieco innej perspektywy.
Jeżeli organizacja korzysta z usług chmurowych, centrów danych, zewnętrznych systemów lub usług ICT, warto wiedzieć nie tylko, jak działają ich zabezpieczenia. Równie ważne staje się pytanie, czy dostawca posiada własne plany ciągłości działania i procedury odtwarzania po awarii.
Brak takich mechanizmów po stronie dostawcy może oznaczać, że nawet bardzo dobrze przygotowana organizacja nie będzie w stanie wrócić do pełnej sprawności w oczekiwanym czasie. To właśnie dlatego informacje o BCP i DRP coraz częściej pojawiają się w kwestionariuszach bezpieczeństwa, procesach due diligence oraz audytach kontraktowych.
NIS2 nie wymaga posiadania dokumentów dla samego faktu ich posiadania. Oczekuje zdolności do działania wtedy, gdy organizacja znajduje się pod presją i musi podejmować szybkie decyzje.
Dlatego warto spojrzeć na BCP i DRP nie jak na obowiązkową dokumentację, ale jak na element budowania odporności. Dokument może być napisany raz. Odporność organizacji buduje się natomiast poprzez regularne przeglądy, testy, aktualizacje i ćwiczenia. Dopiero wtedy można mieć pewność, że gdy pojawi się incydent, organizacja będzie wiedziała nie tylko co jest zapisane w planie, ale przede wszystkim jak wykorzystać ten plan w praktyce.