DORA w ubezpieczeniach: rejestr informacji, incydenty ICT i strategia wyjścia w praktyce

Kogo w sektorze ubezpieczeń obejmuje DORA?

Zgodnie z art. 2 ust. 1 DORA rozporządzenie obejmuje:

• zakłady ubezpieczeń i zakłady reasekuracji,
• pośredników ubezpieczeniowych, pośredników reasekuracyjnych i pośredników oferujących ubezpieczenia uzupełniające.

Są dwa ważne wyłączenia (art. 2 ust. 3):

• pośrednicy ubezpieczeniowi, reasekuracyjni i oferujący ubezpieczenia uzupełniające, którzy są mikro, małymi lub średnimi przedsiębiorstwami,
• małe zakłady ubezpieczeń wyłączone z dyrektywy Wypłacalność II (art. 4 dyrektywy 2009/138/WE).

W praktyce DORA dotyczy więc zakładów ubezpieczeń i dużych brokerów oraz agentów. Warto też pamiętać, że uproszczone ramy zarządzania ryzykiem ICT z art. 16 nie obejmują ubezpieczycieli. Stosują oni pełne wymagania, z zasadą proporcjonalności z art. 4.

Co to jest rejestr informacji DORA?

Rejestr informacji (art. 28 ust. 3) to kompletna ewidencja wszystkich umów o usługi ICT od zewnętrznych dostawców, prowadzona na poziomie podmiotu, a w grupach także na poziomie subskonsolidowanym i skonsolidowanym. Rejestr musi odróżniać umowy wspierające funkcje krytyczne lub istotne od pozostałych.

Strukturę rejestru określa rozporządzenie wykonawcze (UE) 2024/2956: kilkanaście powiązanych tabel (wzory B_01 do B_07 i B_99) opisujących podmiot, umowy, dostawców, łańcuch podwykonawców, funkcje i usługi. Każdy dostawca będący osobą prawną musi być zidentyfikowany kodem LEI lub EUID, a przy funkcjach krytycznych lub istotnych także jego podwykonawcy.

Rejestr informacji DORA w KNF: terminy i najczęstsze błędy

W Polsce rejestr przekazuje się do KNF na formularzu SPR-PF-18 przez System Sprawozdawczości DORA (crp.knf.gov.pl). Pierwsze raportowanie w 2025 r. objęło dane według stanu na 31 marca 2025 r. Z powodu problemów z wypełnianiem KNF przedłużyła termin do 28 kwietnia 2025 r., a w maju przeprowadziła drugi etap dla podmiotów, które nie złożyły rejestru lub których rejestr został odrzucony przy walidacji.

Skalę wyzwania pokazał próbny przebieg zorganizowany przez europejskie urzędy nadzoru w 2024 r.: spośród prawie 1000 uczestników tylko 6,5% rejestrów przeszło wszystkie 116 kontroli jakości danych.

Najczęstsze problemy zgłaszane w praktyce:

• brak kodów LEI lub EUID dostawców albo mylenie tych identyfikatorów,
• niepełny łańcuch podwykonawców przy funkcjach krytycznych lub istotnych,
• pominięcie usług wewnątrzgrupowych,
• zbyt ogólna klasyfikacja usług (np. „chmura” zamiast właściwej kategorii z taksonomii),
• rejestr aktualizowany raz w roku zamiast na bieżąco.

Ostatni punkt jest źródłem pozostałych. Jeśli rejestr żyje w arkuszu uzupełnianym przed terminem, dane o umowach, dostawcach i podwykonawcach rozjeżdżają się z rzeczywistością przez cały rok.

Co DORA przewiduje w zakresie zgłaszania incydentów ICT?

Poważne incydenty ICT zgłasza się do KNF, w Polsce przez portal CSIRT KNF. Klasyfikację określa rozporządzenie delegowane (UE) 2024/1772. Incydent jest poważny, jeśli dotyczy usług krytycznych i spełnia jeden z warunków: nastąpił złośliwy, nieuprawniony dostęp do sieci i systemów skutkujący utratą danych albo przekroczono co najmniej dwa inne progi istotności (np. liczba klientów, czas trwania, zasięg geograficzny, straty). Powtarzające się incydenty o tej samej przyczynie mogą zostać zakwalifikowane łącznie.

Terminy zgłoszeń określa rozporządzenie delegowane (UE) 2025/301:

Cztery godziny od klasyfikacji to bardzo mało, jeśli procedura dopiero zaczyna się od szukania, kto ma dostęp do danych i kto podpisuje zgłoszenie. Kryteria klasyfikacji, role i szablony muszą być przygotowane zawczasu. Jeśli incydent oznacza też naruszenie ochrony danych osobowych, równolegle biegnie 72-godzinny termin zgłoszenia do UODO z RODO.

Dlaczego DORA wymaga posiadania strategii wyjścia?

Bo ubezpieczyciel odpowiada za ciągłość usług dla klientów niezależnie od tego, czy jego system obsługi polis działa we własnej serwerowni, czy u zewnętrznego dostawcy. Art. 28 ust. 8 DORA wymaga strategii wyjścia dla każdej usługi ICT wspierającej funkcję krytyczną lub istotną.

Strategia musi uwzględniać co najmniej:

• awarię dostawcy,
• pogorszenie jakości usług,
• zakłócenia działalności,
• istotne ryzyko dla ciągłości usługi,
• wypowiedzenie umowy.

Plan wyjścia ma być kompleksowy, udokumentowany, wystarczająco przetestowany i okresowo przeglądany. Musi wskazywać rozwiązania alternatywne i plan przejściowy: jak odzyskać usługę i dane od dostawcy i przenieść je do innego dostawcy albo do siebie, bez zakłóceń i bez naruszenia przepisów. Po stronie umowy odpowiada temu obowiązkowy okres przejściowy (art. 30 ust. 3).

Testy odporności cyfrowej: co musi ubezpieczyciel?

Podmioty inne niż mikroprzedsiębiorstwa muszą co najmniej raz w roku testować wszystkie systemy i aplikacje ICT wspierające funkcje krytyczne lub istotne (art. 24 ust. 6). Katalog testów obejmuje m.in. oceny podatności, przeglądy kodu i oceny bezpieczeństwa sieci.

Zaawansowane testy penetracyjne w oparciu o analizę zagrożeń (TLPT) przeprowadza się co najmniej raz na 3 lata, ale tylko w podmiotach wyznaczonych przez organ nadzoru na podstawie ich znaczenia dla sektora i profilu ryzyka. W Polsce decyduje o tym KNF.

Kto za co odpowiada? Mapa ról w zakładzie ubezpieczeń

DORA dotyka kilku działów jednocześnie. Brak jasnego podziału ról to najczęstsza przyczyna, dla której rejestr informacji jest niekompletny, a zgłoszenie incydentu się opóźnia.

Taka tabela, zatwierdzona przez zarząd, jest jednocześnie dowodem na to, że organ zarządzający sprawuje nadzór nad ryzykiem ICT.

Dobre praktyki: jak utrzymać DORA w trybie ciągłym

1. Jeden rejestr dostawców dla wszystkich celów. Te same dane o dostawcach służą rejestrowi informacji, ocenie ryzyka, strategiom wyjścia i odpowiedziom na pytania audytora.
2. Klasyfikacja funkcji na początku. Lista funkcji krytycznych lub istotnych decyduje, które umowy wymagają pełnych klauzul z art. 30 ust. 3, strategii wyjścia i szczegółowego raportowania podwykonawców.
3. Zbieranie LEI przy podpisywaniu umowy, a nie przed terminem raportowania.
4. Ćwiczenia z procedury incydentów z mierzonym czasem od wykrycia do klasyfikacji i wstępnego powiadomienia.
5. Kwartalny przegląd strategii wyjścia dla najważniejszych dostawców.
6. Raport dla zarządu: DORA przypisuje organowi zarządzającemu ostateczną odpowiedzialność za zarządzanie ryzykiem ICT (art. 5 ust. 2).

W jednym z polskich towarzystw ubezpieczeniowych wdrażamy moduł Audomate AI Vendor and Risk Manager. Automatyzuje on ocenę i monitoring dostawców ICT, weryfikację klauzul umownych i utrzymanie danych potrzebnych do rejestru informacji. Zespół ryzyka zamiast zbierać dane przed terminem, pracuje na bieżącym obrazie.

Sprawdź to na swoich danych w 4 tygodnie. W pilotażu Audomate porządkujemy rejestr dostawców ICT, oceniamy umowy pod kątem art. 30 DORA i przygotowujemy raport dla zarządu.

Umów 4-tygodniowy pilotażZacznij od 15-minutowego demo