Przewodnik DORA dla ubezpieczycieli krok po kroku

Przewodnik DORA dla ubezpieczycieli wyjaśnia, jak zarządzać ryzykiem ICT, testami, dostawcami oraz dowodami zgodności wymaganymi przez nadzór finansowy.

Awaria systemu likwidacji szkód, niedostępny portal klienta lub przejęte konto uprzywilejowane nie są wyłącznie problemem działu IT. Dla zakładu ubezpieczeń oznaczają ryzyko przerwania obsługi polis, błędnej wyceny szkód, naruszenia danych i presji raportowej wobec nadzoru. Przewodnik DORA dla ubezpieczycieli powinien więc zaczynać się nie od listy dokumentów, lecz od odpowiedzi na pytanie: które procesy biznesowe przestaną działać, jeżeli zawiedzie konkretna usługa ICT albo dostawca?

DORA zmienia punkt ciężkości z deklarowanej zgodności na operacyjną odporność cyfrową. Regulator oczekuje, że organizacja zna swoją ekspozycję, potrafi wykryć incydent, ograniczyć jego skutki, odtworzyć usługi oraz wykazać, że te zdolności zostały sprawdzone. W ubezpieczeniach szczególne znaczenie mają środowiska wielodostępne, integracje z pośrednikami, systemy taryfikacyjne, kanały mobilne oraz dostawcy przetwarzający dane klientów.

DORA dla ubezpieczycieli: od obowiązku do kontroli operacyjnej

Rozporządzenie DORA obejmuje między innymi zarządzanie ryzykiem ICT, obsługę i raportowanie incydentów, testowanie odporności cyfrowej, wymogi wobec dostawców usług ICT oraz nadzór zarządczy. Błędem jest prowadzenie tych obszarów jako pięciu niezależnych projektów. Jeżeli inwentaryzacja aktywów nie wskazuje właściciela biznesowego, zespół nie wyznaczy właściwego priorytetu remediacji. Jeżeli umowa z dostawcą nie daje prawa do audytu lub nie określa parametrów odtworzenia, plan ciągłości może pozostać nieweryfikowalny.

Najlepszym punktem startowym jest mapa zależności: proces biznesowy, usługa ICT, aplikacja, dane, infrastruktura, dostawca i właściciel. Dla procesu obsługi szkód taka mapa powinna objąć nie tylko główny system, lecz także mechanizmy uwierzytelniania, skanowanie dokumentów, interfejsy API, system powiadomień, kopie zapasowe oraz komponenty chmurowe. Dopiero wtedy można ocenić rzeczywisty wpływ awarii i określić wymagany czas odtworzenia.

W praktyce warto odróżnić krytyczność biznesową od technicznej. Serwer może być łatwy do odtworzenia, ale obsługiwać proces, którego przestój blokuje wypłatę świadczeń. Z kolei podatność o wysokiej ocenie technicznej może mieć ograniczony wpływ, gdy dotyczy odseparowanego środowiska bez danych produkcyjnych. Triage powinien łączyć ekspozycję, możliwość wykorzystania luki, wartość procesu, rodzaj danych i dostępność skutecznych kontroli kompensacyjnych.

Odpowiedzialność zarządu nie kończy się na zatwierdzeniu polityki

DORA wzmacnia odpowiedzialność organu zarządzającego za ryzyko ICT. Zarząd nie musi analizować technicznych logów ani samodzielnie zatwierdzać reguł SIEM. Musi jednak otrzymywać raport, który pozwala podjąć decyzję: jakie ryzyko akceptujemy, jakie finansujemy do usunięcia i gdzie brak zasobów może zagrozić ciągłości usług.

Dobry raport zarządczy nie jest tabelą wszystkich podatności. Pokazuje kilka mierników powiązanych z ryzykiem: liczbę krytycznych zależności bez potwierdzonego planu odtworzenia, odsetek luk krytycznych zamkniętych w SLA, czas wykrycia i ograniczenia incydentu, status testów oraz ryzyka wynikające z dostawców. Każda pozycja powinna mieć właściciela, termin, decyzję oraz dowód wykonania.

Warto ustalić regularny cykl przeglądów ryzyka ICT z udziałem bezpieczeństwa, IT, właścicieli procesów, compliance, prawników i zakupów. Bez udziału biznesu klasyfikacja krytycznych usług będzie teoretyczna. Bez zakupów i prawników organizacja może nie być w stanie skutecznie zmienić warunków współpracy z dostawcą. Bez zespołów technicznych deklarowana remediacja nie przełoży się na zmianę konfiguracji, segmentacji lub kodu aplikacji.

Incydenty: liczy się czas, klasyfikacja i materiał dowodowy

W środowisku ubezpieczeniowym incydent często nie zaczyna się od jednoznacznego alarmu. Może to być wzrost błędów w integracji z pośrednikiem, nietypowa aktywność konta administratora, nagły spadek wydajności procesu taryfikacji lub wyciek dokumentów przesłanych przez klienta. Dlatego monitoring musi obejmować nie tylko infrastrukturę, ale też zachowanie użytkowników, aplikacje, tożsamości, interfejsy API i usługi chmurowe.

Procedura reagowania powinna rozdzielać trzy działania: techniczne ograniczenie zdarzenia, ocenę wpływu biznesowego oraz decyzję dotyczącą eskalacji i raportowania. Te ścieżki biegną równolegle. Czekanie na pełną analizę techniczną przed zaangażowaniem właściciela procesu może wydłużyć przestój. Z drugiej strony zgłoszenie oparte na niezweryfikowanych danych utrudnia późniejsze wyjaśnienie skali zdarzenia.

Dowody procesów mają tu znaczenie porównywalne z samą reakcją. Organizacja powinna móc wykazać, kiedy wykryła zdarzenie, kto nadał klasyfikację, jakie systemy objęto analizą, jakie decyzje podjęto, kiedy przywrócono usługę i jakie działania zapobiegawcze wdrożono. Zapis w systemie zgłoszeniowym, logi, protokół kryzysowy oraz potwierdzenie zamknięcia działań powinny tworzyć spójny łańcuch dowodowy.

Testowanie odporności nie może być ćwiczeniem prezentacyjnym

Testy DORA powinny odpowiadać rzeczywistemu profilowi ryzyka. Dla jednego ubezpieczyciela priorytetem będzie odporność portalu samoobsługowego na ataki aplikacyjne i przejęcia kont. Dla innego - scenariusz niedostępności platformy chmurowej, kompromitacji dostawcy obsługującego obieg dokumentów albo ransomware w środowisku przetwarzającym szkody.

Skuteczny program łączy skanowanie podatności, testy penetracyjne, weryfikację konfiguracji chmury, ćwiczenia reakcji na incydent i testy odtworzeniowe. Nie każdy system wymaga tego samego poziomu intensywności. Zakres należy dobierać proporcjonalnie do krytyczności usługi, ekspozycji internetowej, wartości danych oraz historii incydentów. Istotne jest jednak, aby test kończył się kontrolowaną remediacją, a nie raportem odłożonym do repozytorium.

Przydatnym miernikiem jest odsetek ustaleń zamkniętych w określonym SLA, potwierdzonych retestem. Sama deklaracja właściciela systemu, że poprawka została wdrożona, nie jest wystarczającym dowodem. Retest może wykazać, że luka nadal istnieje w innym komponencie, reguła WAF nie obejmuje wszystkich ścieżek lub uprawnienia nadmierne pozostają aktywne w kontach serwisowych.

Dostawcy ICT: umowa jest elementem bezpieczeństwa

Ubezpieczyciele korzystają z rozbudowanego ekosystemu dostawców: chmury, centrów danych, systemów polisowych, call center, OCR, podpisu elektronicznego, analityki, usług płatniczych i zewnętrznego wsparcia IT. Ryzyko nie znika po podpisaniu umowy. Przechodzi częściowo poza organizację, ale odpowiedzialność regulacyjna pozostaje po jej stronie.

Rejestr informacji o umowach powinien umożliwiać szybkie ustalenie, kto wspiera krytyczną funkcję, gdzie przetwarzane są dane, jakie istnieją zależności podwykonawcze i jak wygląda scenariusz wyjścia z usługi. Szczególnej uwagi wymagają koncentracja usług u jednego dostawcy oraz sytuacje, w których kilka pozornie niezależnych aplikacji korzysta z tej samej platformy chmurowej lub mechanizmu tożsamości.

W umowach należy operacyjnie uregulować wymagania bezpieczeństwa, raportowanie incydentów, współpracę podczas dochodzeń, parametry dostępności, testy, audyt oraz zwrot lub migrację danych. Zbyt ogólna klauzula o zachowaniu należytej staranności nie pozwoli egzekwować oczekiwań w kryzysie. Równie ryzykowne jest kopiowanie zapisów bez analizy możliwości ich wykonania przez dostawcę. Wymóg prawa do audytu trzeba zestawić z realnym modelem świadczenia usługi, dostępnymi raportami niezależnych audytorów i dodatkowymi mechanizmami weryfikacji.

Plan wdrożenia, który daje mierzalny efekt

Pierwsze 30 dni warto przeznaczyć na ocenę luk i ustalenie stanu faktycznego. Celem nie jest stworzenie obszernej prezentacji, lecz potwierdzenie zakresu usług krytycznych, kompletności rejestru aktywów, jakości klasyfikacji incydentów, statusu umów i istniejących dowodów testowania.

W kolejnym etapie organizacja powinna przypisać właścicieli działań, określić SLA remediacji oraz zbudować rejestr ryzyk z decyzjami zarządczymi. Równolegle należy naprawić luki o najwyższym wpływie: niezarządzane konta uprzywilejowane, brak wieloskładnikowego uwierzytelniania, niezweryfikowane kopie zapasowe, publicznie dostępne interfejsy administracyjne czy brak monitoringu kluczowych zdarzeń.

Następnie przychodzi czas na test scenariuszowy i retest działań naprawczych. To moment, w którym dokumentacja spotyka się z operacją: SOC weryfikuje wykrywanie, zespół IT odtwarza usługę, biznes ocenia wpływ, a compliance sprawdza kompletność dowodów. SprintTech w takich projektach łączy ocenę techniczną z priorytetyzacją ryzyka i raportowaniem gotowym dla zarządu, aby lista ustaleń przełożyła się na wykonane zadania, a nie kolejny plan bez właściciela.

DORA nie jest projektem, który można zamknąć po audycie. Największą wartość daje wtedy, gdy cotygodniowy triage podatności, kwartalne przeglądy ryzyka i regularne testy prowadzą do jednej rzeczy: organizacja zna swoje słabe punkty, potrafi je usunąć i umie to udowodnić, zanim awaria zrobi to za nią.