DORA w praktyce w 2026 r. — obowiązki podmiotów finansowych i dostawców ICT krok po kroku

Stan prawny i punkt wyjścia na 18 lipca 2026 r.

DORA jest stosowana od 17 stycznia 2025 r., więc w 2026 r. pytanie nie brzmi już „czy trzeba się przygotować”, lecz czy przyjęte procedury działają, czy rejestry są kompletne, czy umowy z dostawcami ICT rzeczywiście pozwalają wykonywać obowiązki i czy zarząd otrzymuje informacje potrzebne do nadzoru.

• Rozporządzenie DORA jest stosowane od 17 stycznia 2025 r.
• KNF wskazuje pięć głównych obszarów: zarządzanie ryzykiem ICT, testowanie odporności, ryzyko dostawców ICT, ramy nadzoru oraz zgłaszanie poważnych incydentów ICT.

Ten poradnik ma charakter praktyczny i koncentruje się na sposobie organizacji zgodności. Nie zastępuje analizy konkretnego podmiotu, ponieważ zakres obowiązków zależy m.in. od roli prawnej, sektora, wielkości, rodzaju systemu, kategorii danych i modelu współpracy z dostawcami. W projektach technologicznych kilka reżimów często działa jednocześnie, dlatego kwalifikację trzeba wykonywać warstwowo.

Najlepszym punktem startu jest opis rzeczywistego procesu: kto korzysta z technologii, jakie dane są używane, co może się stać w razie błędu i od jakich dostawców zależy działanie usługi. Dopiero potem należy przypisać przepisy, obowiązki, właścicieli i dowody. Odwrócona kolejność — rozpoczęcie od generowania dokumentów — zwykle prowadzi do kosztownej dokumentacji, której nikt nie używa.

DORA jako system operacyjny, a nie jednorazowy projekt

Po dacie rozpoczęcia stosowania regulacji organizacja powinna przejść z trybu wdrożenia do trybu utrzymania. Oznacza to cykliczne przeglądy ryzyka, testy, aktualizację rejestrów i monitorowanie dostawców.

Po dacie rozpoczęcia stosowania regulacji organizacja powinna przejść z trybu wdrożenia do trybu utrzymania. Oznacza to cykliczne przeglądy ryzyka, testy, aktualizację rejestrów i monitorowanie dostawców. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

Największe ryzyko to dokumentacja zamrożona na dzień 17 stycznia 2025 r., podczas gdy architektura ICT i łańcuch dostaw zmieniły się kilkukrotnie. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Ustal właścicieli procesów DORA, kalendarz przeglądów, źródła danych i procedurę aktualizacji po każdej istotnej zmianie technologicznej.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Migracja krytycznego systemu do nowej chmury powinna automatycznie uruchamiać aktualizację oceny ryzyka, rejestru informacji, umów i scenariuszy ciągłości.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Zarządzanie ryzykiem ICT i odpowiedzialność zarządu

Organ zarządzający ma aktywną rolę w ramach zarządzania ryzykiem ICT. Odpowiedzialności nie da się wyzerować przez outsourcing IT.

Organ zarządzający ma aktywną rolę w ramach zarządzania ryzykiem ICT. Odpowiedzialności nie da się wyzerować przez outsourcing IT. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Zarząd, który otrzymuje wyłącznie techniczne raporty bez kontekstu biznesowego, nie może racjonalnie podejmować decyzji o akceptacji ryzyka i inwestycjach. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Raportuj kluczowe ryzyka, zdarzenia, wyniki testów, zaległe działania, koncentrację dostawców i scenariusze krytyczne w języku decyzji zarządczych.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Informacja „99,9% dostępności” ma ograniczoną wartość, jeżeli zarząd nie wie, który proces biznesowy zatrzyma pozostałe 0,1% i na jak długo.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Incydenty ICT: klasyfikacja i zgłaszanie

DORA wprowadza ustrukturyzowane zarządzanie incydentami i obowiązki zgłoszeniowe dla poważnych incydentów ICT. Proces musi zaczynać się w chwili wykrycia zdarzenia.

DORA wprowadza ustrukturyzowane zarządzanie incydentami i obowiązki zgłoszeniowe dla poważnych incydentów ICT. Proces musi zaczynać się w chwili wykrycia zdarzenia. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Rozproszone kanały zgłoszeń i brak wspólnej klasyfikacji powodują opóźnienie decyzji prawnej oraz niespójne dane w kolejnych raportach. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Połącz SOC/ITSM z prawną macierzą kwalifikacji; ustal odpowiedzialność za klasyfikację, korekty informacji, komunikację i archiwizację dowodów.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Awaria dostawcy może rozpocząć się jako ticket techniczny, ale szybko stać się poważnym incydentem wymagającym zaangażowania compliance, zarządu i komunikacji.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Testowanie odporności i TLPT

Testy mają sprawdzać realną zdolność organizacji do zapobiegania, wykrywania, reagowania i odtwarzania. Sam skan podatności nie zastępuje programu testów odporności.

Testy mają sprawdzać realną zdolność organizacji do zapobiegania, wykrywania, reagowania i odtwarzania. Sam skan podatności nie zastępuje programu testów odporności. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

Ryzykiem jest testowanie wyłącznie tego, co łatwo zmierzyć, przy pomijaniu zależności biznesowych i procesów manualnych. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Zbuduj wieloletni plan testów oparty na krytyczności, ryzyku i zmianach; wyniki przekładaj na działania korygujące z właścicielem i terminem.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Jeżeli plan ciągłości zakłada pracę zdalną, test powinien obejmować rzeczywistą możliwość działania zespołów, a nie tylko dostępność serwera zapasowego.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Dostawcy ICT i koncentracja ryzyka

DORA wymaga dojrzałego zarządzania ryzykiem stron trzecich. Kluczowe jest nie tylko to, czy dostawca jest bezpieczny, ale też jak istotna jest usługa i czy istnieje realna alternatywa.

DORA wymaga dojrzałego zarządzania ryzykiem stron trzecich. Kluczowe jest nie tylko to, czy dostawca jest bezpieczny, ale też jak istotna jest usługa i czy istnieje realna alternatywa. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Koncentracja na jednym dostawcy chmurowym, jednym regionie lub jednym integratorze może tworzyć ryzyko systemowe dla organizacji. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Klasyfikuj funkcje i dostawców, badaj podwykonawców, lokalizacje, przenoszalność danych, scenariusze wyjścia i zależności pomiędzy usługami.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Dwie aplikacje mogą być kupione od różnych spółek, lecz działać na tej samej chmurze i w tym samym regionie, co tworzy ukrytą koncentrację.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Umowy ICT: klauzule, których nie można traktować jako dodatku

Umowa jest narzędziem zarządzania ryzykiem. Powinna zapewnić organizacji informacje i prawa potrzebne do wykonania własnych obowiązków DORA.

Umowa jest narzędziem zarządzania ryzykiem. Powinna zapewnić organizacji informacje i prawa potrzebne do wykonania własnych obowiązków DORA. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Standard dostawcy może ograniczać audyt, dowolnie zmieniać podwykonawców albo przewidywać zbyt późne powiadomienie o incydencie. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Sprawdź zakres usług, SLA, bezpieczeństwo, lokalizacje, dostęp do danych, incydenty, audyt, współpracę z organami, podwykonawców, zakończenie i migrację.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Klauzula „dostawca poinformuje bez zbędnej zwłoki” może być za mało precyzyjna, jeżeli klient potrzebuje informacji do własnej terminowej klasyfikacji.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Rejestr informacji i jakość danych

Rejestr informacji nie powinien być traktowany jako plik przygotowywany raz do raportowania. Jego wartość zależy od aktualności danych o funkcjach, umowach i dostawcach.

Rejestr informacji nie powinien być traktowany jako plik przygotowywany raz do raportowania. Jego wartość zależy od aktualności danych o funkcjach, umowach i dostawcach. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

Ręczne scalanie arkuszy z zakupów, IT i compliance zwiększa ryzyko braków i sprzeczności. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

• Zdefiniuj jedno źródło danych dla każdej kategorii, identyfikatory umów i usług, kontrolę zmian oraz cykliczne uzgodnienia z właścicielami biznesowymi.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Zmiana nazwy dostawcy po przejęciu nie powinna tworzyć dwóch pozornie niezależnych dostawców w raportach ryzyka.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

DORA a NIS2/KSC i RODO

Podmiot finansowy może jednocześnie podlegać kilku reżimom. Wspólne procesy powinny być projektowane raz, ale z odrębną kwalifikacją obowiązków.

Podmiot finansowy może jednocześnie podlegać kilku reżimom. Wspólne procesy powinny być projektowane raz, ale z odrębną kwalifikacją obowiązków. Samo zapisanie obowiązku w procedurze nie daje jeszcze zgodności. Organizacja powinna potrafić wykazać, kto wykonuje daną czynność, z jaką częstotliwością, na podstawie jakich danych i co dzieje się po wykryciu wyjątku. W małej firmie proces może być prosty i skupiony w kilku rolach; w dużej grupie wymaga zwykle rozdzielenia odpowiedzialności i wspólnego standardu. Proporcjonalność nie oznacza braku kontroli — oznacza kontrolę dopasowaną do skali i ryzyka.

Trzy oddzielne zespoły reagujące na ten sam incydent bez wspólnego źródła faktów generują niespójność komunikacji. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

• Zbuduj centralny incident record i macierz regulacyjną, z której wynikają właściwe ścieżki zgłoszeniowe i terminy.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Wykradzenie bazy klientów przez ransomware może równolegle wymagać analizy DORA, RODO, KSC i zobowiązań kontraktowych.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Audyt dojrzałości DORA w 2026 r.

Po roku stosowania regulacji warto sprawdzić, czy kontrolki rzeczywiście działają, a nie tylko czy dokumenty istnieją.

Po roku stosowania regulacji warto sprawdzić, czy kontrolki rzeczywiście działają, a nie tylko czy dokumenty istnieją. Na poziomie zarządczym warto przełożyć ten problem na mierzalny mechanizm: właściciela, termin, kryterium zakończenia i dowód wykonania. Takie podejście ogranicza sytuacje, w których compliance istnieje wyłącznie w dokumencie, a produkt lub infrastruktura działają według innych zasad. W sporze, audycie albo po incydencie właśnie ta spójność pomiędzy dokumentacją a praktyką ma zasadnicze znaczenie.

Brak testu skuteczności może utrwalać proces, który formalnie wygląda poprawnie, lecz nie zapewnia odporności. W praktyce oznacza to konieczność połączenia analizy prawnej z realnym procesem biznesowym. Dla obszaru „DORA w praktyce 2026” kluczowe jest ustalenie odpowiedzialności, źródła danych i momentu, w którym decyzja wymaga eskalacji. Dopiero na tej podstawie można dobrać dokumenty, kontrolki techniczne i procedury, które rzeczywiście będą używane. Z punktu widzenia dowodowego warto zachować nie tylko finalną politykę, ale także historię decyzji, wyniki przeglądów i działania korygujące.

• Przeprowadź przegląd end-to-end: ryzyko, incydenty, testy, dostawcy, rejestr, umowy, zarząd, działania korygujące i dowody wykonania.
• Zapisz wynik oceny w jednym miejscu i wskaż osobę odpowiedzialną za jego aktualizację po zmianie systemu, dostawcy lub procesu.
• Ustal trigger ponownego przeglądu: incydent, istotna zmiana umowy, nowa kategoria danych, zmiana modelu biznesowego albo wymagania regulatora.

Przykład: Dobry audyt kończy się priorytetyzowaną listą luk z właścicielem, terminem i oceną ryzyka, a nie wyłącznie tabelą zgodności.

Warstwa umowna i dowodowa powinna być analizowana równolegle. Jeżeli obowiązek jest wykonywany przez zewnętrznego dostawcę, organizacja nadal powinna wiedzieć, jakie informacje otrzyma, w jakim czasie i jak zweryfikuje ich jakość. W relacjach wewnętrznych potrzebny jest natomiast jasny podział pomiędzy właścicielem biznesowym, IT, bezpieczeństwem, ochroną danych i compliance. Nie każdy temat wymaga rozbudowanego komitetu, ale każdy istotny proces powinien mieć osobę zdolną podjąć decyzję.

Przy projektowaniu kontroli należy unikać dwóch skrajności. Pierwszą jest formalizm: tworzenie wielu dokumentów bez związku z codzienną pracą. Drugą jest nadmierna improwizacja, w której decyzje nie są odtwarzalne. Dobrze zaprojektowany model pozostawia ślad wystarczający do audytu, ale jednocześnie jest możliwy do wykonania przez zespół w normalnym rytmie pracy.

Checklista dla zarządu i właściciela procesu

1. Potwierdź kwalifikację prawną i zapisz jej uzasadnienie.
2. Zidentyfikuj systemy, dane, dostawców i procesy krytyczne.
3. Przypisz właścicieli obowiązków i punkty eskalacji.
4. Sprawdź umowy, incydenty, dostęp do logów i współpracę z dostawcami.
5. Zbuduj dowody działania: rejestry, testy, protokoły decyzji i działania korygujące.
6. Ustal cykliczny przegląd i triggery ponownej oceny.

Podstawowe źródła prawne i urzędowe

• Rozporządzenie (UE) 2022/2554 (DORA)
• Komisja Nadzoru Finansowego — materiały DORA i incydenty ICT

Przed podjęciem decyzji wdrożeniowej należy sprawdzić aktualne brzmienie przepisów, akty wykonawcze i stanowiska właściwych organów, zwłaszcza gdy harmonogram regulacji jest w toku zmian.

Powiązane obszary

• Umowy IT, SaaS i cloud — praktyczne rozwinięcie powiązanego ryzyka.
• Cyberincydent i ransomware — praktyczne rozwinięcie powiązanego ryzyka.
• NIS2 i KSC 2026 — praktyczne rozwinięcie powiązanego ryzyka.

Powiązane materiały w klastrze

• Zero Trust, NIS2 i DORA — fundament cyberbezpieczeństwa

Najczęstsze pytania