Audyt QA w sektorze regulowanym: co pokazuje case PKO BP

Audyt QA w sektorze regulowanym to przegląd procesów testowania i wydawania oprogramowania, który sprawdza dwie rzeczy naraz. Czy proces jakości działa. I czy potraficie to udowodnić komuś z zewnątrz. W banku drugie pytanie waży tyle samo co pierwsze, bo odpowiedź czyta nie tylko zarząd, ale też nadzorca.

Ten tekst pokazuje, które przepisy stoją za takim audytem, jakie dokumenty audytor poprosi jako pierwsze i ile to kosztuje. Na końcu znajdziecie listę kontrolną artefaktów, którą możecie przejść sami przed pierwszym spotkaniem. Ogólny przebieg audytu, niezależny od branży, opisujemy w osobnym artykule o zakresie, przebiegu i kosztach audytu procesów QA.

Czym audyt QA w sektorze regulowanym różni się od audytu w software housie?

Audyt QA w sektorze regulowanym ma trzeciego odbiorcę, którego software house zwykle nie ma: nadzorcę. W firmie produktowej audyt odpowiada przed zarządem i klientami. W banku dochodzi Komisja Nadzoru Finansowego, która pyta o zarządzanie ryzykiem ICT. Metodyka testowania zostaje ta sama. Zmienia się to, co trzeba umieć pokazać na papierze.

Ta presja ma pokrycie w liczbach. Według raportu ENISA Threat Landscape: Finance Sector z 2025 roku w europejskim sektorze finansowym odnotowano 488 publicznie zgłoszonych incydentów między styczniem 2023 a czerwcem 2024. Według tego samego raportu ENISA 46 procent z nich celowało w banki. Nadzorca ma więc powód, żeby pytać nie tylko, czy testujecie, ale czy umiecie to udokumentować.

Praktyczny skutek jest jeden: audyt w banku sprawdza, czy da się odtworzyć decyzję o wydaniu sprzed pół roku. Kto ją podjął, na jakich wynikach testów i kto mógł ją zablokować. W software housie taki wymóg pojawia się dopiero wtedy, gdy firma sprzedaje do klientów regulowanych. Ten sam wymóg obejmuje modele AI zatrzymujące podejrzane płatności, co rozpisujemy w tekście o tym, jak testować sztuczną inteligencję w bankowości wykrywającą oszustwa.

Które przepisy stoją za audytem QA w instytucji finansowej?

Głównym źródłem wymagań jest dziś rozporządzenie DORA, czyli rozporządzenie (UE) 2022/2554, stosowane od 17 stycznia 2025 roku. Dla QA najważniejszy jest rozdział IV o testowaniu operacyjnej odporności cyfrowej. Art. 24 ust. 1 wymaga programu testowania jako części ram zarządzania ryzykiem ICT. Art. 24 ust. 4 każe, żeby testy prowadziły niezależne strony, wewnętrzne albo zewnętrzne, bez konfliktu interesów.

Kolejne ustępy są jeszcze bliżej codziennej pracy testerów. Art. 24 ust. 5 wymaga procedur klasyfikowania i usuwania wszystkich problemów wykrytych w testach oraz metody potwierdzenia, że luki naprawdę zamknięto. Art. 24 ust. 6 mówi, że systemy wspierające krytyczne lub istotne funkcje testuje się co najmniej raz w roku. Art. 25 ust. 1 wymienia rodzaje testów, w tym testy wydajności, testy kompleksowe, przeglądy kodu i testy penetracyjne.

Podmioty wskazane przez nadzór przechodzą dodatkowo zaawansowane testy TLPT, nie rzadziej niż co trzy lata (art. 26 ust. 1). Drugi filar to zarządzanie zmianą. Art. 9 ust. 4 lit. e DORA wymaga udokumentowanych procedur, które zapewniają rejestrowanie, testowanie, zatwierdzanie i weryfikowanie każdej zmiany w systemach ICT. Rozporządzenie delegowane (UE) 2024/1774 doprecyzowuje to w art. 17 ust. 1 lit. b: funkcja zatwierdzająca zmianę ma być niezależna od tej, która ją zleca i wdraża.

Rekomendacja D Komisji Nadzoru Finansowego jest już historią. KNF uchyliła ją z dniem 17 stycznia 2025 roku uchwałą nr 6/2025, bo jej zakres przejęła DORA. Wiele banków nadal trzyma się jednak jej logiki w procedurach wewnętrznych: oddzielenia tworzenia systemów od ich testowania. Dlatego audytor wciąż pyta o rozdział ról, choć podstawą prawną jest już DORA.

A co z ustawą o krajowym systemie cyberbezpieczeństwa i dyrektywą NIS2? Dla banku DORA działa jako lex specialis. Art. 1 ust. 2 DORA uznaje ją za sektorowy akt prawny w rozumieniu art. 4 dyrektywy NIS2. Art. 4 ust. 1 NIS2 wyłącza wtedy odpowiednie przepisy NIS2, w tym przepisy o nadzorze. Wymogi zarządzania ryzykiem, testów i zgłaszania incydentów bank bierze więc z DORA, a nie z krajowej ustawy o cyberbezpieczeństwie.

Inaczej wygląda sytuacja dostawcy oprogramowania dla banku. Ten zwykle nie podlega DORA bezpośrednio. Wymagania przychodzą do niego przez umowę, bo rozdział V DORA (art. 28 do 30) każe bankowi zarządzać ryzykiem zewnętrznych dostawców usług ICT i spisać prawa oraz obowiązki stron. Dostawca, który sam jest podmiotem kluczowym albo ważnym w innym sektorze, może podlegać przepisom krajowym wdrażającym NIS2. O tym, czego oczekują wtedy klienci, piszemy przy testach bezpieczeństwa dostawców pod NIS2.

Zakres obowiązków konkretnej instytucji zawsze potwierdza jej dział compliance albo prawnik. Różnice między audytem wewnętrznym a niezależnym od producenta rozpisaliśmy w artykule o tym, co naprawdę sprawdza kontroler, zanim podpiszecie umowę na audyt niezależny, na Strefie QA.

Jakie artefakty audytor poprosi jako pierwsze?

Pierwsza prośba audytora to zawsze lista dokumentów. Poniżej dwanaście artefaktów, które w audycie QA w banku sprawdzamy jako pierwsze. Każdy da się przygotować przed startem. Każdy, którego brakuje, wydłuża audyt o czas jego odtwarzania z maili i pamięci zespołu.

W naszej praktyce audytowej najczęściej brakuje punktu piątego. Decyzja o wydaniu zapada na spotkaniu albo na czacie i nikt jej nie zapisuje. Przy kontroli „zwykle tak robimy” nie jest odpowiedzią, którą przyjmie nadzorca. Wystarczy jedno pole w narzędziu do wydań: kto zatwierdził, na podstawie którego raportu testów i z jakimi znanymi ryzykami.

Drugi częsty brak to punkt dziesiąty. Kopia bazy produkcyjnej na środowisku testowym bywa wygodna. Rozporządzenie delegowane 2024/1774 w art. 16 ust. 5 dopuszcza jednak dane produkcyjne poza produkcją tylko w postaci zanonimizowanej, pseudonimizowanej albo randomizowanej. Wyjątek z art. 16 ust. 6 wymaga zatwierdzenia i ograniczenia w czasie.

Co dodatkowo sprawdza audyt QA w instytucji finansowej?

Pięć obszarów z ogólnego audytu QA zostaje: procesy, odpowiedzialności, komunikacja, kryteria release i kontrola ryzyka. W banku dochodzą cztery kolejne, które w zwykłej firmie produktowej rzadko są formalnym punktem audytu.

Żaden z tych czterech obszarów nie zastępuje pięciu ogólnych, tylko je zaostrza. Kryteria release, które w startupie żyją w głowie lidera, w banku muszą być spisane i egzekwowane bez wyjątków. Wyjątek też jest dopuszczalny, ale wtedy ma swój zapis, uzasadnienie i osobę, która go zatwierdziła.

Co pokazuje współpraca z PKO BP?

Dla PKO BP wykonaliśmy trzy rodzaje prac. Opisujemy je wyłącznie zakresem, bo klient nie upublicznił wyników liczbowych, a my ich nie dopisujemy.

Z samego zakresu da się wyczytać jedną praktyczną lekcję: kolejność. Audyt procesów QA, potem strategia jakości oprogramowania dla całej organizacji, potem szkolenia zespołów. Audyt bez decyzji, co dalej, to diagnoza bez leczenia. W organizacji wielkości banku koszt takiej przerwy rośnie z liczbą zespołów, których dotyczy.

Ta kolejność ma też uzasadnienie w samej DORA. Art. 24 ust. 5 wymaga nie tylko wykrycia luk, ale też metody potwierdzenia, że je usunięto. Raport z audytu bez planu wdrożenia i bez właścicieli działań nie spełnia tego warunku. Szkolenia ustawione po audycie trafiają tam, gdzie audyt pokazał lukę, zamiast uczyć wszystkie zespoły tego samego. Przykładem takiego programu jest szkolenie Zarządzanie testami oprogramowania, które dobieramy dla liderów odpowiedzialnych za kryteria release.

Twarde liczby z porządkowania procesów QA mamy z innego sektora. W projekcie dla Argos, e-commerce, automatyzacja testów i uporządkowanie procesów skróciły regresję przed wydaniem z 5 dni do 10 godzin. Ten wynik opisujemy w case study o skracaniu testów regresyjnych. Nie przenosimy go na bank, bo to inna organizacja i inne ograniczenia.

Ile trwa i ile kosztuje audyt w organizacji wielkości banku?

Audyt QA pojedynczego projektu trwa od dwóch do czterech tygodni. W organizacjach wielozespołowych trwa dłużej, bo rośnie liczba wywiadów, a wnioski trzeba zestawić między zespołami. Dopiero wtedy widać, które problemy powtarzają się w kilku miejscach naraz. Tak opisujemy to na stronie usługi audyt QA.

Organizacja wielkości banku prawie zawsze trafia do ostatniego wiersza. Liczba produktów, zespołów i dostawców sprawia, że wycena z cennika byłaby zgadywaniem. Im dokładniej opiszecie liczbę zespołów, systemów krytycznych i dostawców zewnętrznych, tym szybciej dostaniecie realną wycenę zamiast szacunku na najgorszy scenariusz.

Jak przygotować organizację do audytu, żeby go nie wydłużać?

Audyt QA w sektorze regulowanym wydłuża się zwykle nie przez metodykę, tylko przez przygotowanie organizacji. Trzy kroki przed pierwszym wywiadem skracają ten czas, bo audytor nie odtwarza rzeczy, które zespół i tak zna. Dokumentacja testowa przypomina gaśnicę: latami nikt na nią nie patrzy, a potem cały bank chce ją mieć w ręku w tej samej minucie.

• Zbierzcie dokumenty z listy kontrolnej wyżej, nawet niepełne. Audytor poprosi o nie jako pierwsze. Nieaktualna strategia testów jest lepsza niż żadna, bo pokazuje, skąd zaczynacie.
• Wyznaczcie jedną osobę do kalendarza wywiadów. W dużej organizacji wywiady obejmują wiele osób z różnych zespołów. Bez koordynatora ten etap rozciąga się przez samą logistykę spotkań.
• Powiedzcie zespołom wprost, że audyt ocenia proces, nie ludzi. Zespół, który słyszy „kontrola”, odpowiada obronnie. Jedna rozmowa przed startem bywa tańsza niż tydzień wywiadów weryfikacyjnych.

Żaden z tych kroków nie zmniejsza zakresu audytu ani jego rzetelności. Skracają tylko drogę do materiału, który i tak trzeba przejrzeć. To czysta oszczędność, nie kompromis jakości diagnozy.

Czego sektor regulowany uczy firmy bez nadzorcy?

Wymagania DORA brzmią jak biurokracja, dopóki nie spojrzy się na nie jak na listę dobrych praktyk QA. Firma bez nadzorcy nie musi ich spełniać. Skorzysta na nich jednak z trzech powodów.

• Zapis decyzji o wydaniu oszczędza tłumaczenia. Gdy pół roku później klient albo zarząd pyta, dlaczego wersja z błędem poszła na produkcję, odpowiedź jest w jednym miejscu, a nie w pamięci osoby, która już odeszła.
• Niezależna weryfikacja ścieżek krytycznych łapie to, czego autor nie widzi. Zespół, który sam zatwierdza własny kod, prędzej czy później przepuści błąd oczywisty dla osoby z dystansem. Dlatego DORA wymaga niezależności, a nie dlatego, że nie ufa programistom.
• Procesy gotowe na kontrolę otwierają rynek. Firma, która chce sprzedawać do banków, ubezpieczycieli albo sektora publicznego, i tak usłyszy te pytania w umowie. Łatwiej dopisać dokumentację do działającego procesu niż budować proces pod presją terminu przetargu.

Zanim zamówicie audyt, odpowiedzcie sobie na trzy pytania. Czy macie zapis decyzji o wydaniu, czy wiedza o niej siedzi w pamięci konkretnych osób? Czy ścieżki krytyczne dla klienta mają niezależną weryfikację? Czy plan testów obejmuje scenariusze awarii, czy tylko pracę w warunkach normalnych? Odpowiedź „nie wiem” na którekolwiek z nich to dobry moment na rozmowę o audycie, zanim zrobi to za Was kontrola albo incydent.

Powiązane na blogu Quality Island

• Audyt procesów QA: zakres, przebieg, ile to kosztuje
• KPI dla zarządu: jak przełożyć wyniki QA na język CFO
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• „Wasze oprogramowanie jest zbyt specyficzne”: dlaczego to obiekcja, nie fakt

Pogłębiony materiał o tym, po czym poznać, że dostawca oprogramowania stracił kontrolę nad jakością: 10 oznak braku kontroli przez Twojego dostawcę software’u na Strefie QA.

Pełna lista źródeł

• Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 z 14 grudnia 2022 r. (DORA), art. 1 ust. 2, art. 9 ust. 4 lit. e, art. 11 ust. 6, art. 24 ust. 1, 4, 5 i 6, art. 25 ust. 1, art. 26 ust. 1, art. 28 do 30, eur-lex.europa.eu
• Rozporządzenie delegowane Komisji (UE) 2024/1774 z 13 marca 2024 r. (RTS w sprawie ram zarządzania ryzykiem ICT), art. 16 ust. 5 i 6, art. 17 ust. 1, eur-lex.europa.eu
• Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 (NIS2), art. 4 ust. 1, eur-lex.europa.eu
• Komisja Nadzoru Finansowego, Uchwała nr 6/2025 z 10 stycznia 2025 r. uchylająca uchwałę w sprawie wydania Rekomendacji D, Dziennik Urzędowy KNF 2025 poz. 1, dziennikurzedowy.knf.gov.pl
• ENISA, Threat Landscape: Finance Sector, 2025, enisa.europa.eu. Stąd 488 incydentów i udział banków 46 procent
• CISQ, The Cost of Poor Software Quality in the US: A 2022 Report, it-cisq.org. Stąd roczny koszt 2,41 biliona dolarów i osobno skumulowany dług techniczny 1,52 biliona dolarów
• Case study klienta Quality Island, sektor bankowy (PKO BP), zakres prac potwierdzony przez klienta
• Cennik i opis usługi audyt QA, qualityisland.pl, stan na 11 października 2026