Test penetracyjny — cena i koszt pentestu w 2026 roku

Cena testu penetracyjnego w Polsce zaczyna się zwykle od kilku tysięcy złotych za mały, jasno ograniczony zakres, a przy rozbudowanej aplikacji, środowisku Active Directory lub ćwiczeniu Red Team może przekroczyć kilkadziesiąt tysięcy. Sama liczba ekranów, adresów IP czy endpointów nie wystarcza jednak do uczciwej wyceny. Dwa systemy o podobnym rozmiarze mogą wymagać zupełnie innego nakładu pracy ze względu na role użytkowników, logikę biznesową, integracje i jakość dokumentacji.

Poniższe widełki są orientacyjną mapą rynku na 2026 rok, a nie ofertą handlową BreachRoad. Pokazujemy także, co naprawdę składa się na koszt pentestu, jak uniknąć pozornie taniej usługi i jakie informacje przesłać, aby dostać porównywalne wyceny.

Ile kosztuje test penetracyjny — szybka odpowiedź

Publiczne polskie oferty mówią najczęściej o przedziale od kilku do kilkudziesięciu tysięcy złotych netto. To poprawna, ale mało użyteczna odpowiedź. Praktyczne widełki dla typowych zleceń wyglądają następująco:

Zakres	Orientacyjna cena netto	Typowy czas pracy
Mała powierzchnia zewnętrzna, kilka hostów	5–12 tys. zł	3–6 dni
Mała aplikacja WWW lub proste API	8–20 tys. zł	5–10 dni
Średni SaaS z kilkoma rolami i API	18–45 tys. zł	10–20 dni
Aplikacja mobilna Android/iOS wraz z API	20–55 tys. zł	12–25 dni
Wewnętrzna infrastruktura i Active Directory	15–50 tys. zł	8–25 dni
Rozbudowane ćwiczenie Red Team	40–150 tys. zł i więcej	4–12 tygodni

Widełki obejmują przygotowanie, testy manualne, analizę, raport, prezentację wyników i zwykle jeden retest. Nie obejmują automatycznie VAT, podróży, zakupu urządzeń, testów fizycznych ani całodobowych działań poza standardowym oknem.

Dlaczego zakres jest tak szeroki? Pięć endpointów realizujących przelewy, wielopoziomową autoryzację i integrację z bankiem może wymagać więcej pracy niż sto prostych endpointów katalogowych. Podobnie dziesięć serwerów w jednej płaskiej sieci to inny test niż dziesięć hostów rozdzielonych segmentacją, VPN-em, EDR-em i kilkoma domenami zaufania.

Co składa się na cenę pentestu

1. Powierzchnia techniczna

Najłatwiejsze do policzenia są adresy IP, domeny, aplikacje, moduły, endpointy API, platformy mobilne i role użytkowników. Nie powinno się ich jednak sumować mechanicznie. Tester musi zrozumieć zależności i określić, gdzie ręczna analiza ma największą wartość.

W aplikacji szczególnie kosztowne są złożone mechanizmy uprawnień, płatności, workflow zatwierdzeń, import plików, integracje OAuth/OIDC, funkcje administracyjne i obsługa wielu tenantów. To właśnie tam automatyczny skaner najczęściej nie rozumie kontekstu.

2. Model wiedzy testera

W black box tester zaczyna bez dokumentacji i kont, więc część czasu przeznacza na rekonesans. Grey box daje konta dla wszystkich ról, dokumentację i podstawowe informacje o architekturze. White box może obejmować kod źródłowy, konfigurację oraz rozmowę z deweloperami.

Większa ilość wiedzy nie musi oznaczać droższej usługi. Dobrze przygotowany grey box często pozwala przeznaczyć więcej budżetu na realne testy zamiast odtwarzania informacji, które klient już posiada. OWASP rekomenduje dostęp do odpowiednich ról i dokumentacji, gdy celem jest szeroka, powtarzalna weryfikacja, a nie wyłącznie symulacja anonimowego napastnika.

3. Wymagany poziom pokrycia

„Sprawdźcie OWASP Top 10” może znaczyć szybki przegląd albo dokładne przejście przez setki scenariuszy. Warto w umowie wskazać standard i oczekiwane dowody. Dla aplikacji webowych przydatne są OWASP Web Security Testing Guide oraz ASVS. Dla mobile — MASVS i MASTG. Dla infrastruktury można oprzeć zakres na NIST SP 800-115, PTES i modelu zagrożeń konkretnej organizacji.

Im bardziej regulowany system, tym więcej czasu zajmują śledzenie pokrycia, zachowanie dowodów, mapowanie wymagań i formalna dokumentacja. To wartościowa część pracy, ale nie należy mylić jej z samą eksploatacją podatności.

4. Ryzyko operacyjne i środowisko

Test produkcji wymaga ostrożniejszych technik, okien zmian, bieżącego kontaktu i planu awaryjnego. System medyczny, przemysłowy albo obsługujący płatności może potrzebować ograniczeń, które spowalniają test, ale zmniejszają ryzyko przerwy.

Tańszy i bezpieczniejszy bywa staging odtwarzający konfigurację produkcyjną. Jeśli jednak różni się wersjami, danymi, politykami WAF lub integracjami, wynik może dać fałszywe poczucie bezpieczeństwa. Koszt przygotowania wiarygodnego środowiska również należy uwzględnić.

5. Raport, retest i wsparcie po teście

Dobry raport zawiera nie tylko nazwę luki i CVSS. Powinien pokazać dowód, wpływ biznesowy, warunki ataku, dotknięte zasoby i konkretną rekomendację. Raport zarządczy odpowiada na inne pytania niż techniczny opis dla dewelopera.

W cenie warto potwierdzić prezentację wyników, możliwość konsultacji oraz retest. Bez retestu organizacja wie, że wdrożyła zmianę, ale nie ma niezależnego potwierdzenia, czy problem rzeczywiście został usunięty i czy nie pojawiło się obejście.

Przykład wyceny aplikacji SaaS

Załóżmy, że firma ma aplikację B2B z trzema rolami: pracownik, manager i administrator klienta. System obsługuje dziesięć głównych modułów, REST API, logowanie OIDC, import plików oraz integrację płatniczą. Aplikacja jest wielotenantowa.

Największym kosztem nie jest liczba ekranów. Tester musi sprawdzić separację tenantów, poziome i pionowe obejścia uprawnień, zaproszenia do organizacji, reset i łączenie kont, uprawnienia do plików, nadużycia procesu płatności oraz wpływ integracji. Potrzebne są konta dla co najmniej dwóch tenantów i każdej roli.

Realistyczny zakres może obejmować 12–18 dni pracy testowej plus raport i retest. Oferta na dwa dni prawdopodobnie pokryje skaner, kilka standardowych testów i ograniczoną próbkę logiki. Może być przydatna jako szybki przegląd, ale nie jest równoważna pełnemu pentestowi aplikacji.

Dlaczego najtańsza oferta bywa najdroższa

Cena może być niska z dobrych powodów: mały zakres, dobrze przygotowana dokumentacja, powtarzalny system albo świadomie ograniczony cel. Problem pojawia się, gdy oferty używają tej samej nazwy dla różnych produktów.

Sygnały ostrzegawcze to:

brak pytań o role, tenanty, integracje i logikę biznesową;
obietnica pełnego testu dużej aplikacji w jeden lub dwa dni;
raport będący eksportem ze skanera;
brak manualnej weryfikacji i dowodów;
niejasne zasady bezpiecznej eksploatacji;
brak retestu lub dodatkowa, wysoka opłata za każdy znaleziony błąd;
brak informacji o odpowiedzialności, poufności i usuwaniu danych;
określenie „certyfikat OWASP”, którego OWASP nie wydaje dla testowanych aplikacji.

Zbyt płytki test może przepuścić BOLA, race condition, błąd workflow czy przejęcie konta — problemy, których nie wykrywa prosty skan. Koszt pojawia się później: ponowny test, opóźnione wdrożenie albo incydent.

Jak porównać oferty testu penetracyjnego

Poproś każdego dostawcę o wycenę na podstawie tego samego opisu. Porównaj nie tylko kwotę, ale również:

dokładny zakres zasobów i funkcji;
liczbę oraz rodzaj dni testowych;
podejście black, grey lub white box;
standardy i metodologię;
zakres testów manualnych oraz automatycznych;
wymagane konta i dane testowe;
zasady komunikacji krytycznych znalezisk;
zawartość raportu technicznego i zarządczego;
prezentację wyników i wsparcie w naprawach;
liczbę retestów, termin ważności i warunki dodatkowych testów.

Warto poprosić o anonimowy fragment przykładowego raportu. Nie chodzi o liczbę stron, lecz o jakość dowodu i rekomendacji. Dobry raport pozwala zespołowi samodzielnie odtworzyć problem oraz potwierdzić poprawkę.

Jak przygotować dane do szybkiej wyceny

Im precyzyjniejszy brief, tym mniej „buforu niepewności” musi uwzględnić dostawca. Przed zapytaniem przygotuj:

cel testu: ryzyko biznesowe, wymaganie klienta, regulacja lub premiera;
adresy i środowiska objęte zakresem;
liczbę modułów, ról, tenantów i integracji;
dokumentację OpenAPI, diagram architektury i opis logowania;
platformy oraz wersje aplikacji mobilnej;
ograniczenia produkcyjne i dozwolone godziny;
oczekiwany termin raportu oraz retestu;
wymagane mapowanie do ASVS, MASVS, NIS2, DORA czy polityki wewnętrznej.

Więcej informacji organizacyjnych znajdziesz w poradniku jak przygotować się do testu penetracyjnego. Jeśli nie wiesz, czy potrzebujesz pentestu, audytu czy skanu, zacznij od naszego porównania metod.

Czy abonament i ciągłe testy są tańsze

Przy szybko rozwijanym SaaS jednorazowy test raz w roku szybko się dezaktualizuje. Model okresowy może obejmować duży test bazowy, krótsze testy zmian i ustaloną pulę retestów. Koszt roczny rośnie, ale koszt pojedynczego wdrożenia i przygotowania zwykle maleje, bo tester zna architekturę, a klient utrzymuje konta oraz dokumentację.

Nie zastępuje to ciągłego SAST, SCA i DAST w CI/CD. Narzędzia automatyczne oraz manualny pentest odpowiadają na inne pytania. Automatyzacja szybko znajduje powtarzalne wzorce; człowiek ocenia logikę, łączy podatności i sprawdza wpływ.

Najczęstsze pytania o cenę pentestu

Czy darmowy skaner może zastąpić test penetracyjny? Nie. Skaner jest dobrym pierwszym filtrem dla konfiguracji i znanych podatności. Nie rozumie pełnej logiki biznesowej ani wszystkich relacji uprawnień. Nasz darmowy skaner bezpieczeństwa świadomie nie jest nazywany pentestem.

Czy cena zależy od liczby wykrytych luk? Nie powinna. Płacisz za ustalony zakres, czas i jakość weryfikacji, a nie za sztukę podatności. Model „zapłata za błąd” pasuje bardziej do bug bounty i tworzy inne bodźce.

Czy mała firma potrzebuje testu za kilkadziesiąt tysięcy? Niekoniecznie. Lepiej dobrze przetestować krytyczny proces lub internetową powierzchnię niż kupować szeroki, płytki audyt. Zakres powinien wynikać z najważniejszych aktywów i realistycznego modelu zagrożeń.

Czy retest powinien być w cenie? Najczęściej tak, przynajmniej jeden dla zgłoszonych podatności w ustalonym terminie. Trzeba sprawdzić, czy obejmuje wszystkie poprawki i czy dostawca wydaje zaktualizowane podsumowanie.

Ile trwa przygotowanie oferty? Przy kompletnym briefie wycena małego lub średniego zakresu zwykle nie wymaga długiego discovery. Złożony system może potrzebować krótkiego warsztatu scopingowego, który ograniczy ryzyko rozbieżnych oczekiwań.

Podsumowanie: kupuj zakres i dowód, nie samą liczbę dni

Cena testu penetracyjnego jest funkcją powierzchni, złożoności logiki, oczekiwanego pokrycia, ryzyka środowiska oraz jakości raportu i retestu. Orientacyjne widełki pomagają zaplanować budżet, ale nie zastępują scopingowego opisu.

Najlepsza oferta nie zawsze jest najdłuższa ani najdroższa. Powinna jasno mówić, co zostanie przetestowane, jak głęboko, według jakiej metodyki i jaki dowód otrzyma zespół. Jeśli chcesz uzyskać porównywalną wycenę, wyślij przez formularz kontaktowy opis ról, modułów, integracji i oczekiwanego terminu. Najpierw uporządkujemy zakres, dopiero potem cenę.

Źródła i dalsza lektura: NIST SP 800-115 — Technical Guide to Information Security Testing, OWASP Web Security Testing Guide, Penetration Testing Execution Standard, publiczne polskie strony ofertowe analizowane przy budowie widełek: testpenetracyjny.pl i Pentestica. Widełki są orientacyjne i nie stanowią oferty BreachRoad.