Enter your keyword

Moduł Zarządzania Ryzykiem

Połączenie informacji o ryzykach, incydentach i planach BC

Im więcej informacji tym bardziej wiarygodne szacunki i bardziej adekwatna reakcja na zdarzenia

BCMLogic ONE posiada wszystko co potrzebne do Zarządzania Ryzykiem: listę zasobów, osób i procesów, możliwość opisania przyczyn ryzyka, wybór strategii, przypisanie planów postępowania oraz raportowanie i monitorowanie. Oferuje jednak znacznie więcej. Integracja z informacjami o incydentach, analizie BIA i planach BCP pozwala na jeszcze lepsze urealnienie oceny ryzyka. Poziom prawdopodobieństwa może być ustawiany na podstawie liczby incydentów, które dotyczyły danego procesu czy zasobu. Zarejestrowane skutki incydentów umożliwiają  weryfikację wcześniej przyjętych skutków materializacji ryzyka. BIA  daje nam informację co tak naprawdę jest kluczowe dla organizacji pod kątem oceny ryzyk.

Kontrola nad planami postępowania

Przydzielanie, akceptacja i monitorowanie

Plany postępowania to praktycznie dodatkowy podmoduł. Z jednej strony zintegrowany z listą ryzyk, a z drugiej posiadający własny Workflow, powiadomienia i przypomnienia, gwarantujący automatyzację pełnego cyklu życia od planu do gotowego zabezpieczenia, pozwalający na monitorowanie wykonania.

Spójne zarządzanie ryzykiem w organizacji

Od oceny zasobu po globalne ryzyka w całej organizacji

BCMLogic to analiza ryzyka na różnych poziomach: od systemu IT czy lokalizacji, poprzez różne systemy zarządzania (BCM, Zgodność, Bezpieczeństwo informacji itd.) po ryzyka operacyjne na poziomie jednostek, całej firmy lub międzynarodowej korporacji. System zapewnia izolację poszczególnych poziomów i kategorii, ale nie wyklucza spójnego przepływu na wyższe poziomy. Jeśli administrator kluczowej lokalizacji zdiagnozuje poważne ryzyko mające wpływ na procesy biznesowe, wówczas informacja ta może być propagowana dalej. W zależności od rodzaju i poziomu ryzyka użytkownicy korzystają z najbardziej odpowiednich formularzy i ekranów aplikacji.

Szeroki zakres zastosownia

Ryzyka dotyczące procesów i usług biznesowych, zazwyczaj obsługiwane na poziomie departamentów/pionów.

Ryzyka pod kątem ciągłości działania, zazwyczaj obejmujące kategorie: osoby, infrastruktura IT, lokalizacje, dostawcy. Badane zarówno na poziomie procesów jaki i zasobów.

ryzyka dotyczące systemów i aplikacji oraz kluczowej infrastruktury. Z jednej strony określenie zagrożeń za pomocą checklist (w formie ankiety powiązanej z bazą podatności), z drugiej strony współpraca z dedykowanymi rozwiązaniami, takimi jak skanery podatności. Możliwość określenia priorytetu usuwania dużej liczby podatności dzięki wiedzy o tym ile i jak bardzo krytycznych procesów biznesowych oraz ile i jakie zbiory danych korzystają z danego urządzenia.

Moduł oferuje bibliotekę ryzyk, która może być zarządzana z poziomu aplikacji lub importowana z zewnętrznego źródła.

Jeśli prowadzony projekt lub inna sytuacja wymaga odstępstwa od reguł bezpieczeństwa, wykorzystywany jest formularz odstęp. Pozwala na określeni reguły od której wnioskujący chce odejść, wyrażenie opinii działów merytorycznych (np. prawny, bezpieczeństwo, IT itp.), określenie poziomu ryzyka związanego z odstępstwem. W przypadku akceptacji określa się termin ważności.

Rejestr zdarzeń, które faktycznie wystąpiły z możliwością określenia przewidywanych strat finansowych oraz niefinansowych (w dowolnej liczbie kategorii).

Priorytetyzacja na podstawie wiedzy o powiązaniach pomiędzy procesami (i ich krytycznością) a zasobami. Mechanizmy do przydzielania oraz monitorowania realizacji zadań.

Funkcje i elementy modułu

Podstawowe repozytorium, które dzięki elastyczności umożliwiaj równoległą obsługę wielu typów ryzyk. Podstawowym podziałem jest kategoria ryzyka (definiowalny słownik), na podstawie, którego określa się jakie formularz aplikacji (tzw. zakładki) mają być dostępne dla danej kategorii. Dla każdego ryzyka można określić:

  • Istniejące zabezpieczenia, obniżające poziom ryzyka
  • Poziom ryzyka – określany na podstawie macierzy wypełnianej przez osobę analizującą (prawdopodobieństwo i dowolna liczba typów wpływu) lub na bazie numerycznych wartości przypisanych do podatności.
  • Strategię postępowania
  • Plany postępowania z ryzykiem, jeśli wymaga tego przyjęta strategia postępowania
  • Procesy biznesowe, których ryzyko dotyczy
  • Zasoby (np. systemy informatyczne, infrastruktura, ale również dostawcy)

Baza ryzyk działa w oparciu o workflow – opis w dalszej części.

Uprawnienia do ryzyk nadawane są dynamicznie na podstawie takich elementów jak: kategoria ryzyka, przypisanie ryzyka do jednostki organizacyjne, zasobu, procesu oraz wszelkich innych atrybutów, które dostępne są w rozbudowanej bazie danych. Umożliwia to bardzo precyzyjną kontrolę dostępu. Dwóch użytkowników wchodzących na tą samą listę, może widzieć zupełnie inny zestaw ryzyk, zależnie od pełnionej roli.

Każde ryzyko opisane jest kartą ryzyka, w ramach której istnieje możliwość m.in. zdefiniowania celów/wymagań, jakie należy osiągnąć/spełnić, aby uzyskać oczekiwany poziom ryzyka, możliwość wskazania skutków zmaterializowania się ryzyka pod kątem wpływu na określony obszar             w organizacji, a także funkcja określenia opcji i planu postępowania z ryzykiem.

Karta ryzyka podzielona jest na zakładki gromadzące poszczególne funkcje. Zakładki mogą być wyłączane, udostępnione do podglądu lub edycji w sposób dynamiczny, na podstawie kategorii, aktualnego statusu oraz roli w jakiej występuje użytkownik. Poniżej zaprezentowane formularz z aktywną zakładką określającą macierz ryzyka. Obecnie w aplikacji dostępnych jest kilkanaście zakładek. W przypadku specyficznych potrzeb, w pierwszej kolejności wprowadzamy modyfikacje w istniejących zakładkach, a jeśli liczba zmian jest duża, tworzymy dedykowaną zakładkę. Z poziomu ekranu możliwa jest zmiana statusu ryzyka (przyciski kontekstowe workflow w górnej lewej części) oraz generacja raportu – z wykorzystaniem szablony Word, który jest wypełniany dynamicznie danymi aktualnego ryzyka.

Dla każdego ryzyka możliwe jest zdefiniowanie wpływu na zasoby i procesy w ramach wspólnych dla całej platformy rejestrów. Jednocześnie możliwe jest przeprowadzanie dedykowanej analizy ryzyka dla konkretnego zasobu.

identyfikacja i analiza ryzyka to początek procesu. Naszym zdaniem najważniejsze w procesie zarządzania ryzykiem jest odpowiednie wnioskowanie i wsparcie w podejmowaniu bieżących decyzji. Temu służą narzędzia analityczne:

  • Biblioteka KRI z możliwością połączenia wskaźników z danymi zbieranymi w ramach platformy (incydenty, awarie etc.) oraz z innych systemów.
  • Wartości wskaźników KRI mogą być również wyliczane na podstawie informacji zbieranych od użytkowników
  • Raporty analityczne, wizualizacja danych i eksport do MS Excel
  • Pulpity ryzyka dedykowany dla roli/grupy (Zarząd, RN, dyrektorzy obszarów)

Kolejny obiekt używany w module, ściśle powiązany z ryzykiem. Podstawowy podział zabezpieczeń to zabezpieczenia istniejące i planowane/realizowane. Zabezpieczenia istniejące to po prostu katalog dostępnych środków ogólnych (np. antywirus na stacji roboczej) lub dedykowanych dla konkretnego zasoby ( np. system gaśniczy w serwerowni, czy program motywacyjny dla pracowników, mający zmniejszyć ryzyko odejścia kluczowego personelu. Zabezpieczenia planowane/realizowane to po prostu plany postępowania z ryzykiem, uruchamiane w sytuacji, gdy dane ryzyko ma nieakceptowalny poziom (np. zakup szybszego systemu backup jeśli obecny nie pozwalaj na spełnienie czasów odtworzenia określonych podczas analizy BIA). Wykonany plan postępowania staje się aktywnym zabezpieczeniem. Każde z zabezpieczeń może mieć przypisaną wartość cyfrową, pozwalającą w sposób numeryczny ustalić aktualną wartość ryzyka po ich zastosowaniu/wyłączeniu.

.

Jeśli podjęta strategia postępowania z ryzykiem zakłada wykonanie określonych działań, wówczas w aplikacji przypisujemy do ryzyka wymaganą liczbę Planów Postępowania z Ryzykiem.  Plan postępowania z ryzykiem przedstawia, jakie zabezpieczenia będą zastosowane w celu ograniczenia zidentyfikowanego ryzyka oraz kto, w jakim zakresie oraz terminie jest odpowiedzialny za ich wdrożenie. Mechanizmy kontrolne (zabezpieczenie) są to elementy systemu zarządzania ryzykiem mające ograniczyć prawdopodobieństwo wystąpienia ryzyka lub zniwelować skutki zaistniałego ryzyka.

.

Jeśli podjęta strategia postępowania z ryzykiem zakłada wykonanie określonych działań, wówczas w aplikacji przypisujemy do ryzyka wymaganą liczbę Planów Postępowania z Ryzykiem.  Plan postępowania z ryzykiem przedstawia, jakie zabezpieczenia będą zastosowane w celu ograniczenia zidentyfikowanego ryzyka oraz kto, w jakim zakresie oraz terminie jest odpowiedzialny za ich wdrożenie. Mechanizmy kontrolne (zabezpieczenie) są to elementy systemu zarządzania ryzykiem mające ograniczyć prawdopodobieństwo wystąpienia ryzyka lub zniwelować skutki zaistniałego ryzyka.

.

Rejestry

Moduł ryzyka korzysta z wbudowanych słowników i rejestrów. Rejestry służą do budowania wewnętrznych bibliotek danych z poziomu aplikacji lub mogą być importowane z innych źródeł.

.

Rozbudowywalna bibliotek zagrożeń oraz przypisanych do nich podatności. Dla zagrożenia można określić jego numeryczną wartość.

.

Umożliwiaj ustalenie grup ryzyk na potrzeby biblioteki ryzyka. Dla każdej grupy określana jest kategoria ryzyka (słownikowana, możliwość dodania nowych) oraz typ ryzyka (również słownikowany).

.

Każda podatność ma określony status oraz wartość numeryczną, która może być wykorzystywana do obliczania poziomu ryzyka w bardziej zaawansowany sposób.

umożliwia określenie standardowych Planów Postępowania z Ryzykiem, które mogą być automatycznie przypisane (np. do systemu, aplikacji) po wykryciu podatności. Możliwe jest określenie domyślnej osoby, do której przypisany będzie PPR, strategia postępowania z ryzykiem, czy zastosowanie (zabezpieczenie, kontrola). Zastosowanie biblioteki pokazano w kolejnym rejestrze.

.

Do każdego ryzyka może zostać dodana ankieta, na którą odpowiada właściciel procesu, administrator lokalizacji, administrator systemu, szef HR itd., w zależności od kategorii i typu ryzyka. Każde z pytań może mieć zamknięte odpowiedzi, mające przydzielone wartość numeryczną i kod. W poniższym rejestrze wskazujemy, że jeżeli dla danego pytania zostanie wskazana dana odpowiedź to może to oznaczać potrzebę utworzenia/edycji ryzyka dla badanego zasobu/procesu i dodania do niego tej podatności. Opcjonalnie można wskazać, że po utworzeniu podatności należy od razu przypisać do ryzyka PPR dotyczący tejże podatności (0-N PPRów). Parametry te wykorzystywane są przez aplikację podczas fazy automatycznej analizy ryzyka.

.

Automatyzacja procesu i spójność danych <ROZWIŃ>

Moduły merytoryczne Platformy BCMLogic, w tym BCM, korzystają ze wspólnych modułów i mechanizmów technicznych. Ich wspólnym celem jest realizacja trzech głównych założeń.

  • Automatyzację powtarzalnych czynności i zapewnienie powtarzalnych i kompletnych działań dla takich samych obiektów biznesowych.
  • Zapewnienie spójności danych nie tylko na poziomie aplikacji, ale również, a może przede wszystkim, na poziomie organizacji czy grupie organizacji.
  • Ujednolicenie tworzonych dokumentów oraz komunikacji w ramach procesów.

Mechanizmy te wspominane są przy opisie funkcji biznesowych, natomiast poniżej udostępniamy zwarte kompedium na ich temat.

Workflow definiuje pełny cykl życia danego obiektu/dokumentu. Jako obiekt rozumiemy zbiór informacji dotyczącej pojedynczej instancji charakterystycznej dla danego procesu – audyt, analiza BIA procesu, ryzyko, procedura awaryjna, test BCM, incydent, dokument, odstępstwo, wniosek o zmianę itd.

Każdy typ obiektu może mieć do dyspozycji wiele różnych Workflow, odpowiadających jego specyfice. Przykładowo Workflow dla Procesu Biznesowego może różnić się od Usługi IT.

Workflow jest budowany na bazie stanu – odpowiadające punktom na graficznej prezentacji poniżej. Taki stan odpowiada statusowi obiektu biznesowego. W zależności od statusu można kontrolować widoczność i możliwość edycji zakładek w aplikacji. Przejścia Workflow, na grafie reprezentowane przez strzałki, oznaczają czynności możliwe do wykonania na bieżącym statusie obiektu. Po stronie aplikacji przejścia prezentowane są w postaci przycisków kontekstowych. Uprawnienie do wykonania przejścia jest kontrolowane na bazie ról systemowych. Dodatkowo, na każdym z przejść można zdefiniować wykonanie procedury lub polecenia. Przykładem zastosowania jest skrypt, który może wykonać złożoną kontrolę danych obiektu, przed zmianą statusu. Jeśli założony warunek (np. każda obserwacja musi mieć minimum jedną rekomendację) nie zostanie spełniony, wówczas wyświetlany jest komunikat, a status audytu pozostaje niezmieniony. Na przejściu można zdefiniować jedno lub więcej zdarzeń systemowych – powodujących utworzenie i wysłanie powiadomienia. Inną opcją przy definicji przejścia jest Schemat Akceptacji – sterujący tym kto i w jaki sposób ma zaakceptować zmianę statusu lub wyrazić opinię. Przykład zastosowania – akceptacja wyniku audytu przez przełożonego badanej jednostki.

Schemat akceptacja jest elementem określającym dodatkowy krok na przejściu Workflow, tam gdzie wymagane jest podjęcie i zarejestrowanie decyzji lub wyrażenie opinii przez jednostkę. Przypisanie danego schematu ma miejsce na poziomie edycji przejścia Workflow. Natomiast do zarządzania schematami dedykowany jest oddzielny ekran. Przede wszystkim akceptacja może być jedno lub wielopoziomowa, przy czym warunkiem przejścia na wyższy poziom jest uzyskanie akceptacji na niższym poziomie. Odrzucenie akceptacji niżej, powoduje anulowanie wszystkich akceptacji wyższego poziomy. Na poziomie definicji poziomu określa się aktorów akceptacji. Mogą to być osoby/grupy/role wskazane w schemacie, właściciel audytu itp. Po przekazaniu audytu do akceptacji, użytkownicy wyliczeni przez aplikację na podstawie definicji, otrzymują powiadomienie. Osoba akceptująca może/musi wpisać komentarz oraz zaakceptować (wówczas sterowanie Workflow przechodzi na kolejny stan) lub odrzucić (sterowanie wraca na stan wskazany w definicji Workflow).

Powiadomienia w systemie działają  w oparciu o tzw. zdarzenia (EVENT). Zdarzenie może być wywołane na kilka sposobów.

  • Wykonanie przejścia w ramach Workflow
  • Wykrycie zmiany w danych – np. automatyczna zmiana status użytkownika po imporcie danych z systemu kadrowego.
  • Spełnienie warunków wymagających utworzenia powiadomienia. Przykładowo: dla rekomendacji audytowej zostało mniej niż 30 dni do jej zakończenia.

Proces obsługi powiadomień regularnie sprawdza, czy pojawiły się nowe zdarzenia, dla których zdefiniowano komunikaty. Jeśli tak, wysyłane jest powiadomienie, przy użyciu kanału wskazanego w szablonie.

Poniżej: ekran definicji powiadomienia.

  • Mail –  skrzynka pocztowa, z której zostanie wysłane powiadomienie mail. Opcja Automatic Email pozwala dynamicznie podstawiać email w zależności od przypisania procesu w ramach struktury organizacyjnej – przydatne w opcji multicompany, gdzie mail powinien pochodzić z domeny konkretnej firmy z grupy.
  • Odbiorcy – możliwość elastycznego definiowania różnych kategorii Aktorów powiadamianych. W tym przypadku będzie to osoba, która jest określona w schemacie akceptacji jako odpowiedzialna za akceptację. Wskazane kategorie mogą być łączone.

System uprawnień oparty jest o Uprawnienia Atomowe, odnoszące się do pojedynczych ekranów, opcji czy przycisków, oraz o Role, które z jednej strony grupują poszczególne uprawnienia, a z drugiej są przypisywane do użytkowników.

Informacje o audycie podzielone są na tematyczne zakładki. System uprawnień pozwala na dynamiczne przydzielanie uprawnień do podglądu lub edycji danej zakładki, w zależności od kombinacji takich parametrów jak: rola użytkownika oraz status audytu.

BCMLogic umożliwia samodzielne zarządzanie użytkownikami i ich uprawnieniami. Rekomendowanym rozwiązaniem, jednym z wielu zapewniających spójność danych i bezpieczeństwo na poziomie organizacji, jest integracja z systemami dostarczającymi informację o użytkownikach i ich uprawnieniach. Integracja realizowana jest za pomocą mechanizmów ETL lub online, bezpośrednio z systemem zarządzającym tożsamością i uprawnieniami.

Administrator systemu ma dostęp do wielu różnych informacji dotyczących użytkownika, podzielonych na tematyczne zakładki.

    • Dane kontaktowe, logowania i status
    • Przynależność do jednostek organizacyjnych i grup zadaniowych
    • Przypisanie do ról systemowych
    • Powiązane elementy – szybki podgląd do obiektów, do których użytkownik posiada uprawnienia.
  • Dodatkowe informacje – niestandardowe dane potrzebne w danej organizacji.

Platforma BCMLogic przechowuje i wykorzystuje do działania strukturę organizacyjną przedsiębiorstwa oraz listę pracowników – wraz z ich przypisaniem do jednostek i pełnionych funkcji. Informacje te mogą być wprowadzane i zarządzane z poziomu aplikacji, ale częściej stosowaną metodą jest pobieranie ich z systemów źródłowych. Odbywa się to bądź przez mechanizm ETL bądź online poprzez komunikację z AD.

Praca w oparciu o faktyczne dane oznacza poprawność i spójność danych na poziomie całego procesu. Listy jednostek i pracowników używane są do wypełniania formularzy, definiowania powiadomień i akceptacji (zamiast konkretnej osoby, wskazujemy aktora: Właściciel jednostki), przypisywania rekomendacji itd.

Głównym sposobem logowania do Platformy BCMLogic jest tzw. SSO, czyli dostęp do aplikacji w oparciu o wcześniejsze uprawnienia uzyskane podczas logowania komputera użytkownika do domeny organizacji. Dla użytkownika oznacza to brak potrzeby pamiętania loginu i hasła. Jest to bardzo wygodne szczególnie wtedy, kiedy użytkownik korzysta z systemu okazjonalnie – np. gdy dostanie powiadomienie o działaniu do wykonania w ramach realizacji zaleceń poaudytowych. Klika wówczas w link dostarczony w powiadomieniu, aplikacja w tle weryfikuje uprawnienia i w przypadku pozytywnym, wyświetla odpowiedni ekran.

System szeroko wykorzystuje słowniki danych. Są to:

    • Słownik obiektów biznesowych – procesy, zasoby, podatności, lokalizacje, umowy, dostawcy itp.
    • Słowniki porządkujące dane – wszelkiego rodzaje typy i kategorie – np. typy zasobów, audytów, jednostek organizacyjnych i wiele innych
  • Słowniki etykiet ekranowych i komunikatów – przeważająca większość nazw ekranów, kolumn, przycisków i komunikatów może być ustawiana przez uprawnionego użytkownika z poziomu aplikacji.
Proces Zarządzania Ryzykiem wymienia dane z innymi procesami