Ryzyko ICT to możliwość wystąpienia zdarzenia związanego z technologiami informacyjno-komunikacyjnymi, które może naruszyć poufność, integralność lub dostępność danych i systemów. W sektorze finansowym zasady zarządzania nim określa rozporządzenie (UE) 2022/2554 (DORA), stosowane od 17 stycznia 2025 r. (art. 64). Podmiot finansowy prowadzi udokumentowane ramy zarządzania ryzykiem ICT (art. 6 ust. 1), a ostateczną odpowiedzialność za nie ponosi organ zarządzający (art. 5 ust. 2 lit. a).
Według art. 3 pkt 5 DORA ryzyko związane z ICT to każda racjonalnie przewidywalna okoliczność związana z korzystaniem z sieci i systemów informatycznych. Jeśli się zmaterializuje, może naruszyć bezpieczeństwo sieci i systemów, narzędzi lub procesów zależnych od technologii, operacje albo świadczenie usług, wywołując niekorzystne skutki w środowisku cyfrowym lub fizycznym.
Stan prawny na dzień 21 października 2026 r.
Główne źródła i kategorie ryzyka ICT
Źródła ryzyka ICT, zewnętrzne i wewnętrzne, można pogrupować w cztery kategorie.
- Ataki cybernetyczne i złośliwe oprogramowanie: obejmują włamania, ransomware, phishing i wykorzystanie podatności w aplikacjach. Skutkiem bywa wyciek danych, ich zaszyfrowanie lub przerwa w usługach.
- Awarie infrastruktury: dotyczą sprzętu, sieci, zasilania i centrów danych. DORA wymaga na tę okoliczność kopii zapasowych i procedur odtwarzania (art. 12).
- Błędy ludzkie i zagrożenia wewnętrzne: to pomyłki w konfiguracji, nadmierne uprawnienia i nadużycia ze strony pracowników.
- Ryzyko zewnętrznych dostawców usług ICT: zgodnie z art. 28 ust. 1 DORA zarządza się nim jako integralną częścią ryzyka ICT, a podmiot finansowy pozostaje w pełni odpowiedzialny także przy korzystaniu z usług dostawcy. Szerzej o tym w tekście o bezpieczeństwie łańcucha dostaw w ujęciu NIS2.
Regulacje, które wymagają zarządzania ryzykiem ICT
Zarządzanie ryzykiem ICT wymuszają przede wszystkim dwa akty prawa Unii Europejskiej: rozporządzenie DORA i dyrektywa NIS2.
- DORA: rozporządzenie (UE) 2022/2554 poświęca zarządzaniu ryzykiem ICT cały rozdział II (art. 5–16). Narzędzia, metody i polityki doprecyzowuje rozporządzenie delegowane (UE) 2024/1774.
- NIS2 i ustawa o KSC: art. 21 dyrektywy (UE) 2022/2555 nakłada na podmioty kluczowe i ważne obowiązek stosowania odpowiednich i proporcjonalnych środków zarządzania ryzykiem. Obejmują one m.in. analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw i uwierzytelnianie wieloskładnikowe. W Polsce dyrektywę wdraża znowelizowana ustawa o krajowym systemie cyberbezpieczeństwa.
(Uwaga: zgodnie z art. 4 i motywem 28 NIS2 w zakresie zarządzania ryzykiem ICT i zgłaszania incydentów podmioty finansowe stosują DORA zamiast NIS2. Więcej w tekście o różnicach między NIS2 a DORA.)
Podstawowe elementy zarządzania ryzykiem ICT
Wymogi rozdziału II (art. 5–16) oraz art. 24–25 DORA można uporządkować w pięć powiązanych obszarów.
- Identyfikacja i inwentaryzacja: art. 8 ust. 1 wymaga zidentyfikowania, sklasyfikowania i udokumentowania wszystkich funkcji biznesowych wspieranych przez ICT oraz zasobów, które je wspierają. Źródła ryzyka identyfikuje się w sposób ciągły, a scenariusze ryzyka przegląda się co najmniej raz w roku (art. 8 ust. 2).
- Ocena ryzyka: podmioty inne niż mikroprzedsiębiorstwa oceniają ryzyko przy każdej istotnej zmianie infrastruktury sieci i systemów, procesów lub procedur (art. 8 ust. 3). Pomaga w tym spójna metoda szacowania ryzyka.
- Monitorowanie i wykrywanie: art. 10 wymaga mechanizmów wykrywania nieprawidłowych działań i incydentów ICT, a art. 9 uzupełnia je środkami ochrony i zapobiegania.
- Reagowanie i ciągłość działania: art. 11 dotyczy reagowania i przywracania sprawności, a art. 12 kopii zapasowych i procedur odtwarzania. Z reagowaniem wiążą się też terminy zgłaszania poważnych incydentów ICT.
- Testowanie: art. 24 ust. 6 wymaga od podmiotów innych niż mikroprzedsiębiorstwa co najmniej raz w roku testów wszystkich systemów i aplikacji ICT wspierających krytyczne lub istotne funkcje. Katalog z art. 25 ust. 1 obejmuje m.in. oceny i skanowanie podatności, przeglądy kodu źródłowego i testy penetracyjne.
Jak ryzyko ICT wygląda w raporcie z testu penetracyjnego
W raporcie z testu penetracyjnego ryzyko ICT ma postać konkretnych podatności, ocen i rekomendacji, które przenosi się do rejestru ryzyka.
| Element raportu z testu | Co oznacza dla rejestru ryzyka ICT | Odniesienie w DORA |
|---|---|---|
| Lista testowanych systemów i zakres | Weryfikacja kompletności inwentaryzacji zasobów ICT | Art. 8 ust. 1 |
| Podatność i jej ocena w skali CVSS | Dane do oceny skutków i priorytetów (CVSS mierzy dotkliwość podatności, nie prawdopodobieństwo) | Art. 8 ust. 2–3 |
| Rekomendacje naprawcze i retest | Wnioski z testu i potwierdzenie usunięcia podatności zasilają coroczny przegląd ram i doskonalenie | Art. 6 ust. 5, art. 13 |
W projektach, które prowadzimy, najczęściej widać, że rejestr ryzyka ICT obejmuje systemy własne, a pomija interfejsy i konta dostawców usług ICT oraz konta serwisowe. Sama umowa wpisana do rejestru informacji (art. 28 ust. 3) nie pokazuje, do jakich systemów dostawca ma faktycznie dostęp. Interfejsy dostawców i konta serwisowe warto więc ujmować w inwentaryzacji z art. 8 ust. 1 oraz w rejestrze ryzyka jako odrębne pozycje z przypisanym właścicielem.
Jak Pentestica może pomóc
Pentestica wspiera podmioty finansowe w testach wymaganych przez art. 24 i 25 DORA jako niezależna strona zewnętrzna (art. 24 ust. 4) oraz w porządkowaniu ram zarządzania ryzykiem ICT. Szczegóły zawiera opis wsparcia w zgodności z rozporządzeniem DORA, a zakres testu można wstępnie określić w konfiguratorze zakresu testu.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA) – art. 3 pkt 5, art. 5–16, art. 24–25, art. 28, art. 64.
- Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2) – art. 4, art. 21, motyw 28.
- Rozporządzenie delegowane Komisji (UE) 2024/1774 z 13 marca 2024 r. – regulacyjne standardy techniczne dotyczące narzędzi, metod, procesów i polityk zarządzania ryzykiem ICT oraz uproszczonych ram.
- Komisja Nadzoru Finansowego, strona o DORA – wymagania, sprawozdawczość, incydenty, pytania i odpowiedzi.
Redakcja Pentestica to zespół pentesterów i konsultantów bezpieczeństwa, którzy na co dzień wykonują testy penetracyjne, testy TLPT wymagane przez DORA, red teaming i audyty bezpieczeństwa IT, a także prowadzą wdrożenia zgodności z NIS2, DORA i MiCA. Teksty na tym blogu piszemy z tej praktyki, a nie z opracowań. Każde twierdzenie o przepisie, terminie albo karze opieramy na źródle pierwotnym: dzienniku ustaw, tekście dyrektywy, komunikacie organu nadzoru. Jeśli czegoś nie da się potwierdzić, piszemy o tym wprost, zamiast powtarzać liczbę krążącą po branżowych portalach.