Testy niezależne od producenta jako wymóg prawny: kto, kiedy i co musi udokumentować

„Testy muszą być niezależne od producenta” to zdanie, które w rozmowach z firmami z bankowości, ochrony zdrowia i sektora publicznego pada coraz częściej, ale rzadko z numerem artykułu obok. A numer artykułu ma znaczenie, bo „niezależność” znaczy co innego w rozporządzeniu DORA, co innego w ustawie o krajowym systemie cyberbezpieczeństwa, a jeszcze co innego w Rekomendacji D. W jednym reżimie wystarczy, że tester nie jest tym samym człowiekiem, który napisał kod. W innym potrzebna jest akredytowana jednostka zewnętrzna albo co najmniej dwóch audytorów z certyfikatami. Ten artykuł porządkuje, kto podlega któremu wymogowi, od kiedy, co dokładnie jest wymagane i jakie dokumenty trzeba mieć w ręku, gdy zapyta regulator.

Pięć reżimów, pięć definicji niezależności

Zacznijmy od mapy, bo bez niej łatwo zamówić coś, czego przepis nie wymaga, albo pominąć coś, czego wymaga. W Polsce testy i audyty niezależne od wytwórcy oprogramowania wynikają dziś z pięciu źródeł prawa, z których każde definiuje niezależność na innym poziomie: od rozdziału ról wewnątrz firmy, przez wymóg niezależnej strony wewnętrznej lub zewnętrznej, po obowiązek akredytowanej jednostki z zewnątrz.

Z tej tabeli wynika pierwsza praktyczna rzecz: pytanie „czy testy muszą być niezależne od producenta” nie ma jednej odpowiedzi. Bank podlega jednocześnie DORA i Rekomendacji D, a jeśli jest podmiotem kluczowym, również ustawie o KSC. Szpital publiczny podlega KRI i, jako podmiot kluczowy w sektorze zdrowia, ustawie o KSC, a jeśli sam wytwarza oprogramowanie medyczne, także MDR. Niezależność trzeba więc zamawiać w wersji najsurowszej z tych, które was dotyczą, a nie w wersji najwygodniejszej.

DORA: niezależność zapisana wprost, z datą i częstotliwością

Rozporządzenie o operacyjnej odporności cyfrowej sektora finansowego stosuje się bezpośrednio od 17 stycznia 2025 roku, bez potrzeby polskiej ustawy wdrażającej. Jego artykuł 24 nakłada na podmioty finansowe obowiązek prowadzenia programu testowania operacyjnej odporności cyfrowej i wymaga, żeby testy były przeprowadzane przez niezależne strony, wewnętrzne lub zewnętrzne. Jeśli testuje strona wewnętrzna, podmiot ma zapewnić jej wystarczające zasoby i wykluczyć konflikt interesów. Systemy wspierające funkcje krytyczne testuje się co najmniej raz w roku. Artykuł 25 wymienia, co wchodzi w zakres: oceny podatności, testy scenariuszowe, testy kompatybilności, wydajnościowe, penetracyjne, przeglądy kodu źródłowego i inne.

Osobny, wyższy poziom to testy penetracyjne ukierunkowane przez analizę zagrożeń, czyli TLPT z artykułu 26. Dotyczą podmiotów wskazanych przez organ nadzoru, w Polsce KNF, według kryteriów wpływu na sektor, stabilności finansowej i profilu ryzyka ICT. Przeprowadza się je co najmniej raz na trzy lata, na systemach produkcyjnych. Testerzy wewnętrzni są dopuszczeni tylko pod warunkami, a co najmniej co trzeci test musi wykonać tester zewnętrzny; istotne instytucje kredytowe korzystają wyłącznie z testerów zewnętrznych. Artykuł 27 stawia testerom pięć wymogów: renomę, wiedzę fachową, certyfikat jednostki akredytującej albo przestrzeganie uznanego kodeksu, niezależne zarządzanie ryzykiem testu i pełne ubezpieczenie od odpowiedzialności cywilnej.

Warto zwrócić uwagę na jedno sformułowanie, które w praktyce robi największą różnicę: „niezależne strony, wewnętrzne lub zewnętrzne”. DORA nie każe każdemu bankowi wynajmować firmy zewnętrznej do wszystkich testów. Każe udowodnić, że osoba testująca nie odpowiadała za to, co testuje, i że miała na to zasoby. Bank, który powierza testy regresyjne temu samemu zespołowi, który wdraża zmiany, nie spełnia tego wymogu nawet wtedy, gdy testy są wykonane bardzo dobrze. Bank, który ma osobny zespół QA z własnym budżetem i raportuje poza pion wytwarzania, spełnia go bez wynajmowania kogokolwiek. Zewnętrzny wykonawca staje się konieczny dopiero tam, gdzie przepis mówi o nim wprost, czyli w TLPT, albo tam, gdzie organizacja nie potrafi wykazać niezależności wewnętrznej.

Ustawa o KSC: audyt, który musi wykonać ktoś z zewnątrz lub z papierami

Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa wdrażająca dyrektywę NIS2, opublikowana w Dzienniku Ustaw 2026 pod pozycją 252, obowiązuje od 3 kwietnia 2026 roku i rozszerzyła listę podmiotów objętych obowiązkami daleko poza dawnych operatorów usług kluczowych. Podmioty kluczowe mają obowiązek audytu bezpieczeństwa systemów informacyjnych co najmniej raz na trzy lata, liczone od podpisania raportu z poprzedniego audytu, a pierwszy audyt muszą zamknąć do 3 kwietnia 2028 roku. Raport przekazują organowi w trzy dni robocze od otrzymania. Podmioty ważne audytują na żądanie organu, na przykład po poważnym incydencie.

Tu definicja niezależności jest najbardziej konkretna w całym zestawieniu. Audyt może przeprowadzić akredytowana przez Polskie Centrum Akredytacji jednostka oceniająca zgodność, sektorowy zespół CSIRT albo co najmniej dwóch audytorów z certyfikatami wymienionymi w rozporządzeniu ministra lub z co najmniej trzyletnią praktyką w audycie bezpieczeństwa systemów informacyjnych. Do tego dochodzi wyłączenie: audytu nie może prowadzić osoba, która w roku poprzedzającym realizowała w tym podmiocie zadania z zakresu cyberbezpieczeństwa. Innymi słowy, własny dział bezpieczeństwa nie zaudytuje sam siebie, a wykonawca, który rok wcześniej wdrażał w firmie system SIEM, nie zaudytuje własnego wdrożenia. Sankcje dla podmiotu kluczowego sięgają 10 mln euro albo 2 procent przychodów, a kierownik podmiotu odpowiada osobiście.

Rekomendacja D i KRI: niezależność jako rozdział ról

Rekomendacja D Komisji Nadzoru Finansowego z 2013 roku, wciąż obowiązująca banki, nie mówi o zewnętrznych testerach. Mówi o czymś starszego typu, ale równie wiążącego: o rozdziale funkcji. Punkt 5.2 wymaga oddzielenia tworzenia lub modyfikowania systemów od ich testowania, poza testami wykonywanymi przez programistów w ramach wytwarzania, a także od administracji i użytkowania. Sekcja siódma wymaga metodyki testowania zapewniającej możliwie wysoki stopień niezależności weryfikacji, z planowaniem, kryteriami odbioru, scenariuszami i raportowaniem. Bank, który tego nie ma, nie łamie przepisu o zewnętrznych testach, tylko rekomendację nadzoru, co przy kontroli KNF wychodzi na to samo.

Rozporządzenie o Krajowych Ramach Interoperacyjności obejmuje z kolei każdy podmiot publiczny i wymaga w §20 ust. 2 pkt 14 okresowego audytu wewnętrznego bezpieczeństwa informacji nie rzadziej niż raz na rok. Słowo „wewnętrzny” bywa mylące: chodzi o audyt na wewnętrzne potrzeby kierownika jednostki, nie o zakaz zlecania go na zewnątrz. W praktyce większość urzędów i szpitali zleca go zewnętrznym audytorom, bo nie ma własnych, a organ przy kontroli i tak pyta o to, kto audytował i czy oceniał własną pracę.

Co trzeba mieć w ręku, gdy zapyta regulator

Wspólny mianownik wszystkich pięciu reżimów jest jeden: przepis nie sprawdza, czy testy się odbyły, tylko czy da się to wykazać. Poniżej siedem dokumentów, których brak widzimy najczęściej, gdy firma przychodzi do nas po kontroli albo tuż przed nią. Żaden z nich nie jest egzotyczny. Wszystkie razem rzadko istnieją w jednym miejscu.

Źródło: opracowanie własne Quality Island na podstawie DORA art. 24 do 27, ustawy o KSC art. 15, Rekomendacji D i rozporządzenia KRI.

Dokument drugi jest tym, o który pyta kontroler najczęściej i który firmy mają najrzadziej. Pisaliśmy o tym w artykule o tym, co naprawdę sprawdza kontroler, zanim podpiszecie umowę na audyt niezależny: nie interesuje go, jak dobry jest wykonawca, tylko czy da się wykazać, że nie oceniał własnej pracy. To samo pytanie, w wersji dotyczącej bezpieczeństwa, wraca w rachunku, ile kosztuje luka bezpieczeństwa, której nikt nie szukał, bo w sektorze regulowanym do kosztu incydentu dochodzi koszt wykazania, że szukano.

Medycyna: niezależność jest, ale piętro wyżej

Sektor medyczny jest w tym zestawieniu przypadkiem szczególnym i warto go nazwać uczciwie. Rozporządzenie MDR w załączniku I pkt 17.2 wymaga, żeby oprogramowanie w wyrobie medycznym było projektowane i wytwarzane zgodnie ze stanem wiedzy, z uwzględnieniem cyklu życia, zarządzania ryzykiem oraz weryfikacji i walidacji, co w praktyce oznacza normę IEC 62304. MDR nie mówi jednak, że testy musi wykonać ktoś niezależny od wytwórcy. Niezależność wchodzi piętro wyżej: przy ocenie zgodności przez jednostkę notyfikowaną dla wyrobów wyższych klas ryzyka, która sprawdza dokumentację techniczną, w tym dowody weryfikacji i walidacji.

Dla wytwórcy oprogramowania medycznego znaczy to tyle, że dokumentacja testowa i odbiorcza jest tu produktem samym w sobie, bo to ją ocenia jednostka notyfikowana, a nie sam proces. Niezależny zespół testowy nie jest w MDR wymogiem, ale jest najkrótszą drogą do dokumentacji, która przechodzi ocenę bez uwag, bo zespół, który nie pisał kodu, dokumentuje to, co widzi, a nie to, co zamierzał zrobić.

Nasza perspektywa

W Quality Island testy niezależne od producenta oprogramowania są osobną linią usług, adresowaną wprost do firm, dla których to wymóg, nie wybór. Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji, przeprowadziliśmy audyt procesów QA i szkolenia zespołów. Dla ChaosGears z branży medycznej zbudowaliśmy dokumentację testową i odbiorczą oraz procesy automatyzacji testów, a następnie zrealizowaliśmy procedury odbiorcze. Z obu tych projektów wynoszą się te same trzy wnioski.

Pierwszy: firmy najczęściej mylą dwa różne zamówienia. Jedno to test niezależny, czyli sprawdzenie produktu przez kogoś, kto go nie budował. Drugie to audyt niezależności, czyli sprawdzenie, czy organizacja potrafi wykazać rozdział ról we własnym procesie. DORA i Rekomendacja D pytają głównie o to drugie. Zewnętrzny wykonawca testów regresyjnych nie zastąpi braku rozdziału ról wewnątrz banku, bo kontroler zapyta, kto testuje zmiany między wizytami tego wykonawcy.

Drugi: w sektorze regulowanym obiekcja „nasze oprogramowanie jest zbyt specyficzne dla zewnętrznego zespołu” działa odwrotnie niż w sektorze prywatnym. Im bardziej specyficzny system, tym cenniejszy jest dowód, że sprawdził go ktoś, kto nie zna jego historycznych kompromisów i nie ma powodu ich bronić. Na blogu Quality Island opisaliśmy, dlaczego „zbyt specyficzne oprogramowanie” to obiekcja, nie fakt, i w kontekście regulatora ta obiekcja jest wręcz argumentem za niezależnością.

Trzeci: terminy w tych przepisach liczą się od daty na raporcie, nie od daty testu. Trzy lata w KSC biegną od podpisania raportu z ostatniego audytu, roczny cykl w DORA rozlicza się w programie testów, a KRI pyta o audyt w każdym roku kalendarzowym. Firma, która ma testy, ale nie ma podpisanego i datowanego raportu, w oczach organu nie ma testów. Dlatego przy każdym zleceniu w sektorze regulowanym raport jest produktem końcowym, a nie załącznikiem, i tak go traktujemy od pierwszego dnia projektu.

Powiązane na Strefie QA

• Audyt niezależny od producenta: co naprawdę sprawdza kontroler, zanim podpiszecie umowę
• Ile kosztuje luka bezpieczeństwa, której nikt nie szukał
• Jak testować zgodność z RODO, nie blokując całego developmentu

Źródła:

• Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), EUR-Lex
• Ustawa z 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa, ISAP, z późniejszymi zmianami
• Komisja Nadzoru Finansowego, Rekomendacja D dotycząca zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach
• Rozporządzenie w sprawie Krajowych Ram Interoperacyjności, tekst jednolity Dz.U. 2017 poz. 2247, ISAP
• Rozporządzenie (UE) 2017/745 w sprawie wyrobów medycznych (MDR), EUR-Lex