Inoni Essentials to system zarządzania ciągłością działania (BCMS) przeznaczony do użytku przez organizacje, które wymagają bezpiecznego, kompaktowego oraz niezależnego narzędzia.
Inonito internetowa platforma dostępna dla organizacji na zasadzie subskrypcji lub Software as a Service (SaaS). Platforma jest w 100% własnością Inoni Limited zarejestrowanej w Wielkiej Brytanii w maju 2005 r. Numer firmy 5454746.
Essentials (lub jakiekolwiek inne oprogramowanie wspierające zarządzanie ciągłością działania) samo w sobie nie jest zgodne ze standardami, ponieważ zależy to od właściwego wdrożenia standardu przez organizację. Essentials jest jednak w stanie wspierać organizacje w procesie osiągania zgodności, zapewniając odpowiednie rozwiązania
do gromadzenia informacji, automatyzacji, przechowywania i dokumentowania.
Essentials w szczególności ma na celu wspieranie organizacji w dostosowywaniu się (i potencjalnie do zgodności z ISO22301) do normy międzynarodowej Bezpieczeństwo powszechne Systemy zarządzania ciągłością działania. Essentials wspiera również organizacje we wdrażaniu bieżących najlepszych praktyk poprzez stosowanie Wytycznych Dobrej Praktyki Business Continuity Institute 2013.
Masz wątpliwości co do stosowanej terminologii – Plan Ciągłości Działania, (IT) Disaster Recovery, Emergency Response, Zarządzanie Kryzysowe, Incident Management, IT Incident Response Plan, itp.
Co się kryje pod każdym z tych haseł? Generalnie trudno jest odpowiedzieć jednoznacznie bez lektury chociażby struktury dokumentu, który podpowie czy dany dokument obejmuje całość zagadnień ciągłości działania czy może tylko wycinek. RiskChallenge dla ułatwienia, w swoich projektach traktuje dokument Planu Ciągłości Działania (BCP) jako rodzaj menu w zakresie odbudowy działalności biznesowej. Menu to zawiera pięć dań:
W ostatnim czasie pojawiają się pytania na temat oddzielnego dokumentu dotyczącego obszaru IT, w szczególności w świetle ryzyk cybernetycznych. Zakres i częstotliwość incydentów, które mogą prowadzić do poważnych w skutkach zakłóceń rośnie co uzasadnia aby tę część potraktować oddzielnie, jednak najlepiej jako podrozdział całego Planu Ciągłości Działania. Często jednak BCP oraz IT DRP są niezależnie opracowywane co generuje luki czy niespójności. Są one widoczne, w szczególności, w zakładach produkcyjnych np. w wymiarze OT/IT czy poświęceniu odpowiedniej uwagi bardziej tradycyjnym ryzykom i ich konsekwencjom.
Jak to zwykle bywa standardów, norm czy podręczników dobrych praktyk znajdziemy wiele czy to wprost odnoszących się do ciągłości działania czy jako ujęcie zagadnienia z innego obszaru (IT, bezpieczeństwa informacji, itp.) Jak tylko pojawia się nowe zagrożenie to od razu powstają wytyczne.
Zatem który wybrać? Wszystkie są dobre i nie warto się koncentrować na tym, który standard wykorzystać. Każdy może być zastosowany do opracowania skutecznego programu ciągłości działania. Wszystkim bowiem przyświeca cel budowy oporności organizacji na zakłócenia i zapewnienia ciągłości biznesowej. Najczęściej spotykane w naszej części świata to ISO22301, NFPA1600, Good Practice Guide BCI. Różnice skupiają się na strukturze dokumentu, użytej terminologii, liczbie stron poświęconym danemu zagadnieniu czy historii powstania.
Podejście riskChallenge i Inoni siłą rzeczy wykorzystuje ISO i wytyczne BCI ze względu na ich popularność i rozpoznawalność ale w wymiarze, który służy organizacji jako punkt odniesienia, a nie wymóg jakiejkolwiek certyfikacji, której jednak nie wykluczam.
Potrzebny czas zależy od wielu czynników jednakże dla proponowanego przyjmując pewne założenia można zdefiniować dwie opcje. Projekty dla małych organizacji lub jednorodnych w zakresie działalności czy jedno lokalizacyjne udaje się zrealizować od 6 do 8 tygodni. Projekty dla większych organizacji, różnorodnych, kilku lokalizacyjnych zabiorą trochę więcej czasu od 12 do 18 tygodni.
Różnice wynikają z większej liczby współzależności występujących w organizacji i tym samym czasu potrzebnego na ich udokumentowanie i przeanalizowanie zanim podejmiemy decyzję i zrobimy kolejny krok. W przypadku obydwóch opcji należy przyjąć jedno zastrzeżenie dotyczące etapu wdrożenia, które we wspomnianych terminach może być trudno osiągalne. Jeśli nie dysponujemy gotowymi rozwiązaniami to możemy mówić o zaplanowaniu zadań w tym zakresie niż o faktycznym wdrożeniu rozwiązań zachowania ciągłości działania. Rozwiązania te wymagają czasu na weryfikację, analizę kosztów i korzyści, zapewnienia finansowania czy modyfikacji modelu biznesowego. Pamiętajmy że po ich wdrożeniu następuje aktualizacja planu, szkolenia, symulacje.
Budowa odporności i skutecznego systemu potrwa zatem dłużej i perspektywa 1-2 lat na pewno nie jest niewłaściwa. Sugerowane terminy są powiązane z proponowanym podejściem, które uważam za praktyczne.
Oczywiście nie musi jednak trzeba ten zakres zdefiniować i tu pojawia się dylemat jak to zrobić. Aby uniknąć długotrwałych analiz i rozważań wystarczy zastanowić się na tym, które obszary firmy są krytyczne lub które produkty czy usługi powinny być zagwarantowanie bez względu na wystąpienie istotnego zdarzenia. Istnieje wiele sposobów na określenie tego zakresu, np. poprzez pryzmat produktów czy usług o największych generowanych przychodach; najbardziej zagrożoną lokalizację; wymagania stawiane przez regulatora, klienta czy innego istotnego interesariusza naszej organizacji. Najważniejsze aby zacząć ten proces gdyż perspektywa ciągłości działania może wpłynąć na podejmowane decyzje biznesowe. Pamiętajmy, iż ciągłość działania konkuruje ze zwiększeniem wydajności oraz redukcją kosztów, w tym też wpływa na skuteczność ochrony ubezpieczeniowej, np. outsourcing.
Tolerancja ryzyka to „poziom bólu” jaki organizacja może i chce wytrzymać. Ten parametr jest dosyć kluczowy gdyż decyduje jak szybko musimy czy chcemy zareagować. Jest to punkt odniesienia nawigujący naszymi działaniami w ramach planowania ciągłości działania i może być określony w różnych wymiarach – finansowym, bezpieczeństwa, zgodności, produkcyjnym czy reputacyjnym. Dosyć trudny parametr do określenia w sposób jednoznaczny dla wszystkich w organizacji czy poza nią.
Często ten parametr jest już gdzieś zdefiniowany i wymaga tylko prześledzenia polityk organizacji w różnych obszarach – jak „zero wypadków”, udział własny – 5 dni oczekiwania i 12 miesięczny okres odszkodowawczy, przyczyny i okres wypowiedzenia umowy przez klienta, inne. To są dobre punkty wyjścia do dyskusji, która często pokazuje, że ambitne deklaracje nie są osiągalne w wymiarze ciągłości działania. Jednak najbardziej kluczowym pytaniem jest „Ile czasu mamy od momentu zaprzestania dostarczania produktów do klientów czy świadczenia usług, a pojawieniem się nieakceptowalnych konsekwencji (np. decyzja klienta o rezygnacji z dalszej współpracy). To przekłada się na tajemnicze skróty MTPD, RTO, a inaczej kiedy najpóźniej powinniśmy reaktywować określoną aktywność i w jakim terminie planujemy to zrobić. To zestawienie często weryfikuje nasze ambitne założenia i koszty jakie się z tym wiążą
No cóż, czas na budowę odporności poprzez działania prewencyjne, wdrażanie rozwiązań zapewniających ciągłość działania, ćwiczeniu, szkoleniu czy uaktualnianiu planu. Ten etap jest kluczowy aby nasz plan nie stał się typowym ”półkownikiem”. Tutaj pojawia się pytanie o symulacje planu. Jest to element sprawdzający czy wdrożone rozwiązania zadziałają zgodnie z oczekiwaniami. Często zaraz po opracowaniu planu chciałoby się go przetestować ale warto stopniować napięcie. Pierwszym wystarczającym działaniem jest przejście przez plan z wszystkimi, którzy pełnią w nim przypisaną rolę, co pozwoli się z nią zapoznać oraz przedyskutować opcje i strategie dla poszczególnych scenariuszy. Już takie podstawowe ćwiczenie pozwoli na identyfikacje obszarów wymagających dalszego doskonalenia.
