Zgodność regulacyjna sprowadza się w praktyce do jednego zdania, które powtarza się w czterech różnych aktach prawnych, każdym z własnym terminem: system trzeba przetestować i trzeba umieć wykazać, że test się odbył. To nie jest już kwestia dobrych praktyk, tylko obowiązku, którego niedopełnienie widać przy pierwszej kontroli.
Pomagamy organizacjom pod presją regulacyjną przejść od stanu „testujemy, ale nie wiemy, czy to wystarczy” do stanu, w którym zakres, wyniki i decyzje da się przedstawić kontrolerowi bez przygotowywania czegokolwiek na ostatnią chwilę.
Co obejmuje testowanie pod wymogi regulacyjne?
Zgodność regulacyjna zmienia zakres pracy w porównaniu ze zwykłym projektem testowym, bo poza samym testowaniem liczy się to, czy da się je wykazać. Obejmujemy siedem obszarów:
Dlaczego zgodność regulacyjna jest kwestią testowania, a nie tylko dokumentów
Najczęstsze nieporozumienie brzmi tak: skoro to obowiązek prawny, to załatwi go dział compliance albo kancelaria. Prawnik ustali, co Was obejmuje, i to jest jego rola. Ale żaden przepis nie da się spełnić dokumentem opisującym testy, których nie było.
Rozporządzenie DORA w artykule 24 mówi o programie testowania obejmującym wszystkie systemy wspierające funkcje krytyczne, co najmniej raz w roku, prowadzonym przez strony niezależne. To jest wymóg techniczny, nie formalny. Podobnie AI Act, który przy systemach wysokiego ryzyka wymaga zarządzania ryzykiem i dokumentacji technicznej opartej na rzeczywistym zachowaniu systemu, a nie na deklaracji dostawcy.
Praktyczny skutek jest taki, że zgodność regulacyjna buduje się przez rok, w rytmie wydań, a nie w miesiącu przed kontrolą.
Czy dotyczy Was któryś z tych problemów?
Jeżeli przy którymkolwiek punkcie odpowiedź brzmi „chyba tak”, to jest dokładnie ten obszar, od którego zaczynamy.
Cztery reżimy, cztery różne zakresy pracy
DORA: operacyjna odporność cyfrowa sektora finansowego
Rozporządzenie (UE) 2022/2554 jest stosowane od 17 stycznia 2025 roku, bezpośrednio, bez wdrożenia do prawa krajowego. Artykuł 24 obejmuje wszystkie podmioty finansowe poza mikroprzedsiębiorstwami i wymaga testów co najmniej raz w roku, prowadzonych przez strony niezależne, przy czym zespół wewnętrzny jest dopuszczalny, jeśli ma zasoby i unika konfliktu interesów.
Co robimy: audyt programu testowania, wykonanie testów w zakresie wynikającym z ryzyka, uporządkowanie śladu audytowego, przegląd cykliczny w kolejnych latach.
Czego nie robimy: testów penetracyjnych ukierunkowanych na zagrożenia z artykułów 26 i 27, czyli TLPT. To osobna dyscyplina i mówimy to wprost, zamiast sprzedawać jedno pod drugie.
AI Act: systemy sztucznej inteligencji wysokiego ryzyka
Obowiązki rozporządzenia (UE) 2024/1689 dotyczą dostawców systemów zaklasyfikowanych jako wysokiego ryzyka i obejmują między innymi zarządzanie ryzykiem, jakość danych, dokumentację techniczną i nadzór człowieka. Wchodzą etapami, a klasyfikacja systemu decyduje o tym, które z nich Was dotyczą.
Co robimy: testowanie systemów opartych na modelach, sprawdzanie zachowania przy danych brzegowych i nietypowych, weryfikacja powtarzalności wyników, testy scenariuszy, w których model się myli, dokumentacja testowa pod wymogi dowodowe.
Czego nie robimy: nie klasyfikujemy Waszego systemu jako wysokiego ryzyka. To ustalenie prawne.
Cyber Resilience Act: produkty z elementami cyfrowymi
CRA obejmuje produkty z elementami cyfrowymi wprowadzane na rynek Unii i przenosi ciężar z jednorazowej certyfikacji na obowiązki utrzymywane przez cały cykl życia produktu, w tym obsługę podatności i aktualizacje bezpieczeństwa.
Co robimy: testy bezpieczeństwa, weryfikacja procesu obsługi podatności, sprawdzenie, czy proces aktualizacji faktycznie działa, dokumentacja wykazująca ciągłość tych działań.
Dostępność cyfrowa: WCAG 2.2 i ustawa
Wymóg wynika z osobnych przepisów niż trzy powyższe, a dotyczy tych samych systemów i wchodzi do tego samego programu testowania. Obejmuje sektor publiczny oraz część usług kierowanych do konsumentów.
Co robimy: audyt zgodności ze standardem WCAG 2.2, testy z czytnikami ekranu i nawigacją klawiaturą, raport z listą niezgodności uporządkowaną według wpływu na użytkownika.
Dlaczego warto zrobić to z Quality Island?
Jesteśmy niezależni od producentów oprogramowania. Nie budujemy systemów, które potem testujemy, więc nie mamy interesu w tym, żeby wynik testu był pozytywny. Przy wymogu niezależności to nie jest deklaracja, tylko warunek, który da się zweryfikować.
Pracowaliśmy w sektorze regulowanym z podmiotami, które przechodzą kontrole regularnie. Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji, przeprowadziliśmy audyt procesów QA oraz szkolenia dla zespołów. W finansach pracowaliśmy też z Pekao SA, Santanderem, BNP Paribas, XTB, StoneX i Match Trade Technologies, a w sektorze publicznym i ochronie zdrowia z NFZ, Ministerstwem Cyfryzacji, Głównym Urzędem Miar, PSE, PGE, Orlenem i Luxmedem.
Mówimy, czego nie robimy. Nie wydajemy zaświadczeń o zgodności, bo takich nie wydaje wykonawca testów. Nie doradzamy prawnie. Nie świadczymy TLPT. Ta lista jest krótsza niż lista tego, co robimy, ale bez niej trudno o rzetelną rozmowę.
Zostawiamy po sobie dokumentację, a nie prezentację. Raport z ustaleniami według wpływu, plan naprawy z kolejnością prac i ślad audytowy, który da się przedstawić.
Jak działamy?
Co zyskujecie?
| Obszar | Stan przed | Stan po |
|---|---|---|
| Dowód wykonania testów | wynik żyje w komunikatorze i w głowie testera | ślad audytowy, który da się przedstawić |
| Decyzja o wydaniu | podejmowana na podstawie wrażenia i terminu | zapisane kryteria, niezależna akceptacja |
| Zakres testów | tam, gdzie łatwo testować | tam, gdzie jest ryzyko |
| Przygotowanie do kontroli | miesiąc pracy przed audytem | materiał gotowy przez cały rok |
| Rozmowa z klientem regulowanym | „testujemy”, bez konkretów | opisany zakres, częstotliwość i niezależność |
Jakich rezultatów możecie się spodziewać?
Zgodność regulacyjna sama w sobie jest trudna do zmierzenia, bo jej efektem jest brak problemu. Ale praca, która do niej prowadzi, daje efekty widoczne w eksploatacji, i te potrafimy pokazać liczbami z naszych projektów.
Do tego dochodzi efekt, którego nie da się ująć w procentach: rozmowa z klientem z sektora regulowanego przestaje kończyć się prośbą o „przesłanie czegoś, co potwierdza testy”.
Zgodność regulacyjna a zwykłe testowanie oprogramowania
Różnica nie polega na tym, że testy są inne. Techniki są te same. Różnica jest w tym, co zostaje po testach i kto je wykonał.
Przy zwykłym projekcie wystarczy, że system działa i zespół to wie. Przy wymogu regulacyjnym trzeba dodatkowo umieć wykazać, co sprawdzono, kiedy, w jakim zakresie i na jakiej podstawie uznano wynik za wystarczający. Do tego dochodzi pytanie o niezależność, którego przy zwykłym projekcie nikt nie zadaje.
Dlatego audyt QA jest zwykle pierwszym krokiem, a nie same testy. Bez wiedzy o tym, co już macie, łatwo zapłacić za powtórzenie pracy, która została wykonana i tylko nie została opisana.
Najczęściej zadawane pytania o zgodność regulacyjną
Sprawdzimy, czy Wasz program testowania obroni się przed kontrolą. Audyt stanu, dwa do czterech tygodni, raport z planem naprawy.
Zobacz także
Ta strona opisuje wymogi wymienionych aktów prawnych w zakresie testowania i nie stanowi porady prawnej. Zakres obowiązków konkretnego podmiotu wynika z jego statusu i powinien być potwierdzony przez dział compliance lub doradcę prawnego.