Secureside Blog Bez kategorii DORA oczami nadzoru. Czego UKNF szuka podczas kontroli — i dlaczego warto być na CEDUR 7 września

DORA oczami nadzoru. Czego UKNF szuka podczas kontroli — i dlaczego warto być na CEDUR 7 września

7 września 2026 r. Urząd Komisji Nadzoru Finansowego przeprowadzi trzeci termin webinarium CEDUR „Wybrane aspekty stosowania rozporządzenia DORA z perspektywy organu nadzoru”. Byliśmy na pierwszym terminie. Poniżej podsumowanie tego, co zostało na nim powiedziane, oraz kilka powodów, dla których naszym zdaniem warto zarezerwować ten dzień w kalendarzu.

Rynek finansowy ma za sobą ponad rok stosowania rozporządzenia DORA i kolejne edycje sprawozdania SPR-PF-18. Zmieniło się jednak coś, co dla praktyków ma znaczenie większe niż upływ czasu. Departament Cyberbezpieczeństwa UKNF przeprowadził pierwszą serię czynności kontrolnych i zaczął otwarcie mówić o tym, co w ich trakcie zobaczył. To zupełnie inna kategoria wiedzy niż kolejne omówienie treści przepisów.

CEDUR poprowadzili główni specjaliści Departamentu Cyberbezpieczeństwa UKNF — w trzech blokach tematycznych zakończonych sesją pytań i odpowiedzi. Poniżej to, co uznaliśmy za najważniejsze.

Bezpieczeństwo przestało być funkcją techniczną

Pierwszy blok dotyczył odpowiedzialności organu zarządzającego. Teza była prosta, DORA przenosi bezpieczeństwo z poziomu funkcji technicznej na poziom odpowiedzialności zarządczej, a odpowiedzialność ta ma charakter pełny i ostateczny. Organ zarządzający ma określić strategię i apetyt na ryzyko, zatwierdzać polityki, otrzymywać regularne raporty, rozumieć ryzyko i podejmować na tej podstawie decyzje. Samo zatwierdzanie dokumentów nie wystarcza — za zatwierdzeniem muszą iść dane, mierniki i wskaźniki potwierdzające, że decyzja była świadoma.

Wyraźnie wybrzmiała też zasada, o której łatwo zapomnieć przy budowaniu rejestru umów mianowicie outsourcing usługi nie jest outsourcingiem ryzyka. Awaria u dostawcy pozostaje problemem podmiotu finansowego — to on ponosi skutki finansowe i reputacyjne.

Sporo miejsca poświęcono strategii operacyjnej odporności cyfrowej. Nadzór traktuje ją jako dokument nadrzędny wobec polityk i procedur, a nie ich zbiór ani spis treści z odesłaniami. Elementy wymagane przez art. 6 ust. 8 DORA mają się w niej znaleźć bezpośrednio lub w załącznikach — nie mogą być rozproszone po dokumentach operacyjnych. Obowiązuje konkretna i zdefiniowana hierarchia. Strategia wyznacza kierunek, polityki przekładają ją na zasady, procedury opisują konkretne działania. Polityki muszą wynikać ze strategii, nie odwrotnie. Strategia podlega przeglądowi co najmniej raz w roku, a każdy przegląd powinien być zatwierdzony przez organ zarządzający.

Przypomniano również, na czym stoi krajowa część układanki. Ustawa z 25 czerwca 2025 r. (Dz.U. poz. 1069), obowiązująca od 7 sierpnia 2025 r., zmieniła osiem ustaw sektorowych i wyposażyła KNF w uprawnienia kontrolne oraz sankcyjne. Katalog sankcji obejmuje kary dla podmiotu sięgające ponad 20 mln zł albo 10% całkowitego rocznego przychodu, kary nakładane bezpośrednio na członków organu zarządzającego w wysokości ponad 3 mln zł, kary dla pracowników i wykonawców liczone jako sześciokrotność wynagrodzenia z ostatnich dwunastu miesięcy, a także nakaz zaprzestania naruszeń i zakaz pełnienia funkcji kierowniczych.

Operacyjnie dobrze, dowodowo słabo

Drugi blok był naszym zdaniem najcenniejszy, bo w całości opierał się na wnioskach ze zrealizowanych czynności kontrolnych. Uczestnicy zapytani na czacie, które artykuły rozdziału II DORA sprawiły im najwięcej trudności, najczęściej wskazywali art. 5 i 6 — dokładnie te, przy których nadzór stwierdzał najwięcej luk.

Przy organizacji systemu zarządzania ryzykiem powtarzały się dwa scenariusze. Tam, gdzie nowe zadania przypisano istniejącym komórkom, brakowało ich formalnego zapisania w regulaminach organizacyjnych i stanowiskowych — czynności były realizowane, ale nie sposób było potwierdzić, że funkcja została komukolwiek wyznaczona. Tam, gdzie tworzono nową komórkę, bywała ona osadzona tak głęboko w strukturze, że traciła niezależność, a jednocześnie łączyła zarządzanie ryzykiem ICT z kontrolą tego zarządzania.

Osobno wybrzmiał wątek kanału zgłoszeń na szczeblu przedsiębiorstwa, wymaganego przez art. 5 ust. 2 lit. i) DORA. W praktyce najczęściej powstawał oddolnie, jako alias mailowy założony przez pracownika dla wygody projektowej, bez zaangażowania organu zarządzającego i bez komunikacji do pracowników. Cel przewidziany w rozporządzeniu jest zupełnie inny.

Podobnie ze szkoleniami. Programy najczęściej obejmowały tematy ogólne — bezpieczne hasła, praca zdalna, kopie zapasowe. Tymczasem szkolenia dla członków organu zarządzającego mają umożliwiać zrozumienie i ocenę ryzyka ICT tego konkretnego podmiotu, którym zarządzają. Brakowało też regularności i potwierdzeń uczestnictwa.

Największa luka dotyczyła jednak samych ram zarządzania ryzykiem związanym z ICT. Art. 6 ust. 1 DORA wymaga, by były solidne, kompleksowe i dobrze udokumentowane. W praktyce najczęściej nigdzie nie opisano, co właściwie w skład tych ram wchodzi — a jeśli już, to poprzez sam wykaz regulacji, z pominięciem narzędzi ICT. Konsekwencje układają się w łańcuch: bez określonych ram trudno wykazać, że wspierają one strategię biznesową, trudno mówić o kompleksowym przeglądzie, trudno uwiarygodnić wnioski audytowe. Do tego dochodziły wąskie rejestry źródeł ryzyka, braki w wykazach z art. 8, ocena ekspercka specjalisty IT stosowana zamiast analizy ryzyka oraz audyt wewnętrzny bez kompetencji w obszarze ryzyka ICT — świetnie przygotowany do ryzyka operacyjnego, ale nie do tego.

Padło przy tym zdanie, które warto zapamiętać: bez rzetelnych przeglądów i audytów pierwszymi, którzy wykryją słabości organizacji, będą cyberprzestępcy.

Incydenty – liczy się nie tylko obsługa, ale i ślad

Trzeci blok dotyczył zarządzania incydentami i ich klasyfikacji. Przypomniano terminy: powiadomienie wstępne w ciągu czterech godzin od sklasyfikowania incydentu jako poważny i nie później niż 24 godziny od powzięcia wiedzy o incydencie, sprawozdanie śródokresowe w ciągu 72 godzin, końcowe najpóźniej miesiąc później. Kluczowa uwaga praktyczna: zegar czterech godzin biegnie od momentu klasyfikacji, a w rejestrach często brakuje śladu po tym procesie — nie ma udokumentowanej godziny, w której incydent uznano za poważny, ani danych, na podstawie których to zrobiono.

Nadzór oczekuje śladu dowodowego również dla incydentów, których poważnymi nie uznano. Podejście polegające na dokumentowaniu kryteriów i progów wyłącznie przy incydentach poważnych zostało wprost określone jako nieakceptowalne, ponieważ podmiot nie jest wówczas w stanie wykazać, że klasyfikacja w ogóle została przeprowadzona.

Wybrzmiało też jednoznaczne oczekiwanie dotyczące ataków: skuteczny, złośliwy i nieuprawniony dostęp do sieci i systemów informatycznych wspierających usługi krytyczne ma być traktowany jako osiągnięcie progu istotności w kryterium utraty danych, a więc bezwzględnie jako incydent poważny.

Sporo uwagi poświęcono incydentom powtarzającym się. Zgodnie z art. 8 ust. 2 RTS 2024/1772 incydenty, które pojedynczo nie były poważne, uznaje się łącznie za jeden poważny, jeżeli wystąpiły co najmniej dwa razy w ciągu sześciu miesięcy, mają tę samą widoczną przyczynę źródłową i łącznie spełniają kryteria. Ocena może być prowadzona cyklicznie, w ujęciu miesięcznym — pod warunkiem że jest udokumentowana czymś więcej niż krótkim mailem. Prelegent zwrócił przy tym uwagę na wadę redakcyjną odesłania w tym przepisie i wskazał, że klasyfikację przyczyn źródłowych należy czytać przez pola 4.2 i 4.3 formularza z ITS 2025/302. Praktyczna rekomendacja: katalog przyczyn źródłowych w organizacji powinien być ustandaryzowany i skatalogowany, a nie opisowy — inaczej grupowanie incydentów o wspólnej przyczynie jest w praktyce niewykonalne.

Na koniec dwa obowiązki, o których podmioty zapominają najczęściej. Po każdym poważnym incydencie należy przeprowadzić przegląd ram zarządzania ryzykiem ICT (art. 6 ust. 5 DORA), a sprawozdanie z tego przeglądu sporządzić zgodnie z art. 27 RTS 2024/1774 i przedłożyć organowi zarządzającemu do zatwierdzenia. Odrębnie funkcjonuje przegląd poincydentalny z art. 13 ust. 2 DORA, który musi obejmować ocenę przestrzegania ustalonych procedur i skuteczności podjętych działań — i którego nie może wykonać ta sama osoba, która incydent obsługiwała. To zadanie dla drugiej linii obrony. Nadzór zachęca wprost do przygotowania szablonu takiego przeglądu jako załącznika do regulacji wewnętrznej.

Jedno zdanie, które streszcza całe webinarium

Nadzór nie ocenia intencji ani jakości pracy zespołów technicznych. Ocenia dowody. Prelegenci wielokrotnie podkreślali, że poziom operacyjny w kontrolowanych podmiotach bywa wysoki, a mimo to kontrola kończy się stwierdzeniem nieprawidłowości — bo nie da się wykazać, że proces przebiegł tak, jak opisuje go procedura. Dla wielu organizacji to najistotniejsza korekta w rozumieniu zgodności z DORA. Kompetentny zespół i sprawna reakcja na incydent nie zastąpią udokumentowanej ścieżki decyzyjnej.

Dlaczego warto zapisać się na 7 września

Po pierwsze, formuła tego webinaru jest nietypowa. UKNF nie omawia treści rozporządzenia — mówi, czego szuka w trakcie kontroli, jakich dowodów oczekuje i jakie luki stwierdza najczęściej. Trudno o bardziej konkretną listę oczekiwań nadzorczych, a jest ona dostępna bezpłatnie.

Po drugie, między pierwszym a trzecim terminem minęło kilka miesięcy kolejnych czynności kontrolnych. Można zasadnie oczekiwać, że część obserwacji zostanie zaktualizowana, a przykłady uzupełnione.

Po trzecie, to nie jest webinar wyłącznie dla CISO i zespołów IT. Znaczna część treści dotyczy roli organu zarządzającego, rady nadzorczej, audytu wewnętrznego, compliance i ryzyka operacyjnego. Jeżeli w Państwa organizacji za DORA odpowiada wyłącznie IT, to samo w sobie jest już obserwacją wartą uwagi.

Rejestracja odbywa się przez formularz zgłoszeniowy UKNF:

Formularz zgłoszeniowy CEDUR — III termin, 7 września 2026 r.

Udział jest bezpłatny, prezentacja jest wysyłana uczestnikom po spotkaniu, a UKNF zwykle umożliwia wcześniejsze przesłanie anonimowych pytań — warto sprawdzić szczegóły w programie wydarzenia.

Jak możemy Państwa wesprzeć

Śledzimy komunikację nadzorczą na bieżąco, bo z niej wynika, jak wymagania DORA są w praktyce egzekwowane. Chętnie dzielimy się tą wiedzą — i równie chętnie pomagamy przełożyć ją na dokumenty i procesy, które obronią się w trakcie kontroli.

W praktyce najczęściej zaczynamy od jednej z trzech rzeczy. Od uporządkowania ram zarządzania ryzykiem ICT i strategii operacyjnej odporności cyfrowej tak, by tworzyły spójną hierarchię, a nie zbiór odesłań. Od przeglądu procesu klasyfikacji incydentów wraz z rejestrem, kryteriami, progami istotności i śladem dowodowym, uzupełnionego o szablony przeglądów poincydentalnych i ocenę w drugiej linii obrony. Albo od szkoleń dla organu zarządzającego dopasowanych do profilu ryzyka konkretnego podmiotu — takich, jakich oczekuje nadzór, a nie ogólnych kursów świadomościowych.

Pracujemy w modelu DORA as a Service, jako vCISO oraz w formule audytów zgodności z DORA, NIS2, ISO 27001 i ISO 22301. Niezależnie od zakresu przyjmujemy tę samą zasadę:

  • jasne priorytety
  • minimalne zaangażowanie Państwa zespołu
  • dedykowana osoba kontaktowa, żeby mogli się Państwo skupić na biznesie.

Jeżeli po webinarium pojawią się pytania o to, jak przełożyć oczekiwania nadzoru na Państwa organizację — zapraszamy do kontaktu.

Grzegorz Bielecki

Udostępnij ten wpis:

Zawartość

Kategorie

Dokumenty 0
Porady 0

Najnowsze wpisy

Software house pod DORA i KSC.
DORA oczami nadzoru. Czego UKNF szuka podczas kontroli — i dlaczego warto być na CEDUR 7 września
Wykaz KSC do 3 października. O czym się nie mówi.

Tagi

ISO 27001
DORA
KNF
NIS2
ISO 22301
Kontakt z nami