Testy penetracyjne: cennik, czyli jak czytać wycenę pentestu

Ile kosztują testy penetracyjne? Cennik każdego dostawcy sprowadza się do wzoru: osobodni, których potrzebują testerzy, razy ich stawka dzienna, plus raport i, jeśli go zamówicie, retest. Liczbę dni wyznacza zakres: ile aplikacji webowych, ról użytkowników i endpointów API, jaka część sieci wewnętrznej, które konta w chmurze. Co powinno się w tych dniach zmieścić, opisują m.in. OWASP Web Security Testing Guide i NIST SP 800-115. Poniżej pokazujemy, jak czytać wycenę pozycja po pozycji, zanim zamówicie testy penetracyjne.

Testy penetracyjne: cennik, czyli jak liczy się cenę?

Większość polskich dostawców nie publikuje stawek dziennych, a oferta z jedną kwotą i bez liczby dni ukrywa sposób liczenia. Cena to dni razy stawka. Dni wynikają z ustalenia zakresu, więc ten sam zespół wyceni zupełnie inaczej jedną aplikację webową i sieć wewnętrzną z trzema kontami w chmurze.

Jeden publiczny punkt odniesienia: dostawcy na brytyjskiej rządowej platformie G-Cloud 14 publikują swoje stawki dzienne. Pentest Cyber podaje 900 GBP za dzień, PureCyber od 750 do 1400 GBP za dzień za testy aplikacji webowych (stan na 27 października 2026). To ceny katalogowe ustalone przez samych dostawców, nie wartości podpisanych umów, i nie przenoszą się wprost na polski rynek.

Od czego zależy liczba dni testu?

Każdy element zakresu dokłada czasu, więc dostawca musi znać wielkość każdego celu, zanim policzy dni. Tabela pokazuje, o co Was zapyta i dlaczego to zmienia wycenę.

OWASP dzieli testy penetracyjne aplikacji webowych na kategorie, m.in. uwierzytelnianie, autoryzację, zarządzanie sesją, walidację danych wejściowych, logikę biznesową i testy po stronie klienta. Skąd biorą się te słabości, opisujemy w tekście o bezpieczeństwie aplikacji internetowych. Konfigurację kont chmurowych, której pentest dotyka tylko częściowo, obejmuje audyt chmury.

Poproście dostawcę, żeby pod ceną wpisał założenia: liczbę ról, endpointów albo adresów IP. Jeśli zakres okaże się większy albo mniejszy, zobaczycie, które założenie się zmieniło i z czego wynika nowa cena.

Black box, grey box czy white box: co daje więcej za te same pieniądze?

Te nazwy mówią, ile testerzy wiedzą na starcie. Przewodnik OWASP nazywa test bez wcześniejszej wiedzy testem black box, a test z częściową wiedzą o aplikacji testem grey box. W praktyce grey box oznacza zwykle konto testowe dla każdej roli. W teście white box zespół dostaje dokumentację, konta i często kod źródłowy.

Black box brzmi realistycznie, ale część opłaconych dni idzie na ustalanie tego, co moglibyście napisać testerom w jednym mailu. Niemieckie BSI w swoim praktycznym przewodniku po testach penetracyjnych co do zasady zaleca testy white box. Napastnik ma tyle czasu, ile chce. Testerzy mają tyle dni, ile zapisano w Waszej wycenie.

Przy aplikacjach webowych najczęściej wybiera się grey box. Jeśli potrzebujecie sprawdzenia aplikacji pod kątem zgodności ze standardem bezpieczeństwa, a nie symulacji ataku, to inny zakres: weryfikacja według OWASP ASVS.

Co powinna zawierać wycena testu penetracyjnego?

Wycena, którą da się porównać, opisuje pracę, a nie tylko kwotę. Sprawdźcie te pozycje:

• Zakres. Cele wymienione z nazwy: adresy URL, adresy bazowe API, zakresy IP, konta w chmurze, a także to, co jest wprost wyłączone.
• Metodyka. Przewodnik, według którego pracuje zespół, np. OWASP Web Security Testing Guide albo NIST SP 800-115 z fazami planowania, rozpoznania, ataku i raportowania.
• Pracochłonność. Osobodni na każdy cel i liczba osób w zespole.
• Warunki testu. Środowisko, okna czasowe, konta, które przekazujecie, i osoba kontaktowa w trakcie testu.
• Zasady prowadzenia testu (Rules of Engagement, RoE). Podpisana zgoda na to, co i jak wolno testować; NIST SP 800-115 traktuje ją jako upoważnienie dla testerów.
• Raport. Podsumowanie dla zarządu, a przy każdej podatności poziom ryzyka, dowód, kroki odtworzenia i rekomendacja.
• Retest. Czy jest w cenie, w jakim terminie i których podatności dotyczy.

Pozycja „pentest aplikacji: 1 pakiet” nie mówi, czy kupujecie ręczne testy, czy automatyczny skan z raportem w barwach firmy.

Dlaczego dwie wyceny pentestu tak bardzo się różnią?

Zwykle dlatego, że wyceniają inną pracę. Gdy położycie dwie oferty obok siebie, często okaże się, że:

• jedna obejmuje API i panel administracyjny, druga tylko publiczną część aplikacji;
• jedna liczy dni ręcznych testów, druga opiera się głównie na skanerze podatności;
• jedna zakłada jednego testera, druga zespół (przewodnik BSI zakłada co najmniej dwie osoby na test);
• jedna ma w cenie retest i podsumowanie dla zarządu, druga liczy je osobno;
• jedna testuje nocą na produkcji, druga w dzień na kopii testowej.

Poproście obu dostawców o wypełnienie tej samej tabeli: cele, dni na cel, metodyka, zespół, raport i retest. Różnica w cenie zwykle maleje albo daje się wyjaśnić. Pentest sprawdza, czy ktoś dostanie się do środka, i nie zastępuje audytu IT procesów i uprawnień.

Czym jest retest i czy powinien być w cenie?

Retest to drugi, krótszy test po usunięciu podatności. NIST SP 800-115 (rozdział 8.3) mówi, że ponowny test potwierdza wdrożenie działań naprawczych, a poprawkę sprawdza się, powtarzając pierwotny test. Bez retestu raport pokazuje, co było dziurawe, a nie to, co jest naprawione dziś.

Przed podpisaniem zadajcie cztery pytania. Czy retest jest w cenie, czy to osobna pozycja? Ile czasu po raporcie możecie go zamówić? Czy obejmuje wszystkie podatności, czy tylko krytyczne i wysokie? Czy dostaniecie zaktualizowany raport z oznaczeniem naprawionych podatności?

Kiedy przepisy oczekują testu penetracyjnego?

Dla podmiotów finansowych DORA mówi to wprost (stan na 27 października 2026). Podmioty inne niż mikroprzedsiębiorstwa co najmniej raz w roku muszą przeprowadzać odpowiednie testy wszystkich systemów i aplikacji ICT wspierających funkcje krytyczne lub istotne. Testy prowadzą niezależni testerzy wewnętrzni albo zewnętrzni, a testy penetracyjne są na liście rodzajów testów w art. 25 ust. 1.

Testy TLPT co 3 lata dotyczą tylko podmiotów wskazanych przez organ nadzoru (rozporządzenie (UE) 2022/2554, art. 24-26).

NIS2 nie używa słowa pentest. Art. 21 ust. 2 lit. f wymaga polityk i procedur oceny skuteczności środków zarządzania ryzykiem.

Dostawcy chmury, centrów danych, usług zarządzanych i inne podmioty wymienione w rozporządzeniu wykonawczym (UE) 2024/2690 stosują w ramach SZBI jego środki (art. 8b ust. 1 ustawy o KSC, obowiązki z rozdziału 3 od 3 kwietnia 2027). Załącznik (pkt 6.5) wymaga polityki testów bezpieczeństwa, która określa potrzebę, zakres i częstotliwość testów, a motyw 15 wymienia wśród nich testy penetracyjne.

W obu przypadkach musicie pokazać zakres, metodykę i to, co naprawiliście. Dlatego raport i retest są tak samo ważne jak dni testów. Co się dzieje, gdy nikt nie testuje, opisujemy w artykule o wyciekach danych i ich skutkach.

Jak zebrać wyceny pentestu, które da się porównać

Zanim zapytacie o ceny, spiszcie cele, role użytkowników, dokumentację API, zakresy IP i konta w chmurze, a także wybierzcie środowisko i okno testu. Wyślijcie tę samą listę do każdego dostawcy i poproście na piśmie o dni na cel, metodykę, skład zespołu, zawartość raportu i warunki retestu. Zobaczcie też, jak prowadzimy testy penetracyjne, albo napiszcie do nas, jeśli chcecie omówić zakres.