środa, Październik 21

Zarządzanie ryzykiem operacyjnym (ICT) w projekcie rozporządzenia w sprawie Digital Operational Resilience

Google+ Pinterest LinkedIn Tumblr +

jednym z ostatnich artykułów pochyliliśmy się nad projektem rozporządzenia w sprawie digital operational resilience. Dzisiaj zagłębimy się w meandry zarządzania ryzykami operacyjnymi, co ma też związek z opublikowaną niedawno Rekomendacją Z. Tematyka ta jest od jakiegoś czasu silnie(j) akcentowana przez unijnych i krajowych regulatorów, jako szczególnie istotna w dobie cyfrowej transformacji i to zarówno po stronie banków, jak i użytkowników (klientów) usług finansowych. Dokonując analizy luki nie można także zapomnieć o projekcie ustawy zmieniającej ustawę o Krajowym Systemie Cyberbezpieczeństwa, która ma znaczenie dla operatorów usług kluczowych. Przejdźmy do konkretów!

Zasady odnoszące się do zarządzania ryzykami ICT znalazły swoje miejsce w art. 5 i następnych Rozporządzenia. Ogólnym wymogiem – raczej standardowym – jest wprowadzenie odpowiedniego systemu zarządzania ryzykami ICT, który zapewni „high level of digital operational resilience” (cyfrowa odporność). Taki system musi być oczywiście dostosowany do wymagań konkretnej organizacji.

Patrząc nieco szerzej, wytyczne 18 i 19 Rekomendacji Z [z zastrzeżeniem, że jest ona adresowana do banków]wskazują wyraźnie, że zarządzanie ryzykiem powinno odbywać się na bazie przyjętej strategii, polityk i procedur. W kontekście samego ryzyka operacyjnego mamy też rekomendację, że tym ryzykiem zarządzają jednostki biznesowe, które muszą to robić zgodnie nie tylko z przepisami czy regulacjami wewnętrznymi, ale z uwzględnieniem apetytu na ryzyko danej instytucji.

Warto tutaj zwrócić uwagę na fakt, że Bank Rozliczeń Międzynarodowych „zastanawiał” się ostatnio nad tym jak można podejść do kwestii zarządzania ryzykami w podmiotach o (wyłącznie) cyfrowej działalności (więcej tutaj).

Wróćmy jednak do projektu

No alt text provided for this image

Rozporządzenie „idzie” nieco szerzej, bo wskazuje że na system zarządzania ryzykiem ICT składają się nie tylko ww. dokumenty, ale także narzędzia czy „fizyczne komponenty” i infrastruktura, a więc oprogramowanie, serwery, centra przetwarzania danych czy pomieszczenia przeznaczone na określone działania mogące generować ryzyka operacyjne. Generalnie jest tak, i jest to zapis w rozporządzeniu, że instytucje muszą zrobić wszystko, aby zminimalizować ryzyko zmaterializowania się któregokolwiek z tych ryzyk.

Rozporządzenie zwraca również uwagę na kwestię systemów bezpieczeństwa, które powinny opierać się na uznanych zasadach międzynarodowych i być zaimplementowane w organizacji (mamy tutaj wyłączenie względem mikroprzedsiębiorstw). W rozporządzeniu znajdziemy też wyraźne stwierdzenie, że organizacja instytucji powinna zapewnić oddzielenie poszczególnych jednostek odpowiedzialnych za zarządzanie ryzykami ICT.

I co istotne wszystko musi być udokumentowane, przeglądane (co najmniej raz na rok) i w przypadku wystąpienia tzw. major-ICT incydent oraz w sytuacji, w której pojawiły się zalecenia pokontrolne organu nadzoru czy audytora (do tego tematu też wrócimy). Audyt to zresztą kolejny wymóg – częstotliwość określa sama instytucja bazując na identyfikacji „właściwych” dla niej ryzyk (to zresztą jedna z ważniejszych funkcji).

No właśnie. Czym jest znaczący incydent ICT?

Zanim przejdziemy dalej warto chwilę pochylić się nad tym zagadnieniem, bo ustalenie tej definicji może mieć znaczenie dla wewnętrznych procesów instytucji, które już mają wprowadzone zasady raportowania incydentów krytycznych, np. w kontekście PSD2 (pisałem o tym m.in. tutaj).

Projekt traktuje tzw. major ICT-related incident jako incydent dotyczący obszaru IT, który w znacznym stopniu może wpłynąć negatywnie na systemy IT kluczowe dla utrzymania funkcji krytycznych podmiotu podmiotu.

No alt text provided for this image

To jednak nie wszystko, bo musimy pochylić się nad kwestią czym w ogóle jest ICT-related incident. Tutaj nie ma „rocket science”. Będzie to takie zdarzenie, które dotyczy szeroko rozumianego obszaru ICT i bezpieczeństwa (niezależnie od źródła), które wpływa negatywnie na działanie instytucji (podmiotu).

Jeżeli chodzi o funkcje krytyczne (istotne) to mamy podobną definicję jak np. w wytycznych EBA w sprawie ICT risk. Będą to więc te funkcje, których przerwanie może wpłynąć na funkcjonowanie podmiotu w zgodzie z właściwymi regulacjami (zezwoleniem) czy po prostu wpływające na możliwość wykonywania podstawowej działalności. Ufff…. Chyba skończyliśmy. Warto spojrzeć czy nasze polityki i procedury odpowiadają tym „wymaganiom”.

I znowu nawrotka

Jako instytucja powinniśmy wyraźnie określić w jaki sposób będziemy działać z wynikami audytu (jeżeli pojawią się jakieś krytyczne uwagi). Te zasady powinny być spisane i wdrażane po każdej takiej kontroli.

Ważnym elementem jest tutaj jednak tzw. Resilience Strategy (to coś na wzór strategii ICT, którą wprowadziły wytyczne EBA w tym przedmiocie). Dokument ma być „kompleksowym” opisem w jaki sposób zasady zarządzania ryzykami będą wdrażane w instytucji. Art. 5 ust. 9 projektu „podaje” nam listę tego co powinno się tam znaleźć. Mamy więc m.in.:

1.    Wyjaśnienie jak system zarządzania ryzykami ICT wspiera strategię biznesową instytucji;

2.    Określenie tolerancji na ryzyko ICT (to raczej coś innego niż apetyt na ryzyko w rozumieniu Rekomendacji Z);

3.    Cele polityki bezpieczeństwa (informacji);

4.    Określenie architektury IT oraz zasad wprowadzania zmian (change management?);

5.    Zasady dot. zarządzania incydentami;

6.    Zasady i opis zarządzania dostawcami będącymi osobami trzecimi (struktura byłaby tutaj pożądana);

7.    Wymagania w zakresie tzw. digital operational resilience testing oraz

8.    Zasady dot. komunikacji.

No alt text provided for this image

I znowu ważne zastrzeżenie. Co do zasady to my oceniamy zgodność naszych działań z tą strategią, ale za zgodą organu nadzoru możemy „wydelegować” to zadanie na rzecz innego podmiotu (wchodzącego w skład naszej grupy kapitałowej lub zewnętrznego).

A jak ma wyglądać cała infrastruktura?

Odpowiedź znajdziemy w art. 6, który wymaga od nas, abyśmy utrzymywali i regularnie aktualizacji nasze środowisko IT. To środowisko powinno być skonstruowane tak, aby odpowiadało naszym potrzebom biznesowym i przygotowane na ewentualne spięcia (np. wzrost ruchu). Tutaj mamy też wskazanie, że choć możemy stosować różne międzynarodowe standardy, to zawsze musimy brać pod uwagę ewentualne rekomendacje naszych krajowych nadzorców.

Kolejne kroki…

Zakładając, że mamy wszystko powyższe, możemy przejść do bardziej szczegółowych działań w zakresie zarządzania ryzykami, w tym od identyfikacji. Tym tematem zajmiemy się jednak w kolejnej odsłonie.

Udostępnij.

Zostaw komentarz