5 dni temu
17 stycznia 2025 r. odporność cyfrowa przestała być w sektorze finansowym wyłącznie zagadnieniem technicznym. Recenzja rozporządzenia DORA prowadzi do prostego wniosku: unijny prawodawca oczekuje, iż zarząd będzie umiał wykazać kontrolę nad ryzykiem ICT równie przekonująco jak nad ryzykiem kredytowym, operacyjnym czy prawnym.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554, znane jako DORA, nie tworzy jednego obowiązku, który można zamknąć wdrożeniem narzędzia do cyberbezpieczeństwa. Buduje raczej spójny model governance obejmujący zarządzanie, dokumentację, testowanie, reakcję na incydenty oraz relacje z zewnętrznymi dostawcami technologii. To właśnie ta systemowość jest największą zaletą regulacji, ale też źródłem jej kosztów i trudności wdrożeniowych.
Recenzja rozporządzenia DORA: regulacja o odpowiedzialności
DORA obejmuje szeroki katalog podmiotów finansowych, w tym banki, firmy inwestycyjne, zakłady ubezpieczeń, instytucje płatnicze, dostawców usług w zakresie kryptoaktywów oraz niektóre podmioty funkcjonujące w ramach infrastruktury rynku finansowego. Zakres zastosowania należy jednak ustalać indywidualnie. Sam fakt działania w branży fintech nie przesądza jeszcze o pełnym podleganiu rozporządzeniu, podobnie jak status małego przedsiębiorstwa nie eliminuje automatycznie wszystkich obowiązków.
Kluczowe jest przesunięcie perspektywy. DORA nie pyta wyłącznie, czy organizacja posiada politykę bezpieczeństwa, kopie zapasowe i umowę z dostawcą chmury. Pyta, czy te elementy tworzą mechanizm zdolny do utrzymania krytycznych usług finansowych podczas zakłócenia oraz czy organ zarządzający rzeczywiście rozumie ryzyka związane z technologią.
Odpowiedzialność organu zarządzającego została w rozporządzeniu ujęta wyraźnie. Zarząd ma określać, zatwierdzać, nadzorować i ponosić odpowiedzialność za ramy zarządzania ryzykiem ICT. Delegowanie zadań do działu IT, CISO lub zewnętrznego konsultanta może być operacyjnie rozsądne, ale nie przenosi odpowiedzialności regulacyjnej. W praktyce wymusza to lepszy przepływ informacji między technologią, compliance, ryzykiem, bezpieczeństwem i biznesem.
Pięć filarów, które trzeba czytać łącznie
Konstrukcja DORA opiera się na pięciu wzajemnie zależnych obszarach. Pierwszym jest zarządzanie ryzykiem ICT. Instytucja powinna znać swoje aktywa informacyjne, systemy, zależności, procesy krytyczne oraz słabe punkty. Rejestr systemów sam w sobie nie wystarczy, jeżeli nie pozwala ustalić, która usługa przestanie działać po awarii określonego komponentu lub dostawcy.
Drugim filarem jest zgłaszanie poważnych incydentów związanych z ICT. Regulacja wymaga procedur identyfikacji, klasyfikacji, eskalacji i raportowania. Organizacja musi więc wcześniej zdecydować, kto ocenia wagę incydentu, kto kontaktuje się z adekwatnym organem, jakie dane są zbierane i jak komunikacja z klientami pozostaje spójna z komunikacją nadzorczą. Chaos informacyjny po ataku ransomware lub awarii środowiska chmurowego może stanowić problem regulacyjny niezależnie od samej technicznej przyczyny zdarzenia.
Trzeci obszar to testowanie operacyjnej odporności cyfrowej. DORA wymaga testów proporcjonalnych do skali, profilu ryzyka i znaczenia podmiotu. Dla części instytucji wystarczą regularne testy podatności, scenariusze ciągłości działania czy ćwiczenia reagowania na incydenty. Najważniejsze podmioty mogą zostać objęte zaawansowanymi testami penetracyjnymi prowadzonymi z wykorzystaniem informacji o zagrożeniach, czyli TLPT.
Czwarty filar dotyczy wymiany informacji i informacji o cyberzagrożeniach. Rozporządzenie dostrzega, iż izolowane organizacje reagują wolniej. Udział w zaufanych mechanizmach wymiany informacji może poprawić wykrywanie zagrożeń, ale wymaga ostrożności w zakresie tajemnicy zawodowej, ochrony danych, tajemnicy przedsiębiorstwa i reguł konkurencji.
Piątym, najbardziej wymagającym w praktyce, jest zarządzanie ryzykiem wynikającym z korzystania z usług ICT świadczonych przez dostawców zewnętrznych. To obszar, w którym DORA najmocniej ingeruje w dotychczasowe modele kontraktowania usług technologicznych.
Umowa z dostawcą nie może być już tylko dokumentem zakupowym
Wiele instytucji finansowych korzysta z usług chmurowych, systemów do obsługi płatności, narzędzi KYC, rozwiązań analitycznych, dostawców cyberbezpieczeństwa i podwykonawców utrzymujących starsze systemy. DORA nie zakazuje outsourcingu. Przeciwnie, przyjmuje go jako trwały element rynku. Nakazuje jednak sprawować nad nim kontrolę odpowiednią do ryzyka.
W praktyce oznacza to konieczność prowadzenia rejestru informacji o wszystkich umowach dotyczących usług ICT. Instytucja musi umieć wskazać dostawcę, rodzaj usługi, podwykonawców, miejsce przetwarzania danych, charakter wspieranych funkcji oraz znaczenie usługi dla działalności. Szczególnej oceny wymagają usługi wspierające funkcje krytyczne lub istotne.
DORA wymusza również przegląd klauzul kontraktowych. W umowach należy odpowiednio uregulować między innymi poziomy usług, wymogi bezpieczeństwa, zasady współpracy przy incydentach, dostęp do informacji, uprawnienia audytowe, warunki korzystania z podwykonawców oraz uporządkowane zakończenie współpracy. Najtrudniejsze bywają negocjacje z globalnymi dostawcami chmurowymi, którzy opierają relację na standardowych wzorcach umownych.
Nie oznacza to, iż każda instytucja ma realną możliwość wynegocjowania dowolnego postanowienia. Znaczenie ma skala podmiotu, rodzaj usługi i jego pozycja negocjacyjna. Nie zwalnia to jednak z udokumentowania analizy ryzyka oraz z przygotowania strategii wyjścia. Strategia wyjścia nie powinna być deklaracją, iż dane da się kiedyś przenieść. Musi odpowiadać na pytanie, ile potrwa migracja, kto ją przeprowadzi, jak zachować ciągłość działania i czy alternatywa w ogóle istnieje.
Co DORA robi dobrze, a gdzie pojawiają się ryzyka
Największą wartością DORA jest zastąpienie rozproszonego podejścia wspólnym językiem odporności cyfrowej. Regulacja łączy kwestie, które w wielu organizacjach funkcjonowały osobno: cyberbezpieczeństwo, outsourcing, ciągłość działania, nadzór korporacyjny i raportowanie incydentów. Dla grup kapitałowych działających w kilku państwach UE jest to szczególnie istotne, ponieważ ułatwia budowę wspólnych standardów.
DORA trafnie rozpoznaje też ryzyko koncentracji u niewielkiej liczby dużych dostawców ICT. Awaria dominującego dostawcy infrastruktury chmurowej może równocześnie zakłócić usługi wielu instytucji, choćby jeżeli każda z nich z osobna spełnia podstawowe wymagania bezpieczeństwa. Stąd unijny mechanizm nadzoru nad krytycznymi zewnętrznymi dostawcami usług ICT.
Słabszą stroną regulacji jest jej ciężar organizacyjny. Podmiot o ograniczonych zasobach może odczuwać DORA przede wszystkim jako obowiązek tworzenia rejestrów, procedur, ocen i dowodów wykonania kontroli. Ryzyko formalizmu jest realne. Dobrze napisana polityka nie zmniejsza skutków incydentu, o ile nie została przećwiczona, a osoby odpowiedzialne nie znają swoich ról.
Dlatego zasada proporcjonalności powinna być stosowana rozsądnie, a nie jako wygodny argument za zaniechaniem. Mniejsza organizacja nie musi kopiować struktury banku systemowego. Powinna jednak umieć wykazać, dlaczego przyjęte zabezpieczenia, częstotliwość testów i model nadzoru nad dostawcą odpowiadają jej konkretnemu profilowi ryzyka.
Od czego zacząć wdrożenie
Najbardziej użytecznym pierwszym krokiem jest diagnoza, a nie zakup kolejnego systemu bezpieczeństwa. Należy zestawić wymogi DORA z faktycznym sposobem działania organizacji: usługami krytycznymi, architekturą systemów, incydentami z ostatnich lat, umowami ICT oraz aktualnym podziałem odpowiedzialności.
Następnie warto ustalić właścicieli poszczególnych działań i harmonogram usuwania luk. Część braków będzie miała charakter kontraktowy, inne proceduralny albo techniczny. Nie wszystkie należy usuwać w tej samej kolejności. Pierwszeństwo powinny mieć te obszary, w których zakłócenie może zatrzymać funkcję krytyczną, narazić klientów na szkodę lub uniemożliwić terminowe raportowanie.
Szczególnej uwagi wymaga dokumentowanie decyzji zarządczych. Przy kontroli liczy się nie tylko końcowy rezultat, ale także możliwość wykazania, iż podmiot rozpoznał ryzyko, ocenił warianty i podjął adekwatne działania. DORA premiuje organizacje, które potrafią przedstawić spójną historię swoich decyzji, zamiast gromadzić dokumenty dopiero po incydencie.
Najlepszym sprawdzianem przygotowania nie jest więc liczba przyjętych polityk. Warto postawić zespołowi konkretne pytanie: co wydarzy się jutro rano, jeżeli najważniejszy dostawca ICT utraci dostępność, a klienci zaczną zgłaszać problemy? o ile odpowiedź wskazuje osoby, decyzje, dane i realny plan działania, compliance DORA zaczyna spełniać swoją adekwatną funkcję.
