Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie

Od 17 stycznia 2025 roku banki, ubezpieczyciele, domy maklerskie i instytucje płatnicze w całej Unii mają obowiązek, który wcześniej był dobrą praktyką: raz w roku sprawdzić, czy ich systemy przetrwają awarię i atak. Nie własnym przekonaniem, tylko testem. I nie dowolnym testem, tylko takim, który przeprowadziła strona niezależna.

Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z 14 grudnia 2022 roku, znane jako DORA, w artykule 24 mówi to wprost. Program testowania operacyjnej odporności cyfrowej obejmuje wszystkie podmioty finansowe poza mikroprzedsiębiorstwami. Testy mają objąć wszystkie systemy teleinformatyczne wspierające funkcje krytyczne, co najmniej raz w roku. A prowadzić je mają strony niezależne, wewnętrzne albo zewnętrzne, przy czym zespół wewnętrzny musi mieć wystarczające zasoby i unikać konfliktu interesów.

To ostatnie zdanie jest w praktyce najtrudniejsze. Zaraz do niego wrócimy.

Kogo to dotyczy i od kiedy

DORA obowiązuje bezpośrednio, bez wdrożenia do prawa krajowego, i jest stosowana od 17 stycznia 2025 roku. Materiały dla rynku publikuje Komisja Nadzoru Finansowego. Obejmuje podmioty finansowe działające w Unii oraz zewnętrznych dostawców usług teleinformatycznych, którzy je obsługują.

Jeżeli budujecie albo utrzymujecie oprogramowanie dla banku, ubezpieczyciela lub instytucji płatniczej, ten obowiązek dotyczy Was pośrednio, przez umowę z klientem. To dlatego zapytania o testy zaczęły w ostatnim roku brzmieć inaczej: mniej „potrzebujemy przetestować aplikację”, więcej „potrzebujemy testów, które przejdą audyt”.

Co DORA rozumie przez niezależność

Tu jest miejsce na najczęstsze nieporozumienie. DORA nie zakazuje testów wewnętrznych. Artykuł 24 dopuszcza je wprost, stawiając dwa warunki: zespół musi mieć wystarczające zasoby i musi unikać konfliktu interesów.

Konflikt interesów w testowaniu oprogramowania ma bardzo konkretną postać. Powstaje wtedy, gdy ta sama osoba, ten sam zespół albo ta sama firma odpowiada jednocześnie za dostarczenie systemu i za orzeczenie, czy system jest gotowy. Nie chodzi o złą wolę. Chodzi o to, że nikt nie jest dobrym sędzią własnej pracy pod presją terminu wydania.

W praktyce oznacza to trzy pytania, które audytor zada Waszemu procesowi:

• Kto podejmuje decyzję o wydaniu wersji? Jeżeli osoba odpowiedzialna za testy podlega osobie odpowiedzialnej za termin, niezależność jest formalna, nie faktyczna
• Czy istnieje ślad audytowy? Zakres testów, wyniki, defekty, decyzje o akceptacji ryzyka. Bez tego nie da się wykazać, że test w ogóle się odbył w opisanym zakresie
• Czy testujący ma powiązanie z producentem? Kapitałowe, osobowe, kontraktowe. To pytanie pada zawsze, gdy testy wykonuje podmiot z tej samej grupy co dostawca oprogramowania

Kiedy zespół wewnętrzny przestaje wystarczać

Dla większości podmiotów program testowania z artykułu 24 można zrealizować własnym zespołem, jeśli spełnia powyższe warunki. Ale DORA przewiduje też drugi, ostrzejszy reżim.

Artykuły 26 i 27 wprowadzają testy penetracyjne ukierunkowane na zagrożenia, w skrócie TLPT. Dotyczą podmiotów wyznaczonych przez organ nadzoru i wykonuje się je na systemach produkcyjnych, według scenariuszy realnego ataku. Tam wymogi są wyraźnie twardsze:

• testerzy wewnętrzni są dopuszczalni tylko za zgodą nadzoru i przy braku konfliktu interesów
• obowiązuje naprzemienność: co trzeci test musi wykonać zespół zewnętrzny
• dostawca informacji o zagrożeniach musi być zawsze zewnętrzny wobec badanego podmiotu
• testerzy muszą wykazać kompetencje, certyfikaty, niezależne poświadczenie i ubezpieczenie odpowiedzialności zawodowej

Warto rozróżniać te dwa reżimy, bo w rozmowach handlowych bywają mylone. TLPT to specjalistyczny red teaming, osobna dyscyplina. Program testowania z artykułu 24 to codzienna praca zapewnienia jakości: testy funkcjonalne, regresyjne, wydajnościowe, bezpieczeństwa i dostępności, prowadzone systematycznie i udokumentowane tak, żeby dało się je pokazać kontrolerowi.

My działamy w tym drugim obszarze i mówimy to wprost, zamiast sprzedawać jedno pod drugie.

Co konkretnie obejmuje program testowania

DORA nie podaje listy narzędzi ani nazw technologii, i słusznie, bo te zmieniają się szybciej niż prawo. Mówi o programie testowania opartym na ryzyku, obejmującym wszystkie systemy wspierające funkcje krytyczne. W praktyce taki program składa się z warstw, które trzeba pokryć osobno, bo każda odpowiada na inne pytanie.

Testy funkcjonalne odpowiadają na pytanie, czy system robi to, co ma robić. To warstwa najlepiej pokryta w większości organizacji, bo wynika wprost z wymagań biznesowych. Jej słabym punktem bywa nie zakres, tylko dokumentacja: testy się odbywają, ale nie da się później wykazać, co dokładnie sprawdzono przed konkretnym wydaniem.

Testy regresyjne odpowiadają na pytanie, czy nowa zmiana nie zepsuła czegoś, co działało. W systemach finansowych to warstwa krytyczna, bo zmiany wchodzą często, a zależności między modułami są gęste. Tutaj najczęściej spotykamy ten sam problem: regresja jest tak długa, że przestaje mieścić się w oknie wydania, więc po cichu skraca się jej zakres. Skrócenie regresji z pięciu dni do dziesięciu godzin, o którym pisaliśmy wyżej, nie polegało na testowaniu mniej, tylko na automatyzacji tego, co dotąd klikano ręcznie.

Testy wydajnościowe odpowiadają na pytanie, co się stanie przy obciążeniu, którego nie było w piątek. Sezonowość w finansach jest przewidywalna: koniec miesiąca, koniec roku podatkowego, dni wypłat. Test, który przechodzi przy typowym ruchu, nie mówi nic o zachowaniu systemu przy trzykrotnym szczycie.

Testy bezpieczeństwa odpowiadają na pytanie, czy da się wejść tam, gdzie nie wolno. To warstwa, w której najłatwiej pomylić poziomy: skanowanie podatności, testy penetracyjne i pełny red teaming to trzy różne rzeczy o trzech różnych kosztach. Rozporządzenie wymaga podejścia opartego na ryzyku, więc nie każdy system potrzebuje najwyższego poziomu.

Testy dostępności cyfrowej odpowiadają na pytanie, czy z systemu skorzysta osoba z niepełnosprawnością. W sektorze publicznym i w usługach finansowych dla klientów detalicznych to obowiązek wynikający z osobnych przepisów, nie z DORA, ale w praktyce wchodzi do tego samego programu testowania, bo dotyczy tych samych systemów.

Program, który pokrywa tylko pierwszą warstwę, formalnie istnieje, ale przy pierwszym pytaniu kontrolera o odporność na obciążenie albo o podatności okaże się niepełny.

Dlaczego to nie jest tylko papier

Łatwo potraktować wymóg niezależności jako formalność do odhaczenia. Praktyka pokazuje coś innego.

Zespół, który przez dwa lata rozwija ten sam system, przestaje widzieć jego słabe punkty. Nie dlatego, że jest słaby, tylko dlatego, że zna go od środka i testuje ścieżki, którymi sam chodzi. Zewnętrzny tester zaczyna od pytania, którego nikt wewnątrz już nie zadaje: co się stanie, jeśli użytkownik zrobi to inaczej.

W jednym z naszych projektów w e-commerce uporządkowanie procesów QA i automatyzacja testów obniżyły liczbę błędów krytycznych na produkcji o 46 procent, a regresję przed wydaniem skróciły z pięciu dni do dziesięciu godzin. W projekcie z branży car rental redukcja błędów krytycznych w procesach rezerwacji wyniosła 55 procent, a system wytrzymał obciążenie większe o 120 procent w szczycie sezonu. To nie są liczby z audytu zgodności. To są liczby z eksploatacji, i one interesują zarząd bardziej niż zaświadczenie.

Pięć braków, które znajdujemy najczęściej

Po kilkudziesięciu audytach procesów QA powtarzalność jest uderzająca. Poniższe braki nie wynikają z niekompetencji zespołów, tylko z tego, że nikt wcześniej nie musiał ich wykazywać.

Pierwszy: testy są, dokumentacji nie ma. Zespół testuje sumiennie, ale wynik żyje w komunikatorze, w komentarzu do zgłoszenia albo w głowie testera. Gdy pada pytanie, co sprawdzono przed wersją sprzed pół roku, nie ma jak odpowiedzieć. To najczęstszy pojedynczy brak i zarazem najtańszy do naprawienia, bo nie wymaga zmiany sposobu testowania, tylko zapisywania.

Drugi: kryteria wydania nie są zapisane. Decyzja o wydaniu wersji zapada na spotkaniu, na podstawie ogólnego wrażenia, że „wygląda dobrze”. Bez zapisanych kryteriów nie da się wykazać, że decyzja była oparta na wyniku testów, a nie na terminie.

Trzeci: pokrycie testami liczone tam, gdzie łatwo, a nie tam, gdzie ryzyko. Wysokie pokrycie modułu, który rzadko się zmienia i nie obsługuje pieniędzy, obok znikomego pokrycia procesu płatności. Podejście oparte na ryzyku, którego wymaga rozporządzenie, oznacza dokładnie odwrotną kolejność.

Czwarty: automatyzacja, której nikt nie utrzymuje. Zestaw testów automatycznych napisany dwa lata temu, dziś czerwony w dwudziestu procentach, więc zespół nauczył się ignorować wyniki. Taki zestaw jest gorszy niż jego brak, bo daje złudzenie pokrycia.

Piąty: brak rozdziału ról. Ta sama osoba pisze kod, testuje go i akceptuje wynik. W małym zespole to zrozumiałe, ale przy wymogu niezależności trzeba przynajmniej rozdzielić akceptację od wykonania.

Jak wygląda rok w programie testowania

Wymóg mówi o testach co najmniej raz w roku, co bywa czytane jako „raz w roku wystarczy”. W praktyce roczny cykl wygląda inaczej i rozkłada się na cały rok, bo testy odporności są tylko jednym z jego elementów.

Testy funkcjonalne i regresyjne idą przy każdym wydaniu, więc ich rytm wyznacza rytm wydań, nie kalendarz regulacyjny. Testy wydajnościowe warto planować przed przewidywalnymi szczytami, a nie po nich. Przegląd całości, ten, który odpowiada wymogowi z artykułu 24, wykonuje się cyklicznie i to on kończy się raportem, który przedstawia się w razie kontroli.

Praktyczna wskazówka z naszych projektów: pierwszy taki przegląd trwa dłużej niż kolejne, bo zwykle obejmuje uporządkowanie dokumentacji, której wcześniej nie było. Drugi rok jest znacznie tańszy, o ile w międzyczasie utrzymano zapisy.

Jak wygląda audyt niezależny w praktyce

Opisujemy to konkretnie, bo najczęstsze pytanie przy pierwszej rozmowie brzmi: ile to trwa i co dostanę na koniec.

Zakres. Przeglądamy procesy zapewnienia jakości w ramach audytu QA, dokumentację testową, pokrycie testami, stan automatyzacji, kryteria wydania wersji oraz sposób zarządzania defektami i ryzykiem. Osobno oceniamy, czy ślad audytowy jest wystarczający, żeby wykazać wykonanie testów wobec kontrolera.

Czas. Dla pojedynczego systemu dwa do czterech tygodni, zależnie od liczby zespołów i skali dokumentacji.

Co dostajecie. Raport z ustaleniami uporządkowanymi według wpływu, wskazaniem, które braki blokują zgodność, a które są usprawnieniem, oraz plan naprawy z kolejnością prac. Nie listę uwag, tylko kolejność, w jakiej je zamykać.

Czego nie robimy. Nie wydajemy zaświadczeń o zgodności z DORA ani z żadną inną regulacją, bo takich zaświadczeń nie wydaje wykonawca testów. Nie doradzamy prawnie. Zakres obowiązków Waszego podmiotu potwierdza dział compliance albo kancelaria, a my odpowiadamy za to, żeby testy były wykonane porządnie i udokumentowane w sposób, który da się przedstawić.

Dlaczego niezależność zewnętrzna bywa tańsza niż własny zespół

Argument, który pada rzadko, a jest policzalny. Utrzymanie zespołu testerów z kompetencjami pokrywającymi testy funkcjonalne, wydajnościowe, bezpieczeństwa i dostępności oznacza kilka etatów, które przez większość roku nie są w pełni wykorzystane. Testy odporności z artykułu 24 wykonuje się cyklicznie, a nie codziennie.

Dla części organizacji odpowiedzią jest model mieszany: zespół wewnętrzny prowadzi testy bieżące, a niezależny podmiot wykonuje cykliczny audyt i te rodzaje testów, których wewnętrznie nie opłaca się utrzymywać. Taki układ spełnia wymóg niezależności tam, gdzie jest on najostrzejszy, i nie wymaga budowania kompetencji, których będziecie używać cztery razy w roku.

Niezależność a outsourcing: co mówi umowa

Kwestia, która wraca w każdej rozmowie z działem zakupów. Jeżeli oprogramowanie dostarcza firma zewnętrzna i ta sama firma je testuje, to czy testy są niezależne?

Formalnie tester jest wtedy zewnętrzny wobec podmiotu finansowego, ale nie jest niezależny wobec producenta oprogramowania. A wymóg z artykułu 24 mówi o unikaniu konfliktu interesów, nie o miejscu w strukturze organizacyjnej. Konflikt istnieje wtedy, gdy ten sam podmiot ma interes w tym, żeby wynik testu był pozytywny, bo od tego zależy odbiór jego własnej pracy.

To nie znaczy, że dostawca nie ma testować tego, co buduje. Ma i powinien, bo testy wykonawcze są częścią wytwarzania. Znaczy natomiast, że testy odbiorcze i przegląd cykliczny warto powierzyć komuś, kto nie odpowiada za termin dostawy ani za budżet projektu wdrożeniowego.

W praktyce widzimy trzy układy. Pierwszy: podmiot finansowy zleca testy niezależne bezpośrednio, obok umowy z dostawcą. Drugi: wymóg testów niezależnych wpisuje się do umowy z dostawcą, a on podzleca je podmiotowi bez powiązań z nim. Trzeci, najsłabszy: testy odbiorcze wykonuje dostawca, a podmiot finansowy tylko je akceptuje. Trzeci układ przechodzi audyt tylko wtedy, gdy da się wykazać, że akceptujący miał realną możliwość weryfikacji, a nie tylko podpisał protokół.

Co się dzieje, gdy testów zabraknie

Rozporządzenie przewiduje sankcje, ale w rozmowach z zarządami zwykle nie one są argumentem, który przekonuje. Przekonuje coś innego.

Awaria systemu płatniczego albo bankowości elektronicznej ma trzy koszty, i tylko jeden z nich jest karą regulacyjną. Drugi to koszt operacyjny: godziny pracy zespołów, wstrzymane transakcje, obsługa zgłoszeń klientów. Trzeci, najtrudniejszy do odzyskania, to zaufanie. Klient, który nie mógł zapłacić w piątek wieczorem, pamięta to dłużej niż komunikat z przeprosinami.

Program testowania nie eliminuje awarii, bo nic ich nie eliminuje. Zmniejsza natomiast liczbę tych, które można było przewidzieć. W projektach, które prowadziliśmy, spadek liczby błędów krytycznych na produkcji o 46 i 55 procent nie wziął się z nowego narzędzia, tylko z uporządkowania tego, co i kiedy jest sprawdzane przed wydaniem.

Trzy pytania do dostawcy testów niezależnych

Jeżeli wybieracie podmiot do wykonania takich testów, poniższe pytania oddzielają dostawców, którzy rozumieją reżim regulacyjny, od tych, którzy sprzedają testowanie jako usługę ogólną.

Czy macie powiązania z producentem naszego oprogramowania? Kapitałowe, osobowe, partnerskie. Odpowiedź „nie” powinna dać się zweryfikować, a nie tylko usłyszeć.

Jaki ślad audytowy zostaje po Waszej pracy? Dobra odpowiedź opisuje konkretne dokumenty: plan testów, przypadki, wyniki, rejestr defektów, raport końcowy z decyzjami o ryzyku. Zła odpowiedź mówi o „pełnej dokumentacji” bez wymienienia, z czego się składa.

Co zrobicie, jeśli wynik będzie niekorzystny dla naszego terminu wydania? To pytanie o niezależność w praktyce. Dostawca, który obiecuje, że „znajdzie sposób”, żeby zdążyć, nie jest niezależny, tylko elastyczny wobec presji, a to dokładnie to, co wymóg ma wykluczyć.

Z kim pracowaliśmy w sektorze regulowanym

Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji, przeprowadziliśmy audyt istniejących procesów QA oraz szkolenia i warsztaty dla zespołów. W obszarze finansowym pracowaliśmy też z Pekao SA, Santanderem, BNP Paribas, XTB, StoneX i Match Trade Technologies. W sektorze publicznym i zdrowiu z NFZ, Ministerstwem Cyfryzacji, Głównym Urzędem Miar, PSE, PGE i Luxmedem. Dla firmy z branży medycznej zbudowaliśmy dokumentację testową i odbiorczą oraz wdrożyliśmy procesy automatyzacji testów.

Łącznie z naszych usług i szkoleń skorzystało ponad 100 firm. Zrealizowaliśmy ponad 152 projekty i napisaliśmy ponad 450 000 testów automatycznych. Zespół ma certyfikaty ISTQB, a firma jest akredytowanym dostawcą szkoleń ISTQB.

Od czego zacząć, jeśli nie wiecie, gdzie stoicie

Najtańszy pierwszy krok to nie zamówienie testów, tylko sprawdzenie, czy to, co już robicie, da się wykazać. Trzy pytania, które możecie zadać sobie sami jeszcze dziś:

• Czy potraficie wskazać dokument opisujący zakres testów wykonanych przed ostatnim wydaniem wersji produkcyjnej?
• Czy osoba, która akceptuje wynik testów, jest niezależna od osoby odpowiedzialnej za termin wydania?
• Czy wiecie, które z Waszych systemów wspierają funkcje krytyczne w rozumieniu DORA, i czy każdy z nich był testowany w ciągu ostatnich dwunastu miesięcy?

Jeżeli przy którymkolwiek pytaniu odpowiedź brzmi „chyba tak”, to jest dokładnie ten obszar, od którego zaczyna się audyt.

Jeżeli chcecie sprawdzić, czy Wasz program testowania obroni się przed kontrolą, zacznijmy od audytu procesów QA. Dwa do czterech tygodni, raport z ustaleniami według wpływu i plan naprawy z kolejnością prac. Napiszcie do nas, a odezwiemy się z propozycją zakresu.

Powiązane na blogu Quality Island

• Ustawa o dostępności: kto musi, jakie kary, od kiedy
• Zamówienia publiczne na testy: ścieżka zakupowa, o której nikt nie pisze
• Audyt QA dla firm: co obejmuje, ile trwa i co dostajecie

Pełna lista źródeł

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z 14 grudnia 2022 r., tekst na EUR-Lex
• Komisja Nadzoru Finansowego, materiały dla rynku o DORA
• Artykuł 24 DORA, program testowania operacyjnej odporności cyfrowej: zakres podmiotowy, częstotliwość i wymóg niezależności testujących
• Artykuły 26 i 27 DORA, testy penetracyjne ukierunkowane na zagrożenia: rotacja testerów i wymogi wobec dostawcy informacji o zagrożeniach
• Rozporządzenie delegowane Komisji (UE) 2025/1190, kryteria wyboru testerów TLPT
• Dane własne Quality Island z projektów dla klientów z e-commerce i branży car rental

Ten tekst opisuje wymogi rozporządzenia (UE) 2022/2554 w zakresie testowania i nie stanowi porady prawnej. Zakres obowiązków konkretnego podmiotu wynika z jego statusu regulacyjnego i powinien być potwierdzony przez dział compliance lub doradcę prawnego.