Mała instytucja płatnicza (MIP) podlega rozporządzeniu DORA, ale stosuje uproszczone ramy zarządzania ryzykiem ICT. Nie musi automatycznie wdrażać wszystkich procedur przewidzianych dla banków czy krajowych instytucji płatniczych. Nadal jednak jest zobowiązana do odpowiedniego zabezpieczenia systemów, zarządzania ryzykiem, zgłaszania poważnych incydentów, prowadzenia rejestru informacji o umowach ICT i zapewnienia ciągłości działania.
To ważne rozróżnienie dla przedsiębiorców prowadzących działalność płatniczą.
W praktyce spotykamy się z dwoma skrajnymi podejściami. Pierwsze polega na uznaniu, że skoro MIP jest niewielkim podmiotem, DORA w ogóle jej nie dotyczy. Drugie zakłada, że każda instytucja płatnicza musi przygotować identyczny, rozbudowany zestaw polityk, procedur i dokumentów, niezależnie od skali działalności.
Oba założenia są nieprawidłowe.
Rozporządzenie DORA przewiduje zasadę proporcjonalności oraz szczególny, uproszczony model zarządzania ryzykiem ICT. Nie oznacza to jednak dowolności w wyborze obowiązków.
W skrócie – co MIP musi wiedzieć o DORA w 2026 r.?
- DORA obowiązuje od 17 stycznia 2025 r. Nie jest regulacją, której wdrożenie można automatycznie odłożyć do 2027 r.
- MIP stosuje art. 16 DORA, a szczegółowe wymagania uproszczonych ram określają art. 28–41 rozporządzenia delegowanego (UE) 2024/1774.
- Nie ma jednej ustawowej listy 20 czy 30 odrębnych polityk. Prawo wymaga określonych dokumentów, procedur, planów i dowodów działania systemu, ale nie zawsze nakazuje przygotowanie osobnego pliku dla każdego obszaru.
- MIP nadal musi zarządzać incydentami, dostawcami ICT i ciągłością działania. Uproszczony model nie zwalnia z tych obowiązków.
- Za zgodność odpowiada organizacja i jej kierownictwo, nawet jeżeli cała infrastruktura płatnicza została powierzona zewnętrznemu operatorowi.
W niniejszym artykule przedstawiamy konkretną listę dokumentów i procedur DORA dla MIP, ich podstawy prawne, wymagania KNF oraz przykładowy sposób wdrożenia w niewielkiej instytucji płatniczej.
Stan prawny: 12 października 2026 r.
1. Czy MIP musi wdrożyć DORA? Uproszczone ramy a obowiązki pełnych instytucji płatniczych
DORA, czyli rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego, ustanawia wspólne wymagania dotyczące zarządzania ryzykiem technologicznym w instytucjach finansowych.
Celem regulacji jest zapewnienie, aby podmiot finansowy potrafił nie tylko zapobiegać incydentom ICT, ale również odpowiednio je wykrywać, obsługiwać, ograniczać ich skutki oraz przywracać działalność po awarii.
Dla instytucji płatniczych ma to szczególne znaczenie.
Awaria systemu płatności może bowiem oznaczać nie tylko czasową niedostępność aplikacji. Może również prowadzić do błędnych rozliczeń, opóźnienia transferu środków, utraty dostępu do danych transakcyjnych czy przerwania świadczenia usług klientom.
Dlaczego MIP jest objęta DORA?
Art. 2 ust. 1 lit. b DORA obejmuje instytucje płatnicze, w tym instytucje korzystające ze zwolnień przewidzianych w dyrektywie PSD2.
Polska mała instytucja płatnicza należy właśnie do tej kategorii.
Potwierdziła to Komisja Nadzoru Finansowego w opracowaniu „Wymagania rozporządzenia DORA dla podmiotów stosujących uproszczone ramy zarządzania ryzykiem związanym z ICT”, zaktualizowanym 13 sierpnia 2026 r.
KNF wskazuje wprost, że uproszczone ramy znajdują zastosowanie do polskich MIP oraz biur usług płatniczych (BUP).
Nie oznacza to jednak, że każda MIP jest mikroprzedsiębiorstwem w rozumieniu DORA.
MIP to status regulacyjny wynikający z ustawy o usługach płatniczych. Mikroprzedsiębiorstwo w DORA to odrębna kategoria określona na podstawie art. 3 pkt 60 rozporządzenia.
To rozróżnienie ma znaczenie, ponieważ część dodatkowych uproszczeń DORA przewidziano właśnie dla mikroprzedsiębiorstw, a nie automatycznie dla każdej MIP.
Jakie przepisy DORA stosuje mała instytucja płatnicza?
Podstawowym przepisem jest art. 16 ust. 1 DORA. Wyłącza on stosowanie pełnych ram zarządzania ryzykiem ICT z art. 5–15 wobec określonych kategorii podmiotów.
W ich miejsce MIP stosuje uproszczone ramy, szczegółowo określone w rozporządzeniu delegowanym (UE) 2024/1774.
Nie jest to jednak wyłączenie z całego DORA.
| Obszar | Czy dotyczy MIP? | Podstawa prawna |
|---|---|---|
| Uproszczone ramy zarządzania ryzykiem ICT | Tak | Art. 16 DORA i art. 28–41 rozporządzenia 2024/1774 |
| Pełne ramy zarządzania ryzykiem ICT | Nie w tym reżimie | Wyłączenie art. 5–15 DORA |
| Zarządzanie incydentami ICT | Tak | Art. 17–23 DORA |
| Zgłaszanie poważnych incydentów | Tak | Art. 19 i 23 DORA oraz właściwe standardy techniczne |
| Testowanie odporności cyfrowej | Tak, z odpowiednimi uproszczeniami | Art. 24–25 DORA i art. 36, 40 rozporządzenia 2024/1774 |
| Zaawansowane testy TLPT | Co do zasady nie | Wyłączenie art. 26–27 DORA |
| Zarządzanie dostawcami ICT | Tak | Art. 28–30 DORA |
| Odrębna strategia ryzyka dostawców ICT z art. 28 ust. 2 | Nie jest wymagana w tym reżimie | Wyłączenie art. 28 ust. 2 DORA |
| Rejestr informacji o umowach ICT | Tak | Art. 28 ust. 3 DORA |
| Wymiana informacji o cyberzagrożeniach | Możliwa, na zasadach DORA | Art. 45 DORA |
Nie należy więc utożsamiać uproszczenia z brakiem odpowiedzialności regulacyjnej.
Najważniejsza różnica polega na sposobie organizacji zarządzania ryzykiem, a nie na możliwości całkowitej rezygnacji z cyberbezpieczeństwa.
Czy MIP musi mieć ISO 27001?
Nie. DORA nie nakłada na każdą MIP ogólnego obowiązku uzyskania certyfikatu ISO 27001.
Wdrożenie odpowiedniego systemu zarządzania bezpieczeństwem informacji może pomóc w spełnieniu części wymagań, ale certyfikacja nie zastępuje wykonania konkretnych obowiązków regulacyjnych.
Podmiot, który posiada ISO 27001, nadal musi sprawdzić chociażby zasady raportowania incydentów DORA, wymagania dotyczące rejestru informacji o umowach ICT oraz właściwe postanowienia kontraktów z dostawcami.
Analogicznie MIP, która nie posiada certyfikatu ISO, może spełniać wymagania DORA poprzez odpowiednio zaprojektowane i rzeczywiście stosowane rozwiązania.
Komentarz ekspercki – Bartosz Pasternak, Pasternak Business Law
W przypadku MIP istotne jest właściwe zidentyfikowanie zakresu regulacji. Przedsiębiorca nie powinien kupować dokumentacji przygotowanej dla dużej instytucji finansowej bez sprawdzenia, czy poszczególne obowiązki rzeczywiście go dotyczą.
Jednocześnie uproszczone ramy nie mogą być traktowane jako przyzwolenie na dokumentację pozorną. Jeśli instytucja nie potrafi wykazać, kto odpowiada za bezpieczeństwo systemu płatniczego, jak reaguje na incydent i czy potrafi odtworzyć dane po awarii, samo posiadanie polityki ICT nie rozwiązuje problemu.
2. Jakie dokumenty i procedury DORA musi posiadać MIP? Szczegółowa lista z podstawami prawnymi
To najważniejsza część całego wdrożenia.
W praktyce pytanie przedsiębiorcy brzmi zazwyczaj: „Ile procedur muszę przygotować, żeby spełnić wymagania DORA?”.
Nie istnieje jednak jeden obowiązkowy pakiet o ustawowo określonej liczbie dokumentów.
Rozporządzenie delegowane 2024/1774 przewiduje w motywie 26 uproszczenie obciążeń dokumentacyjnych dla podmiotów objętych art. 16 DORA. Zakłada opracowanie jednej nadrzędnej polityki bezpieczeństwa informacji.
Nie znosi to obowiązku opracowania szczególnych procedur, planów i dokumentacji wymaganych w dalszych przepisach.
Jedna polityka bezpieczeństwa informacji może więc stanowić centralny dokument całego systemu, ale musi zostać uzupełniona o odpowiednie procedury, rejestry i dowody wykonania obowiązków.
Lista kontrolna DORA dla MIP
Poniższa tabela rozróżnia obowiązek przewidziany w przepisach od praktycznej formy jego udokumentowania.
| Dokument lub obszar | Czy wymagany? | Podstawa |
|---|---|---|
| Polityka bezpieczeństwa informacji | Tak, dokument wprost wymagany | Art. 29 rozporządzenia 2024/1774 |
| Określenie odpowiedzialności zarządu i ról ICT | Tak, jako obowiązek organizacyjny; uchwała lub matryca odpowiedzialności to praktyczna forma udokumentowania | Art. 28 rozporządzenia 2024/1774 |
| Identyfikacja i klasyfikacja funkcji, zasobów informacyjnych oraz aktywów ICT | Tak, wymagane udokumentowanie | Art. 30 rozporządzenia 2024/1774 |
| Udokumentowana ocena ryzyka ICT | Tak | Art. 31 ust. 2 rozporządzenia 2024/1774 |
| Rejestr ryzyk ICT | Praktycznie zalecany sposób prowadzenia wymaganej oceny ryzyka | Art. 16 DORA i art. 31 rozporządzenia 2024/1774 |
| Analiza wpływu zakłóceń na działalność (BIA) | Wymagana ocena i uwzględnienie jej wyników; odrębny dokument jest praktycznym rozwiązaniem | Art. 28 i 39 rozporządzenia 2024/1774 |
| Procedury kontroli dostępu fizycznego i logicznego | Tak, wprost wymagane | Art. 33 rozporządzenia 2024/1774 |
| Zabezpieczenia danych, sieci, urządzeń i systemów | Tak, jako wymagane środki; forma dokumentacji zależy od wdrożenia | Art. 32, 34–35 rozporządzenia 2024/1774 |
| Plan testów bezpieczeństwa ICT | Tak | Art. 36 rozporządzenia 2024/1774 |
| Procedura nabywania, rozwijania i utrzymywania systemów ICT | Gdy właściwa dla danego modelu i ryzyka | Art. 37 rozporządzenia 2024/1774 |
| Procedura zarządzania projektami ICT | Tak, wprost wymagana | Art. 38 ust. 1 rozporządzenia 2024/1774 |
| Procedura zarządzania zmianą ICT | Tak, wprost wymagana | Art. 38 ust. 2 rozporządzenia 2024/1774 |
| Plan ciągłości działania ICT (BCP) | Tak | Art. 16 DORA i art. 39 rozporządzenia 2024/1774 |
| Dokumentacja testów ciągłości działania i odtwarzania danych | Tak | Art. 40 rozporządzenia 2024/1774 |
| Proces wykrywania, klasyfikacji i obsługi incydentów ICT | Tak; odrębna procedura jest rekomendowaną formą wdrożenia | Art. 17–23 DORA |
| Rejestr informacji o umowach z dostawcami ICT | Tak | Art. 28 ust. 3 DORA i rozporządzenie 2024/2956 |
| Przegląd ram zarządzania ryzykiem ICT i raport z przeglądu | Przegląd okresowy wymagany; raport przedstawiany organowi na żądanie | Art. 16 ust. 2 DORA i art. 41 rozporządzenia 2024/1774 |
| Audyt wewnętrzny uproszczonych ram ICT | Tak, z częstotliwością proporcjonalną do ryzyka | Art. 28 ust. 5–6 rozporządzenia 2024/1774 |
| Dowody szkoleń i działań zwiększających świadomość ICT | Działania wymagane; rejestr szkoleń jest zalecanym dowodem realizacji | Art. 16 ust. 1 lit. h DORA i art. 28 rozporządzenia 2024/1774 |
Tabela nie oznacza konieczności sporządzenia dziewiętnastu osobnych dokumentów.
Dobrze zaprojektowany system może łączyć część zagadnień w jednej polityce i jej załącznikach. Inne obowiązki, takie jak rejestr informacji o dostawcach ICT czy dokumentowanie wyników testów, wymagają jednak odrębnego, aktualnego materiału dowodowego.
Polityka bezpieczeństwa informacji – fundament dokumentacji MIP
Art. 29 rozporządzenia 2024/1774 nakazuje opracować, udokumentować i wdrożyć politykę bezpieczeństwa informacji.
Nie powinna być ona ogólnym, kilkudziesięciostronicowym dokumentem mówiącym wyłącznie o tym, że firma chroni dane klientów.
Powinna określać zasady ochrony poufności, integralności, dostępności i autentyczności danych oraz świadczonych usług.
W praktyce polityka MIP powinna odnosić się do konkretnych rozwiązań wykorzystywanych w prowadzonej działalności.
Jeżeli przedsiębiorca korzysta z zewnętrznego procesora płatniczego, hostingu, systemu KYC i aplikacji do obsługi użytkowników, dokument powinien wyjaśniać, jak organizacja zarządza ryzykiem wynikającym z tych zależności.
Polityka może stanowić podstawę dla dalszych procedur: zarządzania dostępami, monitorowania systemów, reagowania na incydenty, testów bezpieczeństwa czy zapewnienia ciągłości działania.
Nie powinna jednak zastępować procesów, które zgodnie z przepisami mają być rzeczywiście wykonywane.
Rejestr zasobów ICT i analiza ryzyka
Zgodnie z art. 30 rozporządzenia delegowanego MIP musi identyfikować, klasyfikować i dokumentować funkcje krytyczne lub istotne, wspierające je zasoby informacyjne i aktywa ICT oraz występujące między nimi zależności.
W praktyce oznacza to konieczność ustalenia, które systemy są niezbędne dla świadczenia usług płatniczych.
Przykładowy zakres może obejmować system obsługi transakcji, bazę danych klientów, infrastrukturę uwierzytelniania, interfejs API partnera płatniczego, system monitorowania AML oraz narzędzia do obsługi reklamacji.
Dla każdego istotnego zasobu warto określić właściciela biznesowego, dostawcę, znaczenie dla działalności i konsekwencje jego niedostępności.
Następnie należy przeprowadzić ocenę ryzyka ICT.
Art. 31 rozporządzenia 2024/1774 przewiduje m.in. określenie poziomów tolerancji ryzyka, identyfikację i ocenę zagrożeń, działania ograniczające ryzyko oraz monitorowanie skuteczności zabezpieczeń.
Ocena powinna być dokumentowana okresowo, z częstotliwością odpowiednią do profilu ryzyka instytucji.
Nie jest więc wystarczające jednorazowe stworzenie rejestru i pozostawienie go bez aktualizacji mimo istotnych zmian w infrastrukturze.
Przykład: jeżeli MIP przenosi system obsługi transakcji do nowego dostawcy chmury, nie należy traktować tego wyłącznie jako standardowej zmiany technicznej. Może to wymagać ponownej oceny ryzyka, zależności od dostawcy, bezpieczeństwa danych i możliwości kontynuowania działalności podczas awarii.
Procedura kontroli dostępów, zmian i zarządzania systemami
Art. 33 rozporządzenia 2024/1774 wymaga udokumentowania i wdrożenia procedur kontroli dostępu logicznego oraz fizycznego.
Instytucja powinna określić, kto może korzystać z systemów i danych, kto zatwierdza uprawnienia oraz jak są one zmieniane i odbierane.
Szczególne znaczenie mają dostępy administracyjne, konta uprzywilejowane, logowanie zdalne i dostęp do systemów wspierających funkcje krytyczne lub istotne.
To właśnie w niewielkich fintechach często pojawia się praktyczny problem: kilka osób posiada bardzo szerokie uprawnienia, a proces ich nadawania nie jest odpowiednio udokumentowany.
Nie musi to oznaczać naruszenia DORA w każdym przypadku. Wymaga jednak oceny w świetle zasady minimalnych uprawnień, konieczności identyfikowania użytkowników i okresowego przeglądania dostępów.
Równie istotny jest art. 38, który nakazuje MIP opracować i wdrożyć procedury zarządzania projektami ICT oraz zmianami w systemach.
W praktyce chodzi o zapewnienie, że istotna aktualizacja aplikacji płatniczej zostanie odpowiednio oceniona, przetestowana, zatwierdzona i wdrożona w kontrolowany sposób.
Plan ciągłości działania i odtwarzania systemów
Jednym z najważniejszych dokumentów jest plan ciągłości działania ICT (BCP).
Nie chodzi przy tym wyłącznie o posiadanie kopii zapasowych.
Art. 39 rozporządzenia 2024/1774 wymaga, aby plan uwzględniał możliwe poważne zakłócenia działalności, w tym scenariusze cyberataków, oraz określał zasady utrzymania i przywrócenia funkcji krytycznych lub istotnych.
Dobrze przygotowany plan powinien odpowiadać na następujące pytania:
- Co się stanie, jeśli podstawowa aplikacja płatnicza będzie niedostępna przez kilka godzin?
- Czy przedsiębiorca nadal będzie miał dostęp do danych potrzebnych do prawidłowego rozliczenia transakcji?
- Kto podejmie decyzję o uruchomieniu procedury awaryjnej?
- Jakie są dopuszczalne okresy przerwy i utraty danych?
- Czy istnieje możliwość przełączenia na rozwiązanie zastępcze?
- Jak przebiega komunikacja z klientami i dostawcami?
- Kto potwierdza, że można bezpiecznie wznowić operacje?
W praktyce warto zdefiniować parametry takie jak RTO (Recovery Time Objective) oraz RPO (Recovery Point Objective), dostosowane do krytyczności procesów.
RTO oznacza docelowy czas przywrócenia działania, natomiast RPO określa dopuszczalny zakres utraty danych wyrażony w czasie.
Nie wystarczy jednak wpisać tych wartości do tabeli. Muszą odpowiadać rzeczywistym możliwościom technicznym organizacji i jej dostawców.
Co szczególnie istotne, art. 40 wymaga testowania planów ciągłości działania. Testy procedur tworzenia kopii zapasowych i odtwarzania należy przeprowadzać co najmniej raz w roku, a przy istotnych zmianach planu uwzględnić dodatkowe testowanie.
Wyniki muszą zostać udokumentowane, a stwierdzone braki przeanalizowane i przedstawione organowi zarządzającemu.
Czy MIP musi przeprowadzać audyt DORA?
Tak, ale nie należy utożsamiać tego z obowiązkiem przeprowadzania kosztownych testów TLPT.
Art. 28 ust. 5–6 rozporządzenia 2024/1774 wymaga objęcia uproszczonych ram zarządzania ryzykiem ICT audytem wewnętrznym wykonywanym przez osoby posiadające odpowiednie kompetencje i niezależność.
Częstotliwość i zakres audytu powinny być proporcjonalne do ryzyka ICT konkretnej instytucji.
Audyt może zostać odpowiednio zorganizowany z wykorzystaniem zewnętrznych specjalistów, przy zachowaniu wymaganej niezależności. Nie zwalnia to MIP z odpowiedzialności za właściwe zarządzanie ryzykiem.
Inną kwestią są zaawansowane testy penetracyjne oparte na analizie zagrożeń (TLPT), których reżim z art. 26–27 DORA nie znajduje zastosowania do MIP korzystającej z art. 16.
Nie oznacza to zwolnienia ze zwykłych testów bezpieczeństwa.
Art. 36 rozporządzenia 2024/1774 wymaga ustanowienia planu testowania zabezpieczeń ICT, odpowiedniego do zidentyfikowanych zagrożeń i ryzyka.
Komentarz ekspercki – Bartosz Pasternak, Pasternak Business Law
Najczęstszy problem przy dokumentacji DORA nie musi polegać na braku określonej polityki. Znacznie poważniejsza może być sytuacja, w której instytucja posiada procedury, ale nie ma dowodów ich stosowania.
Jeżeli dokument przewiduje okresowy przegląd dostępów, trzeba wykazać, że przegląd rzeczywiście przeprowadzono. Jeżeli plan ciągłości działania zakłada możliwość odtworzenia systemu w określonym czasie, organizacja powinna potrafić potwierdzić to odpowiednim testem.
Dobrze przygotowana dokumentacja DORA powinna umożliwiać odtworzenie procesu podejmowania decyzji, przypisanie odpowiedzialności i wykazanie skuteczności zastosowanych środków.
3. DORA dla MIP a KNF – raportowanie incydentów, rejestr informacji i umowy ICT
Samo przygotowanie polityki bezpieczeństwa i planu ciągłości działania nie kończy obowiązków małej instytucji płatniczej.
MIP powinna być przygotowana także do realizowania określonych obowiązków nadzorczych, w szczególności zgłaszania poważnych incydentów, prowadzenia rejestru informacji o umowach ICT oraz przekazywania właściwych formularzy KNF.
Kiedy MIP musi zgłosić incydent ICT do KNF?
Rozporządzenie DORA przewiduje obowiązek zgłaszania poważnych incydentów związanych z ICT.
Nie każdy problem techniczny będzie jednak automatycznie kwalifikowany jako poważny incydent.
Kwalifikacja następuje z uwzględnieniem odpowiednich kryteriów, w tym wpływu na świadczone usługi, klientów, transakcje, dostępność systemów, dane i skutków ekonomicznych.
Szczegółowe kryteria określa rozporządzenie delegowane (UE) 2024/1772.
Jeżeli zdarzenie zostanie zakwalifikowane jako poważny incydent związany z ICT, należy zastosować odpowiedni harmonogram raportowania.
| Etap raportowania | Termin |
|---|---|
| Wstępne powiadomienie | Niezwłocznie, najpóźniej w ciągu 4 godzin od klasyfikacji incydentu jako poważnego, ale nie później niż 24 godziny od uzyskania wiedzy o jego wystąpieniu |
| Sprawozdanie śródokresowe | W ciągu 72 godzin od przekazania wstępnego powiadomienia, z uwzględnieniem właściwych zasad aktualizacji |
| Sprawozdanie końcowe | Co do zasady nie później niż miesiąc od sprawozdania śródokresowego lub ostatniej właściwej aktualizacji |
Terminy wynikają z rozporządzenia delegowanego (UE) 2025/301 i zostały uwzględnione w oficjalnym zestawieniu obowiązków sprawozdawczych KNF.
To jeden z najważniejszych powodów, dla których procedura obsługi incydentów musi być dostosowana do rzeczywistej organizacji pracy.
Jeżeli odpowiedzialność za bezpieczeństwo ICT ponosi zewnętrzny software house, a zarząd MIP otrzymuje informacje o awariach wyłącznie poprzez ogólną skrzynkę e-mail, instytucja może mieć poważny problem z terminową identyfikacją i zgłaszaniem incydentów.
Szczególnie ważne jest ustalenie, kiedy organizacja dowiedziała się o wystąpieniu zdarzenia oraz kiedy dokonano jego klasyfikacji.
Gdzie zgłasza się incydenty DORA?
KNF udostępnia System do Obsługi Incydentów DORA (SOID):
W przypadku niedostępności systemu urząd przewiduje alternatywny kanał zgłoszeniowy na adres incydenty.dora@knf.gov.pl, z wykorzystaniem odpowiednich formularzy.
Po przywróceniu dostępności SOID zgłoszenie przesłane awaryjnie należy również zarejestrować w systemie.
Szczegółowe informacje znajdują się na stronie KNF dotyczącej systemów DORA.
Warto dodać, że DORA zmieniła również zasady zgłaszania poważnych incydentów operacyjnych i bezpieczeństwa związanych z płatnościami wobec dostawców usług płatniczych objętych rozporządzeniem.
Z tego względu MIP nie powinna bez sprawdzenia stosować wyłącznie historycznej procedury raportowania incydentów PSD2, przygotowanej przed 17 stycznia 2025 r.
Rejestr informacji DORA – co musi zawierać MIP?
Jednym z najważniejszych obowiązków jest prowadzenie rejestru informacji dotyczących wszystkich odpowiednich ustaleń umownych związanych z korzystaniem z usług ICT świadczonych przez zewnętrznych dostawców.
Obowiązek wynika z art. 28 ust. 3 DORA.
Zakres i standardowe wzory rejestru określa rozporządzenie wykonawcze Komisji (UE) 2024/2956.
Rejestr DORA nie jest jedynie zwykłą listą dostawców.
Powinien umożliwiać identyfikację relacji umownych, świadczonych usług ICT oraz związanych z nimi funkcji organizacji, z uwzględnieniem danych wymaganych przez właściwe standardy techniczne.
W praktyce należy zebrać m.in. informacje dotyczące:
- podmiotów będących stronami ustaleń umownych;
- dostawców usług ICT oraz właściwych identyfikatorów;
- świadczonych usług i wspieranych funkcji;
- relacji między dostawcami i odpowiednimi usługami;
- okresu obowiązywania kontraktów;
- lokalizacji istotnych elementów świadczenia usług i przetwarzania danych;
- charakteru funkcji, które są wspierane przez daną usługę ICT.
Nie należy zakładać, że rejestr obejmuje wyłącznie umowy dotyczące funkcji krytycznych lub istotnych.
Art. 28 ust. 3 przewiduje szerszy zakres rejestracji informacji o umowach ICT, przy czym kwalifikacja krytyczności funkcji wpływa na zakres dalszych obowiązków.
Istotne jest również ustalenie, czy dany kontrahent rzeczywiście świadczy usługę ICT, a nie jedynie wykonuje inną usługę istotną dla działalności płatniczej.
Przykładowo bank prowadzący rachunki rozliczeniowe MIP nie musi z samego tego powodu być uznawany za zewnętrznego dostawcę usług ICT. Jeżeli jednak ten sam podmiot świadczy odrębne usługi technologiczne, konieczna może być osobna ocena tego zakresu współpracy.
Czy MIP musi raportować rejestr DORA do KNF?
MIP musi prowadzić i aktualizować rejestr informacji.
Należy jednak odróżnić obowiązek jego utrzymywania od przekazania pełnej zawartości organowi nadzoru.
KNF przewiduje m.in. formularz SPR-PF-18, dotyczący przedstawienia pełnego rejestru informacji lub jego odpowiedniej części na żądanie.
Jednocześnie w tabelach sprawozdawczych KNF wskazano obowiązek przekazywania określonych informacji o nowych ustaleniach umownych dotyczących usług ICT oraz zgłoszeń związanych z usługami wspierającymi funkcje krytyczne lub istotne.
Dlatego właściwa dokumentacja powinna obejmować nie tylko sam rejestr, ale również mechanizm sprawdzania, kiedy powstaje obowiązek przekazania informacji nadzorczych.
Warto też zadbać o identyfikator LEI, którego znaczenie dla sprawozdawczości DORA podkreśla KNF.
Pełen zestaw formularzy i aktualnych instrukcji należy każdorazowo weryfikować w sekcji sprawozdawczości DORA KNF.
Jakie formularze DORA są szczególnie istotne dla MIP?
W dokumentacji publikowanej przez KNF wskazano m.in. następujące formularze:
| Formularz KNF | Zakres |
|---|---|
| SPR-PF-06 | Sprawozdanie z przeglądu uproszczonych ram zarządzania ryzykiem ICT – na żądanie |
| SPR-PF-07 | Wstępne powiadomienie o poważnym incydencie ICT |
| SPR-PF-08 | Sprawozdanie śródokresowe dotyczące poważnego incydentu |
| SPR-PF-09 | Sprawozdanie końcowe dotyczące poważnego incydentu |
| SPR-PF-10 | Dobrowolne powiadomienie o znaczącym cyberzagrożeniu |
| SPR-PF-17 | Okresowe informacje o nowych ustaleniach dotyczących korzystania z usług ICT |
| SPR-PF-18 | Rejestr informacji lub jego część – na żądanie |
| SPR-PF-19 i SPR-PF-20 | Informacje dotyczące określonych ustaleń umownych wspierających funkcje krytyczne lub istotne |
| SPR-PF-30 | Roczna ankieta dotycząca kluczowych wskaźników ryzyka ICT dla podmiotów stosujących uproszczone ramy |
Powyższe zestawienie nie oznacza, że wszystkie formularze należy składać regularnie i bez wystąpienia zdarzenia uruchamiającego obowiązek. Część dotyczy incydentów, część zgłoszeń na żądanie, a część sprawozdawczości okresowej.
Właściwe terminy i zasady przekazywania dokumentów należy ustalać z uwzględnieniem aktualnych przepisów, wymagań KNF i instrukcji właściwego systemu.
Umowy z dostawcami ICT – co powinna zweryfikować MIP?
DORA wymaga, aby instytucja finansowa zarządzała ryzykiem związanym z korzystaniem z usług technologicznych świadczonych przez podmioty trzecie.
Nie wystarczy więc podpisać standardowej umowy hostingowej albo SaaS i założyć, że odpowiedzialność za bezpieczeństwo została całkowicie przeniesiona na dostawcę.
Art. 30 DORA ustanawia wymagania dotyczące treści określonych ustaleń umownych.
W szczególności należy zweryfikować zasady opisu usług, lokalizację świadczenia i przetwarzania danych, bezpieczeństwo informacji, współpracę przy incydentach, dostępność danych, pomoc przy zakończeniu umowy oraz inne obowiązkowe postanowienia.
Dodatkowe wymagania dotyczą kontraktów wspierających funkcje krytyczne lub istotne.
Warto jednak pamiętać, że do MIP stosującej uproszczone ramy nie stosuje się obowiązku przygotowania odrębnej strategii ryzyka dostawców ICT przewidzianej w art. 28 ust. 2 DORA.
Nie oznacza to jednak, że można zignorować obowiązki z art. 28 ust. 1, 3–8 oraz art. 29–30, w zakresie w jakim znajdują zastosowanie.
Przy wdrażaniu DORA szczególnie istotna może być analiza umów IT, outsourcingu oraz kontraktów z dostawcami technologii.
W przypadku niewielkich instytucji płatniczych dobrze przygotowany przegląd istniejących umów może mieć większą wartość niż stworzenie kolejnej, ogólnej polityki.
4. Jak wdrożyć DORA w małej instytucji płatniczej? Przykład praktyczny i plan działania
Rozważmy hipotetyczną MIP, która prowadzi działalność polegającą na obsłudze płatności dla klientów biznesowych.
Spółka posiada niewielki zespół, korzysta z infrastruktury chmurowej, zewnętrznego systemu KYC oraz partnera technologicznego obsługującego istotną część procesu płatniczego.
Zarząd odpowiada za rozwój działalności, relacje z klientami i zgodność regulacyjną, ale nie zatrudnia rozbudowanego działu bezpieczeństwa IT.
Czy taka organizacja potrzebuje takiego samego systemu dokumentacji i zarządzania ryzykiem jak duży bank?
Nie.
Nie oznacza to jednak, że wystarczy jedna ogólna polityka bezpieczeństwa pobrana z internetu.
Przykład: awaria procesora płatniczego
Załóżmy, że w poniedziałek o godzinie 9:00 partner technologiczny informuje MIP o awarii systemu odpowiedzialnego za obsługę transakcji.
Część klientów nie może realizować płatności. Instytucja nie ma jeszcze pełnych danych o liczbie transakcji objętych problemem.
O godzinie 10:00 okazuje się, że awaria nie została usunięta, a jej skutki dotyczą istotnej części działalności.
Jak powinien działać system DORA?
Po pierwsze, instytucja musi wykryć i prawidłowo zarejestrować incydent.
Należy ustalić, kto odpowiada za odbieranie komunikatów od dostawcy i rozpoczęcie obsługi zdarzenia.
Po drugie, trzeba ocenić wpływ awarii i przeprowadzić klasyfikację.
Sama niedostępność usługi nie przesądza automatycznie o poważnym incydencie, ale konieczne jest zastosowanie kryteriów wynikających z DORA i właściwych standardów technicznych.
Po trzecie, trzeba uruchomić odpowiednie działania awaryjne.
Jeżeli zdarzenie wpływa na funkcję krytyczną lub istotną, MIP powinna stosować przygotowany plan ciągłości działania, uwzględniając możliwe rozwiązania zastępcze i zasady komunikacji.
Po czwarte, w razie spełnienia przesłanek poważnego incydentu trzeba dochować terminów raportowania.
Instytucja nie może automatycznie czekać na końcowy raport dostawcy technologicznego, jeżeli dysponuje informacjami wystarczającymi do uruchomienia obowiązków zgłoszeniowych.
Po piąte, należy przeanalizować przyczyny zdarzenia i wdrożyć działania naprawcze.
Wnioski powinny wpływać na ocenę ryzyka, zabezpieczenia, plany awaryjne i zasady współpracy z dostawcą.
Taki właśnie model działania powinien wynikać z dokumentacji DORA.
Przykład ma charakter hipotetyczny i służy wyjaśnieniu obowiązków organizacyjnych. Nie opisuje konkretnej sprawy klienta kancelarii.
Plan uporządkowania dokumentacji DORA – etapy wdrożenia
W przypadku instytucji, która nie uporządkowała jeszcze swoich obowiązków, rekomendowane jest rozpoczęcie od przeglądu stanu faktycznego.
Etap pierwszy: kwalifikacja i gap analysis.
Należy potwierdzić status instytucji, zakres stosowanych przepisów i istniejące rozwiązania ICT.
W tym etapie analizuje się m.in. mapę usług płatniczych, systemy wykorzystywane do ich świadczenia, dostawców oraz obowiązujące dokumenty.
Etap drugi: opracowanie struktury dokumentacji.
Na podstawie wyników analizy można ustalić, jakie dokumenty już spełniają wymagania, które wymagają aktualizacji i jakie nowe materiały są potrzebne.
Nie należy tworzyć odrębnych polityk wyłącznie dlatego, że taki układ znajduje się w gotowym pakiecie dokumentacji.
Etap trzeci: wdrożenie procesów operacyjnych.
Konieczne jest przypisanie odpowiedzialności, opracowanie procesu obsługi incydentów, przegląd dostępów, identyfikacja ryzyk i zapewnienie właściwych mechanizmów monitorowania.
Etap czwarty: dostawcy i rejestr informacji.
Należy zidentyfikować zewnętrznych dostawców ICT, przeanalizować zawarte umowy, zweryfikować wymagane klauzule i uporządkować rejestr informacji zgodnie z DORA.
Etap piąty: testy, audyt i dalszy nadzór.
Ostatnim etapem jest sprawdzenie, czy wdrożone mechanizmy rzeczywiście działają, w tym poprzez odpowiednie testy, przeglądy i audyt wewnętrzny.
Powyższe etapy są propozycją organizacji projektu, a nie ustawowymi terminami na wdrożenie DORA. Obowiązki wynikające z rozporządzenia mają już zastosowanie.
Czy odpowiedzialność za DORA można przenieść na firmę IT?
Nie.
MIP może korzystać z zewnętrznych dostawców technologii i odpowiednio powierzać im wykonanie określonych czynności. Nie oznacza to jednak przeniesienia na nich całości odpowiedzialności za zgodność instytucji z DORA.
W praktyce szczególnie istotna jest kwestia nadzoru nad dostawcą.
Jeżeli zewnętrzny partner odpowiada za utrzymanie aplikacji płatniczej, instytucja powinna ustalić, w jaki sposób uzyskuje informacje o incydentach, jakie ma uprawnienia kontrolne i jak będzie postępować w razie niedostępności usługi.
Samo zobowiązanie dostawcy do zachowania poufności nie wystarcza.
Czy zarząd MIP odpowiada za DORA?
Organ zarządzający ponosi odpowiedzialność za właściwe funkcjonowanie uproszczonych ram zarządzania ryzykiem ICT.
Art. 28 rozporządzenia 2024/1774 przewiduje m.in. konieczność wyznaczenia odpowiednich ról i odpowiedzialności, określenia celów bezpieczeństwa, zatwierdzania i okresowego przeglądu odpowiednich dokumentów oraz zapewnienia zasobów niezbędnych do realizacji obowiązków.
Przepis wymaga również odpowiedniego nadzoru nad budżetem, szkoleniami i świadomością bezpieczeństwa ICT.
Nie oznacza to obowiązku tworzenia w każdej MIP osobnego, rozbudowanego departamentu cyberbezpieczeństwa.
Konieczne jest natomiast zapewnienie, aby organizacja posiadała odpowiednie kompetencje i rzeczywistą możliwość wykonywania swoich obowiązków.
Komentarz ekspercki – Bartosz Pasternak, Pasternak Business Law
W niewielkiej instytucji płatniczej największym problemem jest często zależność od kilku kluczowych dostawców oraz niewielka liczba osób, które rzeczywiście rozumieją architekturę usługi.
Dlatego wdrożenie DORA powinno zaczynać się od mapy procesów, zależności technologicznych i odpowiedzialności, a nie od zakupu dużego zestawu dokumentów.
Uproszczenie regulacyjne nie oznacza obniżenia znaczenia ryzyka. Oznacza możliwość zastosowania rozwiązań odpowiednich do charakteru i skali działalności, pod warunkiem że są one zgodne z właściwymi wymaganiami.
5. DORA dla MIP – najczęstsze pytania i odpowiedzi
Czy każda mała instytucja płatnicza musi wdrożyć DORA?
Tak. MIP należy do kategorii podmiotów objętych DORA, ale zgodnie z art. 16 korzysta z uproszczonych ram zarządzania ryzykiem ICT.
Zakres obowiązków należy określić z uwzględnieniem stosowanych przepisów, charakteru działalności i właściwych zasad proporcjonalności.
Od kiedy DORA obowiązuje małe instytucje płatnicze?
DORA stosuje się od 17 stycznia 2025 r.
Na dzień 12 października 2026 r. nie należy więc traktować tych przepisów jako regulacji, która dopiero zacznie obowiązywać.
Czy MIP musi mieć 20 osobnych procedur DORA?
Nie. Przepisy nie określają jednej obowiązkowej liczby osobnych dokumentów.
Wymagają natomiast m.in. polityki bezpieczeństwa informacji, określonych procedur zarządzania dostępem i zmianą ICT, planu ciągłości działania, dokumentowania ryzyka, testów, rejestru informacji i realizowania pozostałych odpowiednich obowiązków.
Dokumentację można uporządkować w spójny system, bez niepotrzebnego powielania tych samych treści.
Czy MIP musi prowadzić rejestr informacji DORA?
Tak. Obowiązek wynika z art. 28 ust. 3 DORA.
Rejestr dotyczy odpowiednich ustaleń umownych związanych z korzystaniem z usług ICT świadczonych przez zewnętrznych dostawców.
Szczegółowe standardy dotyczące jego struktury i zawartości określa rozporządzenie wykonawcze (UE) 2024/2956.
Czy MIP musi raportować incydenty do KNF?
Tak, jeżeli zdarzenie spełnia odpowiednie przesłanki poważnego incydentu związanego z ICT.
Nie każdy drobny problem techniczny podlega jednak obowiązkowi zgłoszenia. Konieczne jest prawidłowe zastosowanie kryteriów klasyfikacji.
Czy MIP musi przeprowadzać testy ciągłości działania?
Tak.
Art. 40 rozporządzenia 2024/1774 przewiduje obowiązek testowania planów ciągłości działania, w tym odpowiedniego testowania kopii zapasowych i procedur odtwarzania.
Wyniki testów powinny zostać udokumentowane, a zidentyfikowane braki przeanalizowane i usunięte.
Czy MIP musi przeprowadzać testy TLPT?
Co do zasady nie. Zaawansowane testy TLPT z art. 26–27 DORA nie znajdują zastosowania do instytucji stosujących uproszczone ramy z art. 16.
Nie oznacza to jednak zwolnienia z testowania bezpieczeństwa systemów i kontroli przewidzianych w pozostałych przepisach.
Czy MIP musi mieć audyt DORA?
Tak, uproszczone ramy powinny być objęte niezależnym audytem wewnętrznym na zasadach art. 28 ust. 5–6 rozporządzenia 2024/1774.
Zakres i częstotliwość audytu należy dostosować do ryzyka ICT.
Nie jest to tożsame z obowiązkiem corocznej certyfikacji ISO 27001.
Czy procedura AML może zastąpić dokumentację DORA?
Nie.
AML i DORA dotyczą częściowo powiązanych zagadnień zarządzania ryzykiem, ale mają odmienny zakres i cele.
Procedura AML może obejmować m.in. monitorowanie transakcji i weryfikację klientów, natomiast DORA koncentruje się na operacyjnej odporności cyfrowej, ryzyku ICT, incydentach, testach, ciągłości działania oraz dostawcach technologii.
W praktyce warto zapewnić spójność obu systemów, ale nie należy traktować ich jako zamiennych.
Czy MIP, która już posiada dokumentację bezpieczeństwa, musi tworzyć wszystko od początku?
Niekoniecznie.
Jeżeli instytucja posiada istniejące procedury dotyczące bezpieczeństwa, ryzyka operacyjnego, incydentów lub outsourcingu, warto rozpocząć od ich przeglądu.
W wielu przypadkach właściwsze będzie uzupełnienie istniejących rozwiązań niż tworzenie równoległego systemu dokumentacyjnego.
Konieczna jest jednak weryfikacja, czy dokumentacja odpowiada aktualnym wymaganiom DORA oraz czy jest rzeczywiście stosowana.
Czy biuro usług płatniczych (BUP) również podlega DORA?
Tak. KNF wskazuje biura usług płatniczych jako podmioty objęte uproszczonymi ramami zarządzania ryzykiem ICT.
Zakres konkretnych rozwiązań powinien być dostosowany do rzeczywiście prowadzonej działalności, rodzaju systemów oraz profilu ryzyka.
Czy DORA zastępuje wcześniejsze obowiązki MIP wobec KNF?
Nie w całości.
DORA zmienia określone zasady zarządzania ryzykiem ICT i raportowania incydentów, ale MIP nadal powinna weryfikować obowiązki wynikające z ustawy o usługach płatniczych.
Przykładowo KNF wskazuje odrębny obowiązek corocznego przekazywania informacji o ocenie i aktualizacji procedur zarządzania ryzykiem operacyjnym oraz ryzykiem naruszenia bezpieczeństwa, co do zasady do 31 stycznia kolejnego roku, na zasadach określonych w przepisach sektorowych.
Dlatego prawidłowe wdrożenie DORA powinno być elementem całego systemu compliance instytucji płatniczej, a nie jego zamiennikiem.
Jak rozpocząć wdrożenie DORA w MIP?
Najrozsądniejszym pierwszym krokiem jest analiza zakresu stosowania przepisów i ocena istniejących rozwiązań.
Warto ustalić, jakie funkcje i systemy wspierają działalność płatniczą, kto jest za nie odpowiedzialny, z jakich dostawców korzysta organizacja i jakie dokumenty już posiada.
Dopiero następnie należy przygotować listę braków, harmonogram działań, wymagane procedury i dokumenty oraz plan odpowiednich testów i przeglądów.
DORA dla MIP – podsumowanie
Mała instytucja płatnicza nie musi wdrażać pełnych ram zarządzania ryzykiem ICT przewidzianych dla wszystkich kategorii podmiotów finansowych.
Musi jednak zapewnić rzeczywiście funkcjonujące uproszczone ramy wynikające z art. 16 DORA i rozporządzenia delegowanego 2024/1774, a także realizować właściwe obowiązki dotyczące incydentów, testowania odporności, dostawców ICT i sprawozdawczości.
W praktyce najważniejsze nie jest stworzenie jak największej liczby dokumentów, lecz prawidłowe połączenie polityk, procedur, rejestrów, umów, testów i nadzoru nad dostawcami z rzeczywistym modelem świadczenia usług płatniczych.
Czy Twoja MIP ma dokumentację DORA, ale nie wiesz, czy spełnia ona aktualne wymagania KNF?
W Pasternak Business Law wspieramy małe i krajowe instytucje płatnicze, fintechy oraz podmioty świadczące usługi płatnicze w analizie obowiązków regulacyjnych, przygotowaniu dokumentacji compliance i weryfikacji umów z dostawcami technologii.
W ramach obsługi prawnej DORA i compliance ICT pomagamy w kwalifikacji obowiązków, analizie istniejących procedur, uporządkowaniu rejestru informacji, ocenie umów outsourcingowych oraz przygotowaniu prawnych i organizacyjnych elementów wdrożenia.
Jeżeli dopiero planujesz rozpoczęcie działalności płatniczej, warto również przeanalizować różnice pomiędzy MIP a KIP i wymagania związane z prowadzeniem działalności jako instytucja płatnicza.
Skontaktuj się z Pasternak Business Law i omów dokumentację DORA swojej instytucji.
Podstawy prawne i oficjalne źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 – DORA, w szczególności art. 2–4, 16–25, 28–30 i 45.
- Rozporządzenie delegowane Komisji (UE) 2024/1774, w szczególności art. 1 i art. 28–41 dotyczące uproszczonych ram zarządzania ryzykiem ICT.
- Rozporządzenie delegowane Komisji (UE) 2024/1772 – kryteria klasyfikacji incydentów związanych z ICT i cyberzagrożeń.
- Rozporządzenie wykonawcze Komisji (UE) 2024/2956 – standardowe wzory rejestru informacji o umowach ICT.
- Rozporządzenie delegowane Komisji (UE) 2025/301 – treść i terminy raportowania poważnych incydentów.
- Rozporządzenie wykonawcze Komisji (UE) 2025/302 – formularze i procedury raportowania incydentów.
- KNF – wymagania DORA dla podmiotów stosujących uproszczone ramy ICT.
- KNF – obowiązki sprawozdawcze DORA.
- KNF – systemy DORA.
- KNF – podstawowe obowiązki małych instytucji płatniczych.
Autor: Bartosz Pasternak
Prawnik zarządzający, Pasternak Business Law
Stan prawny: 12 października 2026 r.
Materiał ma charakter informacyjny i edukacyjny. Nie stanowi indywidualnej porady prawnej. Zakres obowiązków DORA oraz wymaganej dokumentacji zależy od statusu regulacyjnego podmiotu, jego struktury, rzeczywistego modelu działalności, wykorzystywanych technologii, charakteru usług płatniczych i aktualnych wymagań właściwych organów nadzoru.