Testy penetracyjne a testy bezpieczeństwa: różnice, ceny w zł i szablon zakresu

Testy penetracyjne a testy bezpieczeństwa to rozróżnienie, które brzmi jak akademicka pedanteria, dopóki nie trzymacie w ręku trzech ofert na „to samo badanie”, różniących się ceną o 300%. Różnica jest jednak bardzo realna: jedna oferta opisuje dwa tygodnie pracy ręcznej doświadczonego testera, druga godzinny przebieg automatycznego skanera, a obie mają w tytule słowo „bezpieczeństwo” i obie wyglądają poważnie.

Stawka rośnie z roku na rok. Według raportu Verizon 2026 Data Breach Investigations Report 31% naruszeń zaczyna się dziś od wykorzystania podatności w oprogramowaniu i to pierwszy raz w 19 letniej historii tego raportu, gdy podatności wyprzedziły wykradzione hasła jako najczęstszą drogę wejścia. Z kolei CERT Polska w raporcie rocznym za 2025 rok zarejestrował 260 783 unikalnych incydentów, o 152% więcej niż rok wcześniej. Dlatego ten tekst nie jest encyklopedią definicji. Wychodzicie z niego z szablonem zakresu do skopiowania, tabelą decyzyjną, cenami w zł i checklistą odbioru raportu.

Testy penetracyjne a testy bezpieczeństwa: co jest czym, w dwóch zdaniach

Testy bezpieczeństwa to cała kategoria działań: automatyczny skan podatności, audyt kodu źródłowego, przegląd konfiguracji serwera, warsztaty dla zespołu i wreszcie test penetracyjny. Test penetracyjny to jedna, konkretna metoda w tym worku: według publikacji NIST SP 800-115 z 2008 roku to badanie, w którym oceniający naśladują realne ataki, żeby znaleźć sposoby obejścia zabezpieczeń, a większość testów penetracyjnych szuka kombinacji podatności, które razem dają większy dostęp niż każda z nich osobno. Tyle definicji, obiecaliśmy dwa zdania.

Teraz część, która kosztuje Was pieniądze. Gdy w zapytaniu piszecie „testy bezpieczeństwa”, każdy dostawca może uczciwie wycenić coś innego: jeden człowieka na dwa tygodnie, drugi licencję na skaner i godzinę konfiguracji. Potem porównujecie ceny i wybieracie „tę samą usługę taniej”, choć porównujecie dwa różne produkty. Z naszego doświadczenia wynika jedno: różnicy nie rozstrzyga nazwa w ofercie, rozstrzyga ją zakres ręczny zapisany w Waszym zapytaniu. Jak ta różnica wygląda od strony technicznej, uczymy na szkoleniu testy penetracyjne aplikacji webowych, a jako usługę realizujemy ją w ramach oferty testy bezpieczeństwa aplikacji i pentesty. Same pojęcia rozbieramy też szerzej we wpisie testy penetracyjne bezpieczeństwa; tutaj zajmujemy się tym, czego tam nie ma: zakresem, cenami i odbiorem raportu.

Szablon zakresu testu penetracyjnego do skopiowania: dziesięć pól zapytania ofertowego

To jest serce tego artykułu. Dziesięć pól, które wklejacie do zapytania ofertowego i wypełniacie swoimi danymi. Gdy wszystkie trzy oferty odpowiadają na te same dziesięć pól, nagle robią się porównywalne, a różnica 300% w cenie przestaje być zagadką i zaczyna być informacją. Wartości w prawej kolumnie są przykładowe, celowo wypełnione, żebyście widzieli poziom szczegółu, o który chodzi.

Dwa pola decydują o cenie bardziej niż wszystkie pozostałe razem: pole 5 i pole 9. Zakres ręczny to godziny pracy człowieka, a godziny pracy doświadczonego testera to główny koszt całej usługi, więc to właśnie pole 5 mówi dostawcy, ile osobodni musi wycenić. Retest z pola 9 to drugie takie miejsce, bo zobowiązuje dostawcę do powrotu po poprawkach, czyli do kolejnych godzin pracy zapisanych w cenie. I odwrotnie: jeśli oferta, którą dostaliście, w ogóle nie odnosi się do zakresu ręcznego, to z dużym prawdopodobieństwem jest to oferta na uruchomienie skanera z ładniejszą okładką. Nie jest to oszustwo, skan też bywa potrzebny, ale powinniście wiedzieć, że płacicie za narzędzie, nie za człowieka.

Tabela decyzyjna: skan podatności, testy bezpieczeństwa czy pentest

Drugie narzędzie do wzięcia. Zamiast pytać „co jest lepsze”, zacznijcie od swojej sytuacji i odczytajcie, co faktycznie ma sens zamówić. Pięć najczęstszych przypadków, które widzimy w firmach, które szkolimy:

Ostatni wiersz zasługuje na liczby, bo wiele firm traktuje aplikację z modelem językowym jak zwykłą aplikację webową. Według raportu Cobalt „AI and Pentesting Pulse Report 2026″ aż 32% znalezisk z testów aplikacji opartych na AI i modelach językowych oceniono jako wysokie ryzyko, wobec 12% dla wszystkich znalezisk razem. Ten sam raport Cobalt z 2026 roku podaje, że średni czas naprawy podatności w aplikacjach AI i LLM wzrósł do 36 dni z 19 dni rok wcześniej, a naprawionych jest 38% tych podatności. Jeśli Wasz produkt rozmawia z użytkownikiem przez model językowy, zapiszcie to osobnym punktem w polu 1 szablonu.

Manualne testy penetracyjne a automatyczny skan: co znajduje człowiek, czego nie zobaczy narzędzie

Manualne testy penetracyjne znajdują przede wszystkim to, czego narzędzie nie ma prawa zobaczyć: błędy logiki biznesowej i kontroli dostępu. NIST w SP 800-115 nazywa to, co mierzy skaner, podatnościami powierzchniowymi, czyli takimi, które istnieją w oderwaniu od innych, i pisze wprost, że skanery nie wykryją podatności ujawniających się dopiero jako wynik kombinacji wzorców ataku, a narzędzie może przypisać każdej z nich z osobna niskie ryzyko i zostawić Was w fałszywym poczuciu bezpieczeństwa. Skaner nie wie, że konto klienta nie powinno widzieć faktur innego klienta. Nie wie, że rabat nie powinien przyjmować wartości ujemnej, a limit zamówienia da się obejść, edytując żądanie HTTP. Dla narzędzia to poprawnie działające funkcje; dla człowieka, który rozumie Wasz biznes, to otwarte drzwi.

U naszych klientów powtarza się przy tym jeden wzorzec: zespół naprawia rzeczy tanie i widoczne, nagłówki, wersje bibliotek, konfigurację TLS, bo one świecą się na liście ze skanera, a zostawia błędy uprawnień, bo tych na żadnej liście nie widać. Skaner podatności jest jak czujnik dymu: bardzo przydatne urządzenie, dopóki ktoś nie uzna, że sam gasi pożary. Mapę tego, czego szuka człowiek, znajdziecie w naszym wpisie OWASP Top 10:2025 okiem testera.

Jedno uczciwe zastrzeżenie: wydawcą cytowanego raportu jest Cobalt, firma, która sama sprzedaje testy penetracyjne, więc wynik gra do jej bramki. Liczby są jednak spójne z tym, co NIST pisał bez żadnego interesu handlowego już w 2008 roku, i z tym, co widzimy w firmach, które szkolimy: automat i człowiek znajdują różne klasy błędów i żaden z nich nie zastępuje drugiego. Dlatego pole 5 szablonu, zakres ręczny, nie jest ozdobnikiem, tylko jedynym miejscem, w którym kupujecie pracę człowieka.

Ile kosztują testy penetracyjne: ceny w zł i co podnosi wycenę

Konkretne liczby z naszego żywego cennika usług, wszystkie ceny netto i „od”, bo ostateczna wycena zależy od zakresu:

• test penetracyjny aplikacji webowej: od 6 000 zł
• testy bezpieczeństwa aplikacji mobilnej: od 7 000 zł
• testy bezpieczeństwa API: od 5 500 zł
• testy infrastruktury i konfiguracji serwera: od 5 000 zł
• testy bezpieczeństwa dla e commerce: od 5 000 zł
• audyt bezpieczeństwa kodu źródłowego: od 4 800 zł
• warsztat bezpieczeństwa dla zespołu IT: od 5 500 zł

Czas trwania: test penetracyjny aplikacji webowej zajmuje zwykle od kilku dni do dwóch tygodni, złożone projekty dłużej. Z naszych ponad 70 projektów z testów bezpieczeństwa, realizowanych zarówno dla dużych organizacji państwowych, jak i dla mniejszych firm prywatnych, wynika prosta zależność: wycenę podnosi przede wszystkim to, co zapisaliście w polu 5 szablonu, czyli szerokość zakresu ręcznego, a zaraz potem liczba punktów końcowych API, liczba ról i kont do sprawdzenia, wymagane okno czasowe (praca nocna i weekendowa kosztuje więcej) oraz retest w cenie. Jeżeli dwie oferty różnią się o 300%, zwykle nie różnią się marżą, tylko liczbą osobodni pracy ręcznej, której jedna z nich w ogóle nie zawiera. Szerzej o mechanice wycen piszemy w tekście ile kosztują testy oprogramowania, a przed każdą wyceną oferujemy bezpłatną konsultację, na której można te pola przegadać.

Warto też policzyć drugą stronę równania. Na Strefie QA, naszym portalu dla liderów jakości, rozkładamy na czynniki pierwsze, ile kosztuje luka, której nikt nie szukał; po tej lekturze cennik powyżej czyta się inaczej. A jeśli wolicie budować kompetencję u siebie: dwudniowe szkolenie „Testy penetracyjne” kosztuje 2 698 zł netto za osobę, w czerwcu 2026 przeprowadziliśmy je w wersji zamkniętej dla 14 osób z firmy AgroApp. Terminy znajdziecie w zakładce kalendarz szkoleń, a pełną ścieżkę rozwojową w szkoleniach z cyberbezpieczeństwa.

Jak przebiega test penetracyjny: cztery fazy według NIST

Publikacja NIST SP 800-115 z 2008 roku opisuje test penetracyjny jako cztery fazy i warto je znać, bo porządkują rozmowę z dostawcą. Faza pierwsza to planowanie: ustalenie zasad, zgoda kierownictwa, cele testu; żadnych testów jeszcze nie ma, powstaje dokładnie to, co spisaliście w szablonie zakresu. Faza druga to rozpoznanie: zbieranie informacji o celu, skanowanie portów i usług, analiza podatności. Faza trzecia to atak, czyli próba faktycznego wykorzystania znalezionych podatności, z pętlą dodatkowego rozpoznania po każdym zdobytym dostępie, bo nowy dostęp odsłania nowe możliwości. Faza czwarta to raport, który rozbieramy w następnej sekcji.

NIST dodaje dwie uwagi, które przekładają się wprost na Wasze zapytanie ofertowe. Po pierwsze, test penetracyjny jest pracochłonny i wymaga dużej wiedzy, więc tani i szybki pentest to wewnętrznie sprzeczne zamówienie. Po drugie, system może w trakcie testu przestać działać, dlatego test wykonuje się po przygotowaniu i powiadomieniu właściwych osób. To jest dokładnie powód istnienia pola 7 w szablonie: okno czasowe i telefon dyżurnego po Waszej stronie nie są biurokracją, tylko planem na moment, w którym coś pójdzie nie tak o 14:30 we wtorek.

Co dostajecie w raporcie i checklista odbioru, dziesięć punktów

Raport to jedyny trwały produkt całej usługi i to po nim poznaje się, za co naprawdę zapłaciliście. Problem w tym, że raport sam niczego nie naprawia. Według omówienia raportu Verizon DBIR 2026 opublikowanego przez Help Net Security w 2026 roku tylko 26% podatności z listy znanych wykorzystywanych podatności CISA zostało w pełni naprawionych przez 13 000 badanych organizacji, rok wcześniej było to 38%. To samo omówienie Help Net Security z 2026 roku podaje, że mediana czasu do pełnego załatania po wykryciu wynosi 43 dni, rok wcześniej 32 dni, a słabe hasła i błędy w uprawnieniach połowa badanych naprawia przez blisko osiem miesięcy. Innymi słowy: świat nie ma problemu ze znajdowaniem podatności, świat ma problem z ich naprawianiem. Dlatego pole 9 szablonu, retest w konkretnym terminie, jest w naszej ocenie ważniejsze niż niejedna pozycja, o którą toczą się negocjacje cenowe.

Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „Raport z testów nie czyni systemu bezpiecznym. Bezpieczniejszy robi się wtedy, gdy ktoś naprawia to, co w raporcie stoi, i sprawdza to ponownie. Dlatego przy każdej wycenie pytamy, kto u klienta będzie właścicielem naprawy, bo bez tej jednej osoby najlepszy raport zostaje plikiem na dysku.” W rozmowach z CTO to zresztą regularnie najtrudniejsze pytanie: nie „ile to kosztuje”, tylko „kto u Was to naprawi”.

Jeżeli raport przechodzi osiem z dziesięciu punktów, macie dobrego dostawcę. Jeżeli przechodzi cztery, zapłaciliście za wydruk ze skanera. Dla zarządów przygotowaliśmy na Strefie QA także minimalny zestaw działań dla zarządu, który dobrze uzupełnia tę checklistę od strony decyzyjnej.

Kto musi i jak często: przepisy, które wymuszają testy w Polsce

Coraz częściej pytanie „czy testować” zadaje za Was regulator albo Wasz klient. Ustawa o krajowym systemie cyberbezpieczeństwa i wdrażana dyrektywa NIS 2 sprawiają, że podmioty objęte przepisami pytają swoich dostawców oprogramowania o dowody badań bezpieczeństwa; jeśli jesteście takim dostawcą, sprawdźcie, jakich testów zażąda klient objęty KSC, zanim zapyta. Odpowiedzialność nie rozmywa się przy tym w organizacji: opisaliśmy osobno obowiązki kierownika podmiotu. Producentów produktów cyfrowych dotyczy rozporządzenie o cyberodporności, które zakłada testowanie podatności przez cały cykl życia produktu, a sektor finansowy ma w DORA wymóg testów niezależnych od producenta w DORA. Ważne zastrzeżenie z naszej praktyki: raport z testów dokumentuje stan produktu na dany dzień i to właśnie taka dokumentacja, z datą, zakresem i retestem, jest tym, czego potrzebujecie w rozmowie z klientem albo audytorem. Uciekajcie od dostawców, którzy obiecują więcej.

Skalę zjawiska w Polsce dobrze pokazują dane CERT Polska z raportu rocznego za 2025 rok: 658 320 zgłoszeń i 260 783 unikalnych incydentów, przy czym liczba incydentów wzrosła o 152% rok do roku, a zespół przetwarza średnio blisko 55 tysięcy zgłoszeń miesięcznie. Ten sam raport CERT Polska podaje, że zespół opublikował w 2025 roku 165 identyfikatorów CVE, wobec 73 w pierwszym roku pracy jako CNA, i wprost wiąże pracę nad skoordynowanym ujawnianiem podatności z wdrażaniem NIS 2 i rozporządzenia o cyberodporności. A jak często testować? Z naszego doświadczenia rozsądny rytm dla większości firm wygląda tak: skan podatności przy każdym wydaniu, pełny test penetracyjny po każdej dużej zmianie architektury albo modelu uprawnień, a retest po każdej rundzie poprawek. Częstotliwość z kalendarza bez tych wyzwalaczy to rytuał, nie zarządzanie ryzykiem.

Co to oznacza praktycznie dla Was

Zanim wyślecie następne zapytanie ofertowe, odpowiedzcie sobie na trzy pytania. Po pierwsze: czy w Waszym ostatnim zapytaniu był zapisany zakres ręczny, czyli pole 5 z szablonu, czy tylko hasło „testy bezpieczeństwa”? Po drugie: kto u Was, z imienia i nazwiska, jest właścicielem naprawy znalezisk z ostatniego raportu? Po trzecie: kiedy ostatnio ktoś powtórzył test po poprawkach i czy istnieje z tego protokół?

Jeśli na któreś z tych pytań odpowiedź brzmi „nie wiem”, to dobra wiadomość jest taka, że macie już wszystko, czego potrzeba, żeby to zmienić: szablon dziesięciu pól do skopiowania, tabelę decyzyjną na pięć sytuacji, ceny w zł do budżetu i checklistę odbioru raportu. Następna rozmowa z dostawcą będzie wyglądała zupełnie inaczej, bo tym razem to Wy będziecie wiedzieć, co kupujecie.

Powiązane na blogu Quality Island

• owasp top 10:2025 okiem testera
• jakich testów zażąda klient objęty ksc
• obowiązki kierownika podmiotu
• testowanie podatności przez cały cykl życia
• ile kosztują testy oprogramowania

Pełna lista źródeł

• Verizon, „2026 Data Breach Investigations Report”, 2026, verizon.com. Stąd udział naruszeń zaczynających się od wykorzystania podatności, udział ransomware i okres danych.
• Help Net Security, omówienie raportu Verizon DBIR 2026, 2026, helpnetsecurity.com. Stąd odsetek w pełni naprawionych podatności z listy CISA i mediana czasu łatania.
• Cobalt, „AI and Pentesting Pulse Report 2026″, 2026, cobalt.io. Stąd dane o fałszywych wynikach negatywnych skanerów, odwrocie od pełnej automatyzacji i podatnościach aplikacji AI.
• NIST, „Technical Guide to Information Security Testing and Assessment”, SP 800-115, 2008, nvlpubs.nist.gov. Stąd definicja testu penetracyjnego, cztery fazy i ograniczenia skanerów podatności.
• CERT Polska (NASK), „Raport roczny 2025″, 2026, cert.pl. Stąd liczba zgłoszeń i incydentów w Polsce oraz dane o publikowanych identyfikatorach CVE.
• Dane własne Quality Island, 2026. Stąd liczba zrealizowanych projektów, cennik usług, czasy trwania testów i dane o szkoleniach.