Rekomendacja D KNF, Rekomendacja D-SKOK, komunikat chmurowy oraz wytyczne dla ubezpieczycieli i TFI zostały uchylone (m.in. 17 stycznia 2025 r.). Krajowe soft law zastąpiło twarde prawo unijne – rozporządzenie DORA, stanowiące odtąd główny punkt odniesienia dla banków i instytucji finansowych.
Poniżej omawiamy kluczowe zmiany operacyjne oraz sposoby na godzenie nowych wymogów z długiem technologicznym.
Co się stało - uchylenie Rekomendacji D
Uchwałą nr 6/2025 KNF uchyliła Rekomendację D (wydaną uchwałą nr 7/2013) z dniem 17 stycznia 2025 r., czyli w dniu rozpoczęcia stosowania DORA. Tego samego dnia wycofano także pokrewne wytyczne dla innych typów podmiotów oraz komunikat dotyczący przetwarzania w chmurze obliczeniowej. Powód jest jasny: DORA to prawo powszechnie obowiązujące, a była aktem ona tzw. soft law. Utrzymywanie obu jednocześnie tworzyłoby wątpliwości interpretacyjne i podwójne obciążenie regulacyjne. Warto dodać, że Polska przyjęła też krajową ustawę wdrażającą DORA, podpisaną przez Prezydenta 31 lipca 2025 r.
Czy to znaczy, że wymogi zniknęły? Wręcz przeciwnie
To najczęstsze nieporozumienie. Substancja Rekomendacji D – ład w obszarze IT, bezpieczeństwo środowiska teleinformatycznego, zarządzanie ryzykiem, kontrola nad oprogramowaniem użytkownika końcowego (typu arkusze i bazy budowane przez nieprogramistów) – nie zniknęła. Została wchłonięta i rozszerzona przez ramy zarządzania ryzykiem ICT w DORA. Zmienił się charakter wymogów, nie ich kierunek. A charakter zmienił się w stronę bardziej wymagającą.
Co realnie zmienia DORA względem Rekomendacji D
Różnice te sprowadzają się w praktyce do trzech kwestii. Przede wszystkim chodzi o samą rangę przepisów. W efekcie wytyczne soft law stają się twardym obowiązkiem prawnym. Ponadto za brak zgodności grożą kary do 2% rocznego obrotu.
Kolejna kwestia to znacznie szerszy zakres wymagań. DORA wprowadza bowiem obowiązkowe testy odporności cyfrowej, w tym TLPT. Co więcej, nakłada obowiązek prowadzenia rejestru dostawców ICT i ustrukturyzowane raportowanie.
Ostatnią różnicą jest z kolei pełna jednolitość prawa. DORA obowiązuje bowiem bezpośrednio w całej Unii Europejskiej. Dlatego ujednolica ona zasady ponad dotychczasowymi przepisami krajowymi.
Gdzie stary stack staje się problemem
Konsekwencja jest ta sama, co w całej DORA. Nieudokumentowany system w Delphi, VB6 czy starej Javie EE utrudnia wykazanie zarządzania ryzykiem, przeprowadzenie testów i przedstawienie dokumentacji, których nadzór teraz twardo oczekuje. Rekomendacja D również wymagała dokumentacji i kontroli nad środowiskiem, ale jako soft law była egzekwowana łagodniej. DORA nie zostawia tu miejsca na „system działa, więc jest dobrze”: trzeba udowodnić, że jest zarządzany i odporny.
Jak się przygotować
Dobra wiadomość jest taka, że nie zaczynacie od zera. Duża część prac wykonanych pod Rekomendację D – polityki, dokumentacja, zarządzanie ryzykiem – jest nadal wartościowa i wymaga głównie zmapowania na wymogi DORA. Rozsądna ścieżka to audyt luk między dotychczasową zgodnością a DORA, uzupełnienie brakujących elementów oraz odzyskanie widoczności tam, gdzie jej brakuje. Pomagamy w tym w ramach doradztwa IT i audytu architektury IT, a odtworzenie dokumentacji starych systemów opieramy o S*.doc – tak, by zgodność z DORA dało się realnie wykazać, także dla stacku legacy.
