DORA: ryzyko ICT, dostawcy i dowody

Definicja: DORA to operacyjna odporność cyfrowa sektora finansowego

DORA wprowadza wspólne zasady odporności cyfrowej dla sektora finansowego. Jej celem jest to, aby banki, instytucje płatnicze, firmy inwestycyjne, ubezpieczyciele oraz inne podmioty finansowe potrafiły utrzymać usługi mimo awarii ICT, cyberataku, błędu dostawcy albo incydentu operacyjnego. Najkrócej: DORA wymaga powiązania usług krytycznych z systemami ICT, dostawcami, testami, incydentami, decyzjami zarządu i dowodami działania kontroli.

Jak prowadzić działania naprawcze DORA

Zakres ustal według rodzaju podmiotu, wyłączeń i zasady proporcjonalności. Harmonogram poprawy nie zawiesza obowiązujących wymagań: zgłaszanie incydentów, ochrona dostępów, kopie i nadzór muszą działać. Pilne luki wymagają niezwłocznej reakcji, a przeglądy po 30/60/90 dniach służą ocenie postępu.

• Funkcje krytyczne lub ważne: klasyfikuj je według kryteriów DORA i wpływu zakłócenia, a nie wyłącznie potocznego znaczenia słowa „krytyczny”.
• System ICT: aplikacja, infrastruktura, chmura, sieć, backup lub usługa dostawcy wspierająca funkcję krytyczną.
• Dokumentacja wykonanych działań: wynik testu, raport, log, decyzja właściciela, protokół przeglądu albo potwierdzona zmiana.
• Plan naprawczy: właściciele, terminy, zależności i środki tymczasowe; samo przyjęcie planu nie usuwa niezgodności.
• Przegląd po 30 dniach: oceń mapę funkcji, rejestr informacji, braki dowodowe i wyniki testów kopii.
• Przegląd po 60 dniach: zweryfikuj działanie klasyfikacji i zgłaszania incydentów, plan testów, umowy oraz raporty.
• Przegląd po 90 dniach: oceń nadzór nad dostawcami, monitoring, odtwarzanie, uprawnienia i kompletność dowodów.
• Po 90 dniach: cykliczna obsługa systemów ICT, osoby odpowiedzialne za kontrole, aktualizacja ryzyk i lista zadań poprawiających odporność.

Aktualność prawna: DORA już obowiązuje operacyjnie

DORA, czyli Digital Operational Resilience Act, to rozporządzenie (UE) 2022/2554. Zgodnie z tekstem aktu stosuje się je od 17 stycznia 2025 r., więc w 2026 roku nie jest to projekt przygotowawczy, tylko obowiązujący reżim odporności ICT. W praktyce wymaga połączenia compliance, cyberbezpieczeństwa, ciągłości działania, dostawców ICT i utrzymania IT.

Co DORA zmienia po stronie organizacji

DORA nie jest wyłącznie projektem compliance. To sprawdzian, czy usługi finansowe mogą działać mimo awarii, cyberincydentu, błędu dostawcy lub problemu z infrastrukturą ICT. Dokumentacja ma sens tylko wtedy, gdy jest powiązana z realnymi systemami, testami, decyzjami zarządu, odpowiedzialnością właścicieli usług oraz cyklicznym raportowaniem luk. Największym wyzwaniem DORA jest połączenie języka ryzyka, compliance i IT.

Główne obszary DORA

W praktyce projekt DORA trzeba prowadzić jako mapę zależności między usługą biznesową, systemem ICT, dostawcą, ryzykiem, kontrolą i dowodem. Bez tej mapy łatwo stworzyć polityki, których nikt nie potrafi utrzymać. Kluczowe wymogi DORA obejmują ramy zarządzania ryzykiem ICT, klasyfikację i raportowanie incydentów, regularne testy odporności operacyjnej, zarządzanie ryzykiem dostawców ICT oraz utrzymywanie dokumentacji, która pokazuje decyzje, działania i wyniki testów.

• Zarządzanie ryzykiem ICT: aktywa, procesy, właściciele, wpływ biznesowy, tolerancja ryzyka i decyzje zarządcze.
• Obsługa incydentów: klasyfikacja, eskalacja, komunikacja, rejestr, raportowanie i wnioski po zdarzeniu.
• Testowanie odporności: backup, odtwarzanie, scenariusze awarii, podatności, ciągłość działania i ćwiczenia.
• Ryzyko dostawców ICT: umowy, podwykonawcy, krytyczność, plan zakończenia współpracy z dostawcą, SLA, raporty i przeglądy.
• Dobrowolna wymiana informacji o zagrożeniach: uzgodnione zasady, poufność i ochrona danych; art. 45 nie nakazuje udziału w każdym takim porozumieniu.

Kogo dotyczy DORA?

DORA stosuje się bezpośrednio do objętych nią podmiotów finansowych. Zwykli dostawcy ICT mogą odczuwać jej skutki przez wymagania umowne i operacyjne klientów finansowych, natomiast bezpośrednie ramy nadzoru DORA dotyczą dostawców wyznaczonych jako kluczowi zewnętrzni dostawcy usług ICT. Dlatego zakres trzeba ustalić osobno dla podmiotu regulowanego, jego usług oraz dostawców wspierających funkcje krytyczne lub ważne.

Odpowiedzialność organu zarządzającego i właścicieli usług

Właściciele usług prowadzą uzgodnione działania i eskalują ryzyka. Organ zarządzający zachowuje odpowiedzialność za ramy ryzyka ICT; outsourcing i akceptacja ryzyka nie znoszą obowiązków regulacyjnych.

• Które funkcje są krytyczne lub ważne i jakie systemy ICT je obsługują.
• Jaki przestój, utrata danych lub degradacja usługi są nieakceptowalne biznesowo.
• Który dostawca ICT ma ryzyko koncentracji, zależności od podwykonawców albo brak planu zakończenia współpracy z dostawcą.
• Jak klasyfikujemy incydenty i kto decyduje o eskalacji, komunikacji oraz raporcie końcowym.
• Jakie dowody trafiają do zarządu po teście, incydencie, przeglądzie dostawcy i akceptacji wyjątku.

Jak przełożyć DORA na systemy i właścicieli

Najczęściej brakuje nie samej polityki, lecz połączenia między usługą biznesową, systemem, dostawcą, ryzykiem i dowodem działania. Bez tej relacji organizacja nie wie, kto ma wykonać test, kto akceptuje ryzyko i co pokazać podczas kontroli.

• Dla każdej usługi krytycznej wskaż systemy ICT, dane, integracje, właściciela biznesowego i właściciela technicznego.
• Dla każdego dostawcy określ krytyczność, SLA, miejsce przetwarzania, podwykonawców, plan zakończenia współpracy z dostawcą i sposób odbioru raportów.
• Dla każdej kontroli przypisz dowód: wynik testu, log, protokół, decyzję, raport monitoringu albo akceptację wyjątku.
• Dla incydentów ustal klasyfikację, progi eskalacji, osoby kontaktowe, terminy raportowania i wzór wniosków po zdarzeniu.
• Dla zarządu przygotuj krótką mapę ryzyk, kosztów, tolerancji i decyzji wymagających zatwierdzenia.

DORA, NIS2 i cyberbezpieczeństwo techniczne

DORA koncentruje się na sektorze finansowym i odporności cyfrowej, a NIS2 reguluje szersze zarządzanie cyberbezpieczeństwem w podmiotach kluczowych i ważnych. Dla podmiotów finansowych objętych DORA trzeba jednak uwzględnić zasadę lex specialis z art. 4 NIS2: gdy sektorowy akt UE ustanawia równoważne wymogi zarządzania ryzykiem ICT i zgłaszania incydentów, odpowiadające im przepisy NIS2 nie mają zastosowania. Zakres zawsze wymaga oceny konkretnego podmiotu i obowiązków; same dokumenty nie zastępują działających kontroli i dowodów.

Co powinno zostać jako pakiet dowodów

Aktualizuj dokumenty, raporty, wyniki testów i decyzje na bieżąco. Przy każdym materiale wskaż okres, którego dotyczy, oraz osobę odpowiedzialną. Zaznacz brakujące dokumenty i otwarte zadania, aby zarząd, audytor lub nadzorca mógł ocenić rzeczywisty stan kontroli.

• Rejestr informacji o ustaleniach umownych dotyczących usług ICT, powiązany z usługami, dostawcami, funkcjami i właścicielami; zakres nie ogranicza się do dostawców wspierających funkcje krytyczne.
• Rejestr incydentów z klasyfikacją, decyzjami, komunikacją, czasami reakcji i działaniami korygującymi.
• Wyniki testów backupu, odtwarzania, podatności, ciągłości działania i scenariuszy awaryjnych.
• Przeglądy dostawców, umów, SLA, podwykonawców, planów zakończenia współpracy z dostawcami i ryzyk koncentracji.
• Raporty monitoringu, przeglądy dostępów, akceptacje wyjątków i decyzje właścicieli ryzyk.

Certyfikat ISO 27001 partnera a zgodność z DORA

Własny certyfikat systemu zarządzania bezpieczeństwem informacji (SZBI) Virtline opisuje zakres certyfikowanego systemu zarządzania. Pomaga ocenić sposób pracy partnera, ale nie jest certyfikatem zgodności klienta z DORA. Wyniki przeglądu trzeba oprzeć na rzeczywistych kontrolach i aktualnych dowodach.

Najczęstsze błędy we wdrożeniu DORA

Błędy wynikają zwykle z odłączenia compliance od IT. Organizacja ma politykę, ale nie ma testu odtworzenia. Ma rejestr dostawców, ale nie wie, który system wspiera krytyczną funkcję. Ma procedurę incydentu, ale nie ćwiczy eskalacji.

Ryzyka, które trzeba nazwać wprost

Rzetelna ocena zgodności z DORA nie ukrywa trudnych zależności. Pokazuje, gdzie organizacja ma ryzyko koncentracji, gdzie dostawca jest krytyczny, gdzie backup nie potwierdza odtworzenia usługi i gdzie decyzja wymaga zarządu.

• Jedna usługa finansowa zależy od kilku systemów, ale tylko część z nich ma właściciela technicznego.
• Dostawca ICT obsługuje krytyczny proces, a umowa nie przewiduje scenariusza wyjścia ani raportów odporności.
• Incydenty są zamykane w helpdesku bez klasyfikacji regulacyjnej i bez decyzji o zgłoszeniu.
• Test backupu potwierdza odtworzenie pliku, ale nie potwierdza odtworzenia całej funkcji biznesowej.
• Monitoring generuje alerty, lecz nie ma ścieżki eskalacji, priorytetów ani mierzalnego czasu reakcji.

Jak Virtline wspiera DORA

Łączymy audyt, wdrożenie i bieżące utrzymanie środowiska ICT. Rekomendacji nie pozostawiamy w tabeli — przekładamy je na konfiguracje, procedury, testy, monitoring, dowody i zadania operacyjne.

Co dostaje organizacja po projekcie

Celem jest materiał, który da się utrzymywać po zakończeniu warsztatu. Dlatego wynik prac opisuje konkretne odpowiedzialności, częstotliwość kontroli i dowody, a nie tylko rekomendacje.

• Mapę usług ICT, funkcji krytycznych, dostawców i właścicieli decyzji.
• Rejestr luk z priorytetami, zależnościami, właścicielami oraz terminami.
• Procedury incydentowe, testowe i dostawcze powiązane z realnymi systemami.
• Wzory raportów zarządczych i operacyjnych, które pokazują status ryzyk oraz działań.
• Pakiet dowodów do audytu DORA: rejestry, wyniki testów, przeglądy, decyzje i materiały odbiorowe.

Priorytety DORA na 2026 rok

Warto zebrać wyniki testów, przeglądów i obsługi incydentów, aby pokazać audytorowi, klientowi lub nadzorcy, jak przyjęte zasady działają w praktyce. Same polityki nie wystarczą. Organizacja powinna wskazać, które usługi są krytyczne, jakie systemy ICT je wspierają, kto zatwierdza ryzyko, jak testowano odtworzenie i jak nadzorowani są dostawcy.

• Utrzymuj aktualną mapę funkcji krytycznych, systemów ICT, dostawców, właścicieli i zależności technicznych.
• Powiąż rejestr incydentów z klasyfikacją, czasami reakcji, decyzjami eskalacyjnymi i wnioskami po zdarzeniu.
• Testuj odporność operacyjną: backup, odtworzenie, scenariusze awarii, komunikację i działania po stronie dostawców.
• Regularnie oceniaj umowy ICT, SLA, podwykonawców, plan zakończenia współpracy z dostawcą, lokalizację przetwarzania i ryzyko koncentracji.
• Przygotuj krótki raport dla zarządu: status ryzyk, brakujące dowody, budżet, właściciele decyzji i terminy.

Szybki wybór zakresu: audyt, wdrożenie czy utrzymanie

Nie każda organizacja potrzebuje tego samego startu. Firma z gotową dokumentacją może potrzebować przeglądu dokumentacji i testów konfiguracji. Organizacja bez rejestru usług ICT powinna zacząć od mapy zależności. Podmiot po incydencie powinien najpierw uporządkować klasyfikację, komunikację i działania korygujące. DORA warto traktować jako program odporności cyfrowej, który łączy compliance, cyberbezpieczeństwo i utrzymanie IT.

Kontakt

Najlepiej zanim audytor, klient lub nadzorca zapyta o dowody. Krótki warsztat pozwala oddzielić działania krytyczne od prac dokumentacyjnych, wskazać właścicieli decyzji i ustalić realny plan uporządkowania dowodów i odpowiedzialności dla usług, dostawców, testów oraz incydentów.

• Nie ma aktualnej mapy usług ICT, dostawców i procesów krytycznych.
• Backup istnieje, ale nie ma regularnych testów odtworzenia usług.
• Incydenty są obsługiwane ad hoc, bez klasyfikacji i rejestru decyzji.
• Umowy z dostawcami ICT nie odzwierciedlają krytyczności usług.
• Zarząd potrzebuje krótkiej informacji o ryzyku, budżecie i priorytetach.

Źródła do opisanych wymagań i terminów