Audyt zgodności z DORA sprawdza sześć obszarów: rejestr informacji, ramy zarządzania ryzykiem ICT, warstwę operacyjną tych ram, proces incydentowy, program testowania i umowy z dostawcami. Rozporządzenie nie narzuca kolejności badania. Zaczynamy od rejestru, bo to on wyznacza zakres pięciu pozostałych obszarów. Poniżej opisujemy, czym dowodzi się każdego z nich.
Stan prawny na dzień 10 września 2026 r.
- Zacznij od rejestru informacji — art. 28 ust. 3 DORA i wzory z ITS 2024/2956 pozwalają ustalić zakres całego badania. Kolejność sześciu kroków to nasza metodyka, nie wymóg rozporządzenia.
- Ustal ścieżkę ram — pełne (art. 6) albo uproszczone (art. 16), zgodnie z RTS 2024/1774.
- Dowód to dokument z datą — polityka, protokół, zgłoszenie w systemie KNF, raport z testu.
- Terminy zgłoszeń są sztywne — cztery dokumenty i ich terminy wyznacza art. 5 RTS 2025/301.
- Umowy zostawiamy na koniec — art. 30 DORA, RTS 2024/1773 i RTS 2025/532, w tym testowany plan wyjścia.
Dlaczego audyt DORA zaczyna się od rejestru informacji, a nie od polityk
Mowa o przeglądzie gotowości: badaniu, które podmiot finansowy zamawia albo prowadzi wewnętrznie, zanim dowody zobaczy ktoś z zewnątrz. Zaczynamy od rejestru informacji z art. 28 ust. 3, bo to rejestr pozwala ustalić zakres wszystkiego pozostałego. Z rejestru wynika, które funkcje podmiot uznał za krytyczne lub istotne. To przesądza, które umowy podlegają zaostrzonym wymogom, które usługi trafiają do programu testowania i dla których ustaleń umownych potrzebny jest udokumentowany plan wyjścia.
Jest jeszcze powód praktyczny: część rejestrów organ nadzoru już zna. Rejestry zbierano formularzem SPR-PF-18, a komunikat KNF z 29 kwietnia 2025 r. potwierdził upływ terminu 28 kwietnia 2025 r. i przekazanie plików do Europejskiego Urzędu Nadzoru Bankowego do walidacji. Komunikat z 23 maja 2025 r. uruchomił drugi etap dla podmiotów, które rejestru nie złożyły albo otrzymały odrzucenie. Sama zbiórka była działaniem nadzorczym z 2025 r., nie stałą regułą — obowiązek z art. 28 ust. 3 DORA dotyczy prowadzenia i aktualizowania rejestru. Na 10 września 2026 r. nie potwierdziliśmy komunikatu KNF o kolejnym cyklu, więc termin przekazania w danym roku trzeba sprawdzić w sekcji DORA na stronie nadzoru. Punktem odniesienia w badaniu jest ostatnia wersja rejestru złożona organowi, a przy jej braku ostatnia wersja zatwierdzona wewnętrznie.
Ten wpis nie powtarza kolejności wdrożenia. Jeśli szukasz przeglądu pięciu filarów i sekwencji prac wdrożeniowych, prowadzi przez nie lista kontrolna pięciu filarów DORA. Tutaj opisujemy kolejność dowodzenia zgodności i dowody, które trzeba położyć na stole.
Sześć kroków audytu zgodności z DORA
Sekwencja sześciu kroków to metodyka, którą stosujemy przy porządkowaniu dowodów: wynika z zależności między dokumentami, a nie z numeracji artykułów. Każdy kolejny krok korzysta z ustaleń poprzedniego, dlatego zespoły, które zaczynają od przeglądu polityk, i tak wracają do rejestru, żeby ustalić, czego te polityki dotyczą. Podstawę prawną i dowód dla każdego kroku zbiera tabela niżej.
Mapa wymogów: co, na jakiej podstawie i czym się to dowodzi
Tabela zbiera to, co rozporządzenie rozprasza między poziom pierwszy a akty delegowane. Kolumna „Dowód” opisuje materiał, który trafia do akt badania.
| Krok | Co się sprawdza | Podstawa (DORA) | Akt poziomu 2 | Dowód, który trzeba pokazać |
|---|---|---|---|---|
| 1 | Rejestr informacji i klasyfikacja funkcji krytycznych lub istotnych | art. 28 ust. 3 | ITS 2024/2956 | Plik rejestru zgodny ze wzorem, protokół zatwierdzenia i notatka z metodyki |
| 2 | Wybór i kompletność ram zarządzania ryzykiem ICT, nadzór organu zarządzającego | art. 5 i art. 6 albo art. 16 | RTS 2024/1774, tytuł II albo III | Zatwierdzone ramy, uchwała, protokół posiedzenia, raport dla zarządu |
| 3 | Identyfikacja, ochrona, wykrywanie, reagowanie i odtwarzanie, kopie, komunikacja | art. 8–14 na ścieżce pełnej, art. 16 na uproszczonej | RTS 2024/1774, tytuł II albo III | Inwentarz aktywów ICT, protokół z testu odtworzenia, rejestr wniosków |
| 4 | Klasyfikacja incydentów, progi istotności, zgłoszenia i terminy | art. 17, 18, 19 | RTS 2024/1772, RTS 2025/301, ITS 2025/302 | Zapis klasyfikacji i potwierdzenia zgłoszeń z systemu KNF (SOID) |
| 5 | Program testowania, testy narzędzi i systemów, warunkowo TLPT | art. 24, 25, 26, 27 | RTS 2025/1190 | Plan testowania, raporty z testów, rejestr działań naprawczych |
| 6 | Postanowienia umowne, polityka i plany wyjścia, ocena podwykonawstwa | art. 28, art. 30 | RTS 2024/1773, RTS 2025/532 | Wykaz klauzul, przetestowany plan wyjścia wraz z protokołem przeglądu |
Krok 1: rejestr informacji wyznacza zakres audytu
Pierwsze pytanie dotyczy zgodności rejestru informacji ze wzorami z ITS 2024/2956 oraz tego, czy klasyfikacja funkcji krytycznych lub istotnych ma udokumentowane uzasadnienie. Zestawiamy ostatnią wersję przekazaną do KNF — a jeśli podmiot rejestru nie przekazywał, ostatnią zatwierdzoną wersję wewnętrzną — z aktualnym stanem umów i listą dostawców. Dowodem jest sam plik rejestru, protokół jego zatwierdzenia i notatka z metodyki klasyfikacji funkcji.
W projektach, które prowadzimy, najczęściej widzimy rozbieżność między rejestrem przekazanym do nadzoru a faktycznym stanem umów. Zwykle chodzi o podwykonawców, których dostawca dopisał po podpisaniu umowy i których nie ujawniono w rejestrze. Ten jeden brak przenosi się później na krok szósty. To obserwacja zanonimizowana, nie statystyka.
Krok 2: ramy zarządzania ryzykiem ICT i odpowiedzialność zarządu
Drugi krok rozstrzyga, czy podmiot działa na pełnych ramach z art. 6 DORA, czy na uproszczonych z art. 16. To rozstrzygnięcie zmienia listę dowodów, a nie tylko ich objętość. Art. 16 ust. 1 DORA wyłącza stosowanie art. 5–15 wobec:
- małych i niepowiązanych wzajemnie firm inwestycyjnych,
- instytucji płatniczych wyłączonych na podstawie dyrektywy (UE) 2015/2366,
- instytucji wyłączonych na podstawie dyrektywy 2013/36/UE, wobec których państwo członkowskie nie skorzystało z opcji z art. 2 ust. 4 DORA,
- instytucji pieniądza elektronicznego wyłączonych na podstawie dyrektywy 2009/110/WE,
- małych instytucji pracowniczych programów emerytalnych.
Dla tych podmiotów odpowiednikiem warstwy operacyjnej jest tytuł III rozporządzenia 2024/1774, a nie tytuł II.
Na ścieżce pełnej sprawdzamy dodatkowo art. 5, czyli udokumentowaną odpowiedzialność organu zarządzającego: zatwierdzenie strategii, przydział budżetu, okresowe raportowanie i szkolenia członków zarządu.
Dowodem nie jest sama polityka, tylko ślad decyzyjny. Uchwała z datą, protokół posiedzenia z omówieniem ryzyka ICT, raport przedłożony organowi zarządzającemu i potwierdzenie odbycia szkoleń znaczą więcej niż stustronicowy dokument bez historii zatwierdzeń.
Krok 3: warstwa operacyjna ram, od identyfikacji po komunikację
Tu kończą się polityki, a zaczynają logi i protokoły. Na ścieżce pełnej art. 8–14 DORA obejmują identyfikację zasobów i zależności, środki ochrony, mechanizmy wykrywania, procedury reagowania i odtwarzania, politykę kopii zapasowych, proces uczenia się po zdarzeniach oraz plany komunikacji. Do każdego z tych obszarów przypisujemy odrębny dowód: inwentarz aktywów ICT, wyniki testów odtworzeniowych, rejestr wniosków po incydentach, zatwierdzony plan komunikacji kryzysowej. Na ścieżce uproszczonej te same pytania zadajemy w zakresie wynikającym z tytułu III rozporządzenia 2024/1774.
Najsłabszym ogniwem bywa odtwarzanie. Polityka kopii zapasowych istnieje, ale brakuje protokołu z odtworzenia systemu wspierającego funkcję krytyczną, z datą, czasem i wynikiem. Bez takiego protokołu obszar zostaje w badaniu jako deklaracja.
Krok 4: klasyfikacja incydentów, terminy i kanał zgłoszeń do KNF
Czwarty krok weryfikuje, czy proces z art. 17 DORA rozpoznaje incydent, poprawnie go klasyfikuje według art. 18 i progów istotności z RTS 2024/1772, a następnie kończy się zgłoszeniem w terminie. Art. 5 RTS 2025/301 wyznacza cztery dokumenty — opracowania rynkowe zwykle wymieniają trzy, pomijając aktualizację sprawozdania śródokresowego:
- Zgłoszenie wstępne — tak szybko, jak to możliwe, w każdym razie w ciągu 4 godzin od sklasyfikowania incydentu jako poważnego i nie później niż 24 godziny od momentu, w którym podmiot dowiedział się o incydencie.
- Sprawozdanie śródokresowe — najpóźniej 72 godziny od przedłożenia zgłoszenia wstępnego, także wtedy, gdy status incydentu się nie zmienił.
- Zaktualizowane sprawozdanie śródokresowe — po odzyskaniu sprawności w zakresie regularnej działalności. Ten dokument najczęściej wypada z procedur, a od niego liczy się termin sprawozdania końcowego.
- Sprawozdanie końcowe — nie później niż miesiąc po sprawozdaniu śródokresowym lub po jego ostatniej aktualizacji.
Formularze reguluje ITS 2025/302. Kanałem technicznym jest System do Obsługi Incydentów DORA (SOID) pod adresem csirt.knf.gov.pl, z awaryjnym kanałem mailowym. Pozostałe sprawozdania idą osobnym torem, przez System Sprawozdawczości DORA (SSD) w Podsystemie Komunikacji CRP pod adresem crp.knf.gov.pl. Pytamy więc o konta, role i przetestowanie kanału, bo sama procedura nie dowodzi, że zgłoszenie wyjdzie na czas. Szerzej opisuje to tekst o raportowaniu incydentów według DORA i terminach zgłoszeń.
Krok 5: program testowania odporności cyfrowej i kiedy dochodzi TLPT
Piąty krok ocenia program testowania z art. 24 DORA oraz zakres testów narzędzi i systemów ICT z art. 25. Sprawdzamy trzy rzeczy: czy program jest oparty na ryzyku, czy obejmuje systemy wspierające funkcje krytyczne lub istotne wskazane w kroku pierwszym i czy jego harmonogram wynika z tej klasyfikacji. Dowodem są plan testów, raporty z testów i rejestr działań naprawczych z terminami zamknięcia.
Podmioty objęte obowiązkiem zaawansowanego testowania dokładają TLPT z art. 26 i 27, doprecyzowane w RTS 2025/1190. Eurosystem zaktualizował ramy TIBER-EU pod DORA komunikatem z 11 lutego 2025 r., wskazując purple teaming jako obowiązkowy i zmieniając terminologię zespołów. Zakres i przebieg takiego ćwiczenia opisuje strona testów TLPT. Powtarzalnym brakiem jest tu niespójność między klasyfikacją funkcji w rejestrze a zakresem programu testowania.
Krok 6: umowy, plany wyjścia i podwykonawstwo
Szósty krok wraca do rejestru z kroku pierwszego. Sprawdzamy, czy umowy dotyczące funkcji krytycznych lub istotnych zawierają postanowienia z art. 30 DORA, czy polityka wobec dostawców odpowiada RTS 2024/1773, a ocena podwykonawstwa — RTS 2025/532. Osobno weryfikujemy wyjście z umowy. Art. 10 RTS 2024/1773 wymaga udokumentowanego planu wyjścia dla każdego ustalenia umownego objętego tą polityką, czyli dotyczącego usług ICT wspierających funkcje krytyczne lub istotne, wraz z okresowym przeglądem, testowaniem i harmonogramem zgodnym z warunkami wypowiedzenia.
Wraca tu ten sam wzorzec co przy rejestrze: plany wyjścia istnieją na papierze, ale nie były testowane. Brakuje protokołu z przeglądu, dat, właściciela procesu i wniosków. Taki plan traktujemy jako nieudowodniony, bo nie ma śladu, że da się go wykonać w oknie wypowiedzenia.
Od czego zależy koszt audytu zgodności z DORA
Konkretnych liczb w tym wpisie nie podajemy, bo koszt zależy wprost od zakresu, a zakres ustala się dopiero po kroku pierwszym. Na wycenę składają się: ścieżka ram (pełna albo uproszczona), liczba ustaleń umownych w rejestrze informacji, liczba dostawców wspierających funkcje krytyczne lub istotne, obecność TLPT w zakresie oraz stan dokumentacji.
Najsilniej przesuwają zakres dwie rzeczy: liczba spółek objętych badaniem oraz to, czy zgłoszenia incydentów były już realnie wykonywane, czy istnieją tylko na poziomie procedury. Orientacyjne przedziały i zasady ich ustalania podaje sekcja o kosztach wdrożenia DORA na stronie usługowej, a wstępny zakres badania ustala konfigurator zakresu DORA.
Najczęstsze pytania o audyt zgodności z DORA
Od czego zacząć przygotowanie do audytu zgodności z DORA?
Od zestawienia ostatniej wersji rejestru informacji z aktualnym wykazem umów ICT. Pokazuje, czy klasyfikacja funkcji krytycznych lub istotnych jest nadal aktualna i czy w łańcuchu dostaw pojawili się nowi podwykonawcy. Dopiero po niej ma sens przegląd polityk.
Jakie dokumenty są dowodem zgodności z DORA w audycie?
Dowodem są dokumenty z datą i właścicielem, nie same polityki. Do akt badania trafiają: plik rejestru informacji, uchwały i protokoły organu zarządzającego, inwentarz aktywów ICT, protokoły z testów odtworzeniowych, zapisy klasyfikacji incydentów, potwierdzenia zgłoszeń w systemie KNF, raporty z testów oraz przetestowane plany wyjścia.
W jakich terminach trzeba zgłosić poważny incydent ICT?
Art. 5 rozporządzenia delegowanego (UE) 2025/301 wyznacza cztery dokumenty: zgłoszenie wstępne, sprawozdanie śródokresowe, jego aktualizację po odzyskaniu sprawności w zakresie regularnej działalności oraz sprawozdanie końcowe. Zegar zgłoszenia wstępnego rusza od sklasyfikowania incydentu jako poważnego, nie od jego zamknięcia, a termin sprawozdania końcowego liczy się od ostatniej aktualizacji sprawozdania śródokresowego.
Czy każdy podmiot finansowy musi przeprowadzić TLPT?
Nie. Zaawansowane testowanie w oparciu o TLPT z art. 26 i 27 DORA obejmuje wskazane podmioty, a kryteria ich identyfikacji, wymogi wobec testerów i metodykę doprecyzowuje RTS 2025/1190. Pozostałe podmioty prowadzą program testowania z art. 24 DORA i testują narzędzia oraz systemy ICT zgodnie z art. 25. W badaniu dowodem jest plan testów powiązany z klasyfikacją funkcji z rejestru informacji.
Gdzie składa się sprawozdania i zgłoszenia wymagane przez DORA?
W dwóch różnych systemach KNF: incydenty w SOID, pozostała sprawozdawczość w SSD. W badaniu nie wystarczy wskazać właściwy system. Pytamy, kto ma w nim konto, w jakiej roli, kto przejmuje zgłoszenie poza godzinami pracy i kiedy ostatnio przetestowano wysyłkę — zegar czterech godzin nie czeka na nadanie uprawnień.
Jak Pentestica może pomóc
Wspieramy podmioty finansowe w przygotowaniu do badania zgodności: porządkujemy rejestr informacji, weryfikujemy ramy zarządzania ryzykiem ICT i kompletujemy dowody z sześciu kroków. Prowadzimy też testy penetracyjne, red teaming i TLPT oraz wsparcie w formule vCISO. Mamy ponad 10 lat doświadczenia i setki zrealizowanych projektów. Zakres prac opisuje strona usługi wdrożenia i zgodności z DORA.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 (DORA) — tekst rozporządzenia z 14 grudnia 2022 r., stosowanego od 17 stycznia 2025 r.
- Rozporządzenie delegowane Komisji (UE) 2024/1774 z 13 marca 2024 r. — RTS dotyczące narzędzi, metod, procesów i polityk zarządzania ryzykiem ICT oraz ram uproszczonych.
- Rozporządzenie delegowane Komisji (UE) 2024/1772 z 13 marca 2024 r. — RTS dotyczące kryteriów klasyfikacji incydentów ICT i progów istotności.
- Rozporządzenie delegowane Komisji (UE) 2025/301 z 23 października 2024 r. — RTS dotyczące treści i terminów zgłoszenia wstępnego oraz sprawozdań śródokresowego i końcowego.
- Rozporządzenie wykonawcze Komisji (UE) 2025/302 z 23 października 2024 r. — ITS ze standardowymi formularzami i procedurami zgłaszania poważnych incydentów ICT.
- Rozporządzenie wykonawcze Komisji (UE) 2024/2956 z 29 listopada 2024 r. — ITS ze standardowymi wzorami rejestru informacji.
- Rozporządzenie delegowane Komisji (UE) 2024/1773 z 13 marca 2024 r. — RTS dotyczące polityki wobec dostawców ICT, w tym art. 10 o planach wyjścia.
- Rozporządzenie delegowane Komisji (UE) 2025/532 z 24 marca 2025 r. — RTS dotyczące elementów ocenianych przy zlecaniu podwykonawstwa usług ICT.
- Rozporządzenie delegowane Komisji (UE) 2025/1190 z 13 lutego 2025 r. — RTS dotyczące TLPT: kryteria identyfikacji podmiotów, wymogi wobec testerów, metodyka.
- Sekcja DORA na stronie Komisji Nadzoru Finansowego — akty wykonawcze, wytyczne nadzorcze, materiały informacyjne oraz pytania i odpowiedzi.
- Systemy DORA w KNF — opis Systemu Sprawozdawczości DORA (SSD) i Systemu do Obsługi Incydentów DORA (SOID).
- Komunikat KNF z 29 kwietnia 2025 r. o przekazaniu rejestrów informacji — formularz SPR-PF-18, termin 28 kwietnia 2025 r. i przekazanie plików do EUNB.
- Komunikat Eurosystemu o aktualizacji ram TIBER-EU (11 lutego 2025 r.) — dostosowanie ram testów pod kątem zagrożeń do wymogów DORA.
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.