Bankowość i płatności
Autoryzacja transakcji
Czy zlecenie zatwierdzone drugim składnikiem da się zmienić przed wykonaniem - kwotę, rachunek odbiorcy - i czy potwierdzenia nie można użyć ponownie.
Testy penetracyjne · Finanse i ubezpieczenia
Testy penetracyjne dla banków i ubezpieczycieli oraz fintechów
Testy penetracyjne dla banków i ubezpieczycieli to testy aplikacji, API, infrastruktury i kodu, które podmiot finansowy włącza do programu testowania operacyjnej odporności cyfrowej z art. 24-25 rozporządzenia (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA). Innovix z Wrocławia oferuje te testy bankom, zakładom ubezpieczeń, instytucjom płatniczym, fintechom i ich dostawcom ICT w całej Polsce - jako zewnętrzny wykonawca, z raportem i retestem, które dokumentują usunięcie problemów. Nie jesteśmy testerem TLPT, ale pomagamy się do TLPT przygotować.
01Dla kogo
Które podmioty finansowe testujemy i co sprawdzamy?
| Podmiot | Typowe systemy | Na co zwracamy uwagę |
|---|---|---|
| Bank | Bankowość internetowa i mobilna, API dla partnerów i agregatorów, aplikacje pracowników oddziałów | Autoryzacja zleceń, dostęp do cudzych rachunków i dokumentów, drugi składnik i odzyskiwanie dostępu |
| Zakład ubezpieczeń | Portal klienta i agenta, zgłaszanie szkód z załącznikami, API dla pośredników i porównywarek | Uprawnienia sieci sprzedaży, dane z wniosków i polis, obsługa przesyłanych plików |
| Instytucja płatnicza, instytucja pieniądza elektronicznego, fintech | Aplikacja mobilna, API płatności, panel dla sprzedawców | Logika płatności i limitów, powtórne użycie żądań, weryfikacja webhooków |
| Firma inwestycyjna, pośrednik ubezpieczeniowy | Platforma klienta, integracje z systemami partnerów | Przejęcie konta, zmiana danych do wypłaty, separacja klientów i doradców |
| Dostawca ICT dla sektora finansowego | Moduły i usługi SaaS dla banków i ubezpieczycieli | Raport z niezależnego testu przed odbiorem, separacja klientów, przygotowanie do udziału w TLPT klienta |
DORA obejmuje 20 kategorii podmiotów finansowych (art. 2 ust. 1 lit. a-t), m.in. instytucje kredytowe, instytucje płatnicze i instytucje pieniądza elektronicznego, firmy inwestycyjne, zakłady ubezpieczeń i reasekuracji oraz pośredników ubezpieczeniowych poza mikro, małymi i średnimi przedsiębiorstwami. Obowiązki stosuje się proporcjonalnie do wielkości, profilu ryzyka oraz charakteru, skali i złożoności działalności (art. 4). Pełną listę i zakres rozporządzenia opisujemy na stronie DORA: testy odporności cyfrowej i zarządzanie ryzykiem ICT.
02DORA
Jakich testów wymaga DORA i które z nich wykonujemy?
Program testowania należy do podmiotu finansowego. Tabela pokazuje, które jego elementy możemy dostarczyć.
| Przepis | Czego wymaga | Nasz wkład |
|---|---|---|
| Art. 24 ust. 1-3 | Każdy podmiot poza mikroprzedsiębiorstwami ustanawia i utrzymuje program testowania jako część ram zarządzania ryzykiem ICT, a testy dobiera według analizy ryzyka. | Propozycja testów dla systemów wspierających krytyczne lub istotne funkcje; przegląd programu w ramach oceny gotowości do TLPT |
| Art. 24 ust. 4 | Testy wykonuje niezależna strona - wewnętrzna albo zewnętrzna; przy testerze wewnętrznym podmiot zapewnia wystarczające zasoby i unikanie konfliktów interesów. | Zewnętrzny wykonawca, niezależny od zespołu, który rozwija i utrzymuje testowany system |
| Art. 24 ust. 5 | Procedury ustalania hierarchii, klasyfikowania i rozwiązywania problemów z testów oraz wewnętrzne zatwierdzenie, że słabości usunięto w pełni. | Ocena CVSS z kontekstem biznesowym, zalecany termin naprawy i retest z nowym dowodem |
| Art. 24 ust. 6 | Odpowiednie testy wszystkich systemów i aplikacji ICT, które wspierają krytyczne lub istotne funkcje - co najmniej raz w roku. | Plan testów na cały rok w umowie ramowej, z terminami ustawionymi pod kalendarz wydań i zakresem potwierdzanym przed każdym testem |
| Art. 25 ust. 1 | Przepis wylicza przykładowe rodzaje testów: od ocen podatności i skanowania pod tym kątem, analiz otwartych źródeł informacji i ocen bezpieczeństwa sieci po przeglądy kodu źródłowego (gdy jest to wykonalne), testy scenariuszowe i testy penetracyjne. | Pentesty aplikacji, API, infrastruktury i chmury, audyt kodu (white box), oceny podatności i bezpieczeństwa sieci |
| Rozporządzenie delegowane (UE) 2024/1774, art. 16 ust. 3 | Przeglądy kodu źródłowego, z testami statycznymi i dynamicznymi, są częścią procedury pozyskiwania, rozwoju i utrzymania systemów ICT i obejmują testowanie bezpieczeństwa systemów i aplikacji internetowych. | Audyt kodu i testy aplikacji przed wydaniem - także dla systemów, których nie budowaliśmy |
W ramach testów bezpieczeństwa nie wykonujemy testów wydajności ani fizycznych kontroli bezpieczeństwa z listy art. 25. Nie prowadzimy też ataków DoS, testów obciążeniowych ani testów socjotechnicznych - te elementy programu testowania trzeba powierzyć innym wykonawcom albo zespołom wewnętrznym. Wyjątkiem są systemy, które sami budujemy: testy wydajności wykonujemy przy ich odbiorze.
Pentest nie zastępuje też zautomatyzowanego skanowania pod kątem podatności, które rozporządzenie delegowane 2024/1774 przewiduje co najmniej raz w tygodniu dla zasobów ICT wspierających krytyczne lub istotne funkcje (art. 10 ust. 2). Skaner wyłapuje znane błędy, a pentest - to, czego skaner nie widzi: logikę biznesową, uprawnienia i łańcuchy kilku podatności.
03TLPT
Testy z art. 24-25 a TLPT: co robimy, a czego nie
| Kryterium | Testy z art. 24-25 | TLPT (art. 26-27) |
|---|---|---|
| Kogo dotyczy | Podmiotów finansowych innych niż mikroprzedsiębiorstwa | Podmiotów wskazanych przez KNF w drodze decyzji |
| Częstotliwość | Systemy wspierające krytyczne lub istotne funkcje - co najmniej raz w roku | Nie rzadziej niż co trzy lata; organ może zmienić tę częstotliwość |
| Wykonawcy | Niezależne strony wewnętrzne lub zewnętrzne | Testerzy spełniający wymagania art. 27; KNF zatwierdza testerów wewnętrznych |
| Zakończenie | Raport, klasyfikacja i usunięcie problemów, retest | Poświadczenie testu wydawane przez KNF |
| Nasza rola | Wykonujemy testy penetracyjne i przeglądy kodu | Nie jesteśmy testerem TLPT - oceniamy gotowość i pomagamy porównać oferty testerów |
TLPT to zaawansowany test red team na działających systemach produkcyjnych, dopasowany do podmiotu na podstawie analizy zagrożeń. Organizacje, które chcą sprawdzić zespół obrony przed TLPT, mogą zacząć od red teamingu: wieloetapowej symulacji ataku pod cele uzgodnione z zarządem. Różnice między testem penetracyjnym a TLPT wyjaśniamy w artykule testy penetracyjne a TLPT w DORA, a wymagania wobec testerów TLPT - na stronie o przygotowaniu do TLPT.
04KNF
Co z rekomendacjami KNF od rozpoczęcia stosowania DORA?
Rekomendacja D dla banków przestała obowiązywać 17 stycznia 2025 r., w dniu rozpoczęcia stosowania DORA - uchwała KNF nr 6/2025 uchyliła uchwałę o jej wydaniu. Tego samego dnia straciły moc wytyczne IT z 2014 r. m.in. dla zakładów ubezpieczeń i firm inwestycyjnych (uchwała KNF nr 8/2025). Testy planuje się więc według DORA oraz aktów delegowanych i wykonawczych.
Nadzór może jednak pytać o to, jak podmiot uwzględnił rekomendacje Urzędu KNF w programie testowania - w rekomendacjach o modelach Frontier AI UKNF zapowiada, że adekwatność wdrożonych rozwiązań sprawdzi w nadzorze bieżącym i w czynnościach kontrolnych. Na zakres testu przekładają się dwie z nich:
- modele Frontier AI (22.07.2026) - scenariusze ataków z użyciem AI w testach odporności cyfrowej z art. 24-27 DORA, a przy naprawach kolejność według rzeczywistego ryzyka, a nie samej oceny CVSS,
- usługi SaaS (5.10.2026) - certyfikat dostawcy nie wystarcza jako potwierdzenie bezpieczeństwa usługi, więc ocena uwzględnia też skuteczność zabezpieczeń, wyniki testów i sposób usuwania nieprawidłowości, a przegląd obejmuje konta techniczne, tokeny i klucze API oraz integracje łączące usługę z systemami podmiotu.
05Bankowość i API
Co sprawdzamy w bankowości mobilnej, API i portalach klienta?
Sześć obszarów, od których zaczynamy test systemów obsługujących pieniądze i polisy klientów.
API
Dostęp do cudzych zasobów
Rachunki, polisy, szkody i dokumenty po zmianie identyfikatora w żądaniu - pierwsza pozycja listy OWASP API Security Top 10 2023 (API1:2023 Broken Object Level Authorization).
Aplikacja mobilna
Dane na urządzeniu
Tokeny, wyciągi i dokumenty w pamięci podręcznej, logach i zrzutach ekranu - według grupy MASVS-STORAGE.
Aplikacja mobilna
Odporność na modyfikację
Ochrona przed inżynierią wsteczną i uruchomieniem na urządzeniu z root lub jailbreak (MASVS-RESILIENCE) - uzasadniona w aplikacjach bankowych i płatniczych jako dodatkowa warstwa ochrony.
Integracje
Klucze partnerów i pośredników
Zakres kluczy API agentów, porównywarek i agregatorów, separacja danych między partnerami, unieważnianie dostępu po zakończeniu współpracy.
Logika biznesowa
Limity i wypłaty
Obejście limitów, podwójne wykonanie operacji przy równoległych żądaniach i zmiana rachunku do wypłaty bez ponownej autoryzacji - sprawdzane bez obciążania systemu.
Zakresy techniczne opisujemy na stronach: testy penetracyjne aplikacji mobilnych, testy bezpieczeństwa API, aplikacje webowe i audyt kodu źródłowego. Moduły rozliczeń, w których liczy się każda ścieżka w kodzie, najlepiej łączyć z audytem white box.
06Dostawcy ICT
Jesteś dostawcą ICT dla banku lub ubezpieczyciela?
Podmiot finansowy przez cały czas ponosi pełną odpowiedzialność za zgodność z DORA, także gdy korzysta z dostawców ICT (art. 28 ust. 1 lit. a). Dlatego bank albo ubezpieczyciel pyta dostawcę o aktualny raport z testu, a umowa o usługi wspierające krytyczne lub istotne funkcje obejmuje m.in. udział dostawcy w TLPT podmiotu finansowego oraz nieograniczone prawa dostępu, kontroli i audytu (art. 30 ust. 3).
Dla dostawcy przygotowujemy test przed odbiorem albo cykliczny, z raportem po polsku i po angielsku oraz retestem, który pokazuje usunięcie problemów. Sami też budujemy systemy dla tego sektora - zobacz oprogramowanie dla banków, ubezpieczycieli i brokerów.
07Co dostajesz
Co dostaje dział ryzyka ICT i audyt wewnętrzny?
| Element raportu | Do czego służy |
|---|---|
| Executive Summary | Informacja dla organu zarządzającego, który odpowiada za ramy zarządzania ryzykiem ICT |
| Zakres, podejście i środowisko | Dowód, który system i w jakim zakresie przetestowano - do rejestru testów w programie |
| Ustalenia z dowodami i oceną CVSS | Klasyfikacja problemów; dowody to dosłowny wynik poleceń i zapytań, bez parafraz |
| Mapowanie na wymagania DORA | Powiązanie ustaleń z obszarami rozporządzenia dla funkcji zgodności i audytu wewnętrznego |
| Harmonogram remediacji | Zalecane terminy: Critical 14 dni, High 30 dni, Medium 90 dni, Low 180 dni |
| Retest | Dowód usunięcia problemów - każda podatność sprawdzona ponownie z nowym dowodem |
| Wersje PL i EN | Dla grup kapitałowych, zagranicznych właścicieli i zespołów międzynarodowych |
Jak wygląda raport na danych demonstracyjnych, pokazujemy na stronie przykładowy raport z testu penetracyjnego. Na produkcji pracujemy nieinwazyjnie: bez modyfikacji danych, bez testów obciążeniowych, w uzgodnionych oknach czasowych i z kontaktem awaryjnym.
Najczęściej zadawane pytania
Czym różni się zakres testu z art. 24-25 DORA dla zakładu ubezpieczeń od zakresu dla banku?
Przepisy art. 24-25 DORA są w obu przypadkach te same, a różnicę robi lista systemów, które podmiot uznał za wspierające krytyczne lub istotne funkcje. W banku na pierwszy plan wysuwa się zatwierdzanie przelewów w aplikacji mobilnej i API udostępniane agregatorom. U ubezpieczyciela punktem wyjścia jest obieg szkody: formularz zgłoszenia z załącznikami, decyzja likwidatora i wypłata odszkodowania. Inny jest też zestaw kont testowych - w banku klient i pracownik oddziału, w zakładzie ubezpieczeń klient, agent i likwidator.
Czy test aplikacji mobilnej banku obejmuje telefony z rootem lub jailbreakiem?
Tak. Sprawdzamy, jak aplikacja zachowuje się na urządzeniu z rootem albo jailbreakiem, z podłączonym debuggerem i po podmianie pliku instalacyjnego na zmodyfikowany, a przede wszystkim - czy serwer nadal przyjmuje z takiej sesji zlecenia płatnicze. Samą blokadę uruchomienia na zmodyfikowanym telefonie da się zwykle obejść, dlatego ocenę ryzyka opieramy na tym, co atakujący osiągnie po jej obejściu. Szczegóły: testy penetracyjne aplikacji mobilnych.
Co sprawdzacie w systemie likwidacji szkód ubezpieczyciela?
Całą drogę sprawy od zgłoszenia do wypłaty. Czy zgłaszający widzi wyłącznie własne szkody i dokumenty, czy wgrany plik - zdjęcie pojazdu, faktura z warsztatu, dokumentacja medyczna - nie wykona kodu na serwerze ani nie trafi pod publiczny adres, czy rzeczoznawca zewnętrzny ma wgląd tylko w przydzielone sprawy i czy zmiana numeru rachunku do wypłaty odszkodowania wymaga zatwierdzenia przez drugą osobę. Konta testowe przygotowujesz dla każdej roli, od klienta po likwidatora z prawem do decyzji.
Kiedy zaplanować test, jeśli bank zamraża zmiany na przełomie roku?
Z takim wyprzedzeniem, żeby między raportem a początkiem zamrożenia zmieściły się poprawki i retest. Wtedy coroczny test systemów wspierających krytyczne lub istotne funkcje (art. 24 ust. 6 DORA) zamykasz potwierdzonym usunięciem problemów, a nie listą otwartych ustaleń. Gdy termin jest zbyt krótki, w okresie zamrożenia testujemy środowisko testowe, a retest na produkcji wykonujemy po pierwszym oknie wdrożeniowym w nowym roku. Daty raportu i retestu ustalamy w ofercie, więc od razu widać, czy zmieszczą się przed zamrożeniem.
Źródła
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), Dz.U. UE L 333 z 27.12.2022 ()
- Sprostowanie polskiej wersji rozporządzenia (UE) 2022/2554 (DORA), Dz.U. UE L 2024/90177 z 12.3.2024 ()
- Rozporządzenie delegowane Komisji (UE) 2024/1774 - narzędzia, metody, procesy i polityki zarządzania ryzykiem związanym z ICT oraz uproszczone ramy ()
- Ustawa z dnia 21 lipca 2006 r. o nadzorze nad rynkiem finansowym (t.j. Dz.U. 2026 poz. 935 ze zm.) ()
- Uchwała nr 6/2025 Komisji Nadzoru Finansowego z dnia 10 stycznia 2025 r. uchylająca uchwałę w sprawie wydania Rekomendacji D dotyczącej zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w bankach (Dz.Urz. KNF 2025 poz. 1) ()
- Uchwała nr 8/2025 Komisji Nadzoru Finansowego z dnia 10 stycznia 2025 r. uchylająca uchwały w sprawie wydania wytycznych dotyczących zarządzania obszarami technologii informacyjnej i bezpieczeństwa środowiska teleinformatycznego w podmiotach infrastruktury rynku kapitałowego, firmach inwestycyjnych, towarzystwach funduszy inwestycyjnych oraz zakładach ubezpieczeń i zakładach reasekuracji (Dz.Urz. KNF 2025 poz. 3) ()
- UKNF - Rekomendacje dla podmiotów rynku finansowego dotyczące wpływu modeli Frontier AI na cyberbezpieczeństwo (22.07.2026) ()
- UKNF - Rekomendacje dla podmiotów rynku finansowego dotyczące przeglądu bezpieczeństwa usług SaaS i zarządzania ryzykiem dostawców ICT (5.10.2026) ()
- OWASP Mobile Application Security Verification Standard (MASVS) 2.1 ()
- OWASP MASVS - wydania w repozytorium projektu (v2.1.0 oznaczone jako najnowsze) ()
- OWASP API Security Top 10 2023 ()
- FIRST - Common Vulnerability Scoring System (CVSS) v3.1 i v4.0 ()
Powiązane usługi
Zgodność · DORA
DORA i TLPT
DORA (rozporządzenie 2022/2554): kogo dotyczy, obszary wymagań, testy z art. 24-25 i TLPT, ryzyko ICT i wymagania wobec dostawców. Testy i ocena zgodności.
DORA · Ryzyko ICT
Ryzyko ICT
Ocena ram zarządzania ryzykiem ICT według DORA (art. 5-16) i RTS 2024/1774: zakres, uproszczone ramy z art. 16, metoda, macierz zgodności i plan działań.
Branże · Finanse i ubezpieczenia
Oprogramowanie dla finansów
Oprogramowanie dla banków, ubezpieczycieli i brokerów: DORA i dostawcy ICT, wymagania KNF po 2025 r., automatyzacja dokumentów polisowych, testy penetracyjne.