Projekt unijnego rozporządzenia w sprawie digital operational resilience dla sektora finansowego. Co w nim znajdziemy?

Dzisiaj politico.eu dotarło do ciekawego projektu na poziomie UE, tj. Draft Regulation on digital operational resilience for the Union financial sector and amending Regulation EU/909/2014, Regulation EU/648/2012 and Regulation EC/1060/2009, czyli rozporządzenia dla sektora finansowego, które ma pokryć istotną kwestię cyfrowej odporności (digital operational resilience). Jest to tematyka, która jest na “topie” wśród regulatorów od wielu miesięcy. Założyć można, że przyśpieszona transformacja jest w jakimś stopniu przyczyną przyśpieszenia w tym zakresie. Wprawdzie projekt może ulec jeszcze wielu zmianom, ale warto przyjrzeć się najważniejszym założeniom. 

Zacznijmy od tego do jakich podmiotów ma być adresowane rozporządzenie. Zakres podmiotowy jest bardzo szeroki i co bardzo ciekawe mamy tam nie tylko „klasyczne” podmioty sektora finansowego, ale również dostawcy usług opartych o krypto-aktywa platformy crowdfundingowe czy tzw. data reporting service providers. Oznacza to, że zapewne pojawią się nowe definicje tych podmiotów na co zresztą wskazuje „słownicze”, który zawiera „wolne” miejsca na referencje do aktów prawnych. Warto tą kwestię monitorować, ale i pamiętać, że rozporządzenie finalnie może wyglądać inaczej.

O czym?

Zakres przedmiotowy jest również szeroki. W art. 1 mamy więc takie obszary jak:

1.       Zarządzanie ryzykami ICT;

2.       Raportowanie istotnych incydentów z obszaru ICT;

3.       Operacyjna odporność cyfrowa (digital operational resilience);

4.       Wymiana informacji w zakresie cyberbezpieczeństwa oraz

5.       Zasady zarządzania ryzykami stron trzecich (również w kontekście chmury obliczeniowej.

Patrząc nieco bardziej szczegółowo, projekt zakłada określenie najważniejszych wymogów dla third-party providers wchodzących w relacje umowne z instytucjami finansowymi, w tym w szczególności w kontekście realizacji odpowiednich KPI (szczegółowo określa to m.in. art. 28 określający Key contractual provisions). Mamy też pomysł wprowadzenia tzw. Oversight Framework dla krytycznych dostawców usług ICT dla sektora (zakładam, że podobnie jak to ma miejsce np. w Cybersecurity Act) – tutaj art. 29 (takie podmioty będą ponosiły opłaty nadzorcze). Są też zasady współpracy i wymiany informacji pomiędzy organami nadzoru.

Organizacja i governance 

Na samym początku mamy postanowienia dotyczące konieczności wprowadzenia wewnętrznych rozwiązań, które gwarantują efektywne zarządzanie ryzykami ICT. To co jest istotne to twardy wymóg dla zarządów instytucji finansowych do zarządzania tymi ryzykami oraz do „brania” za to odpowiedzialności. W projektowanym art. 4 ust. 2 mamy wskazane jakie obszary muszą zostać pokryte przez zarząd. Nie różnią się one zasadniczo od tego co znajdziemy np. w wytycznych EBA w sprawie ryzyk ICT i bezpieczeństwa.

Zarządzanie ryzykami 

Patrząc dalej mamy zasady zarządzania ryzykami ICT, w tym obowiązek wprowadzenia takich rozwiązań, które zapewnią „odpowiedź” na te ryzyka szybko, efektywnie i kompleksowo, ale w sposób proporcjonalny do rozmiaru „biznesu”. Obejmuje to m.in. tworzenie i wdrażanie strategii, polityk, procedur, protokołów i narzędzi, ale także infrastruktury. Mamy też obowiązek posiadania tzw. Digital Resilience Strategy.

W kolejnych artykułach mamy sporo „technicznych” aspektów składających się na całokształt działań związanych z zarządzania ryzykami ICT, w tym w zakresie identyfikacji czy planów zapasowych, ale także zobowiązanie do stworzenia ram do pozyskiwania informacji o zagrożeniach (analityki), które pozwolą na ich unikanie w przyszłości (learning and evolving).

Zarządzanie incydentami 

Kolejnym elementem jest prawidłowe zarządzanie incydentami. Tutaj rozporządzenie narzuca obowiązek posiadania odpowiedniego systemu, który to umożliwi, w tym będzie przekazywał stosowne alerty. Pojawiają się tez konkretne wymogi w zakresie klasyfikacji „wag” incydentów i zasady raportowania tzw. major incidents (mamy też mandaty dla EBA, ESMA i EIOPA do wydania standardów technicznych określających m.in. wzory formularzy zgłoszeniowych). Ma też powstać EU Hub dla zarządzania tymi incydentami.

Testowanie

W projekcie pojawiają nam się także wymogi w zakresie testowania digital operational resilience. Art. 22 i 23 określają jakimi narzędziami należy tego dokonywać i w jaki sposób. Ważnym wymogiem jest przeprowadzanie co najmniej raz na 3 lata tzw. Threat Led Penetration Testing. Są też wymogi dla samych testerów (wewnętrznych i zewnętrznych).

 Kary

Pojawiają nam się też kary. Zgodnie z projektem wyznaczone organy (zakładam, że m.in. KNF) będą mogły stosować określone narzędzia nadzorcze, w tym nakładać administracyjne kary pieniężne. Możliwa jest rezygnacja z wprowadzania nowych rozwiązań (administracyjnych), jeżeli zaniechania lub działania podlegają już odpowiedzialności karnej.

Od kiedy?

Propozycja zakłada, że rozporządzenie wejdzie w życie w 6 miesięcy od publikacji w dzienniku z wyjątkiem art. 23-25, które mają wejść dopiero po 3 latach.