Zgodnie z definicją, którą znajdziemy w normie ISO 223301, zarządzanie ciągłością działania jest kompleksowym procesem identyfikacji potencjalnych zagrożeń i ich wpływu oraz ramą budowania odporności i zdolności do efektywnej reakcji, zabezpieczającej interesy kluczowych udziałowców, reputację, markę i działania tworzące wartość.

Zarządzanie ciągłością działania przedsiębiorstwa to bardzo rozległy, złożony i niesamowicie istotny temat. Jak przekonują eksperci z Business Continuity Institute, ok. 80% firm, które nie mają wdrożonych Planów Ciągłości Działania (ang. Disaster Recovery Plans – DRP), wypadnie z biznesu w ciągu kilkunastu miesięcy od dużego incydentu. Czym są plany ciągłości działania (PCD) w praktyce, kto jest odpowiedzialny za ich stworzenie, stosowanie i ciągłe aktualizowanie, postaramy się odpowiedzieć w niniejszym artykule.

> PCD w teorii

PCD to tylko mały klocek w całej budowli, jaką tworzy zarządzanie bezpieczeństwem i ciągłością działania organizacji (rys. 1). W dużych korporacjach tworzy się specjalne zespoły, a nawet całe piony/departamenty, które kompleksowo zarządzają ryzykiem na wszystkich etapach działania przedsiębiorstwa. My skupimy się na kwestiach związanych z zarządzaniem ryzykiem w IT, a szczególnie planami DRP.

Plany ciągłości działania to zbiór procedur, dokumentów, technicznych pomiarów, które umożliwią przywrócenie infrastruktury IT, systemów oraz danych po zakłóceniu działania bądź utracie jednego centrum danych lub danej lokalizacji.

Już z tej definicji wynika jedna bardzo ważna rzecz – musimy mieć przynajmniej dwa ośrodki przetwarzania danych, aby mieć możliwość stworzenia PCD. Redundancja jest tutaj kluczowa. Najczęściej definiujemy podstawowy ośrodek przetwarzania danych jako Primary Data Center (PDC) oraz zapasowy ośrodek przetwarzania danych jako Disaster Recovery Center (DRC).

Na początek dobrze również wspomnieć o przepisach, standardach oraz źródłach dobrych praktyk, z których możemy korzystać przy opracowywaniu planów. Poniżej przedstawiamy kilka pozycji, które z pewnością będą przydatne:

• ISO 27001 – ciągłość działania w zarządzaniu bezpieczeństwem informacji;
• ISO 20000 – ciągłość działania w zarządzaniu informatyką;
• ISO 31000 – ciągłość działania jako konsekwencja zarządzania ryzykiem;
• ISO 27001: 2005 – „Technika informatyczna – Techniki bezpieczeństwa – Systemy zarządzania bezpieczeństwem informacji – Wymagania”. Polskie wydanie: PN – ISO/IEC 27001:2007.

Norma ISO27001 będzie szczególnie niezastąpiona, gdyż opisuje szczegółowo 11 obszarów zabezpieczeń każdego przedsiębiorstwa. Zostały w niej opisane następujące zagadnienia:

• polityka bezpieczeństwa;
• organizacja bezpieczeństwa informacji;
• zarządzanie aktywami;•bezpieczeństwo zasobów ludzkich;
• bezpieczeństwo fizyczne i środowiskowe;
• zarządzanie systemami i sieciami;
• kontrola dostępu;
• pozyskanie, rozwój i utrzymanie systemów informacyjnych;
• zarządzanie incydentami naruszenia bezpieczeństwa informacji;
• zarządzanie ciągłością działania;
• zgodność z wymaganiami prawnymi.

Obalając mity, chcielibyśmy uświadomić, że zarządzanie ryzykiem:

• nie ogranicza się do wypełniania formularzy;
• nie jest zadaniem jednorazowym;
• nie dotyczy tylko kierownictwa;
• nie dotyczy tylko kwestii finansowych;
• nie sprowadza się do eliminacji ryzyka;
• nie ogranicza się do ryzyk ubezpieczalnych.

> Na początek

Wdrożenie PCD powinno być pełnoprawnym projektem. Bez wymaganych zasobów, precyzyjnego zakresu i harmonogramu oraz co najważniejsze określonego budżetu wdrożenie ma nikłe szanse na powodzenie. W proces wdrożenia powinno być również zaangażowane najwyższe kierownictwo.

Na samym początku należy zdefiniować role osób zaangażowanych w projekt i wyznaczyć: sponsora projektu (określa strategię i zakres, zatwierdza wyniki), kierownika projektu (zarządza projektem, zna organizację, prowadzi komunikację, negocjuje, rozwiązuje problemy), komitet sterujący (planuje wdrożenie planu, definiuje projekt, role i zakresy, wybiera metody analizy ryzyka i kryteria akceptacji), zespół projektowy (dostarcza informacje o procesach i zasobach). Nie jest wymagane, aby wszystkie osoby biorące udział w projekcie były ekspertami w obszarze ryzyka i planów ciągłości. Właściwie jest to nawet niepożądane. Bardzo ważne natomiast jest to, aby zespół był interdyscyplinarny i przynajmniej w komitecie sterującym zasiadały osoby odpowiedzialne za poszczególne obszary zarządzania organizacją: IT, audyt, prawo i zgodność, finanse, HR, bezpieczeństwo fizyczne.

Pierwszym zadaniem, jakie czeka zespół projektowy, jest zrozumienie organizacji, jej procesów biznesowych, zasobów, powiązań z interesariuszami itd. Tylko wielofunkcyjny zespół będzie potrafił dostarczyć odpowiednią wiedzę na tym etapie, aby przygotować prawidłową i kompleksową ocenę ryzyka biznesowego. Business Impact Analysis (BIA) ma na celu udokumentowanie strat wynikających z przerwania procesów oraz identyfikację akceptowalnych czasów przerw, utraty danych oraz wymaganych poziomów odtworzenia. BIA powinna również przygotować listę krytycznych procesów i zasobów niezbędnych do ich realizacji. Do rzetelnego wykonania tej części jest potrzebna duża wiedza i pełne zrozumienie biznesu i procesów w danej organizacji, tak aby jasno rozdzielić procesy kluczowe, które dostarczają wartość klientowi, od tych jedynie wspomagających, które nie generują bezpośrednich strat. Analiza ryzyka powinna uwzględnić różne rodzaje strat, począwszy od finansowych (kary, odszkodowania, przestoje, utrata przychodów, koszty odtworzenia procesów) po wizerunkowe (utrata reputacji, komentarze w mediach, spadek wartości marki oraz morale pracowników). W wynikach BIA powinny się również znaleźć docelowe czasy przywrócenia produktów i usług do uwzględnionego wcześniej poziomu tzw. Recovery Time Objective (np. RTO = 4 h oznacza konieczność przywrócenia procesu w ciągu 4 godzin od wystąpienia przerwy). RTO nie mówi nic o poziomie, na jakim proces ma być odtworzony. Taką informację zawiera minimalny poziom odtworzenia procesów lub usług (ang. Minimum Business Continuity Objective, MBCO).

Wyniki BIA są podstawą kolejnych faz budowania planów ciągłości działania. Dlatego też przyjęte metody identyfikacji i późniejszej analizy zagrożeń powinny być dobrane z najwyższą starannością. Analiza BIA powinna odpowiadać na fundamentalne pytania:

• Co może się zdarzyć?
• Gdzie?
• Kiedy?
• Dlaczego? (jakie są czynniki ryzyka)
• Jak jesteśmy zabezpieczeni (jakie mamy środki kontroli)
• Co należy zrobić, aby zminimalizować zagrożenie?
• Co można zrobić, aby zmniejszyć prawdopodobieństwo wystąpienia zdarzenia?
• Czy mamy wystarczającą liczbę pracowników? Co w przypadku 50% absencji?
• Czy mamy alternatywną listę dostawców? Czy są podpisane z nimi odpowiednie umowy?

[...]

Autor jest specjalistą ds. utrzymania infrastruktury data center. Zajmuje się problematyką budowy, utrzymania i zarządzania centrami przetwarzania danych oraz koordynowaniem zmian dotyczących krytycznej infrastruktury IT.