Cena testów penetracyjnych wynika z nakładu pracy potrzebnego do zbadania konkretnego środowiska, dlatego żaden dostawca nie publikuje sztywnego cennika ani jednej stawki za usługę. Wycena powstaje dopiero po ustaleniu zakresu i sprowadza się do oszacowania, ile dni pracy certyfikowanych specjalistów pochłonie zbadanie wskazanych systemów. Dla pojedynczej aplikacji albo średniej wielkości sieci badanie zajmuje zwykle kilka do kilkunastu dni roboczych, a rozbudowane środowiska wymagają odpowiednio dłuższego planu. Ten sam zakres wyceniony przez dwóch dostawców może się różnić, ponieważ każdy z nich inaczej szacuje pracochłonność i głębokość analizy.
Pytanie o to, ile kosztuje test penetracyjny, ma sens dopiero wtedy, gdy wiadomo, co dokładnie ma zostać przetestowane i jak głęboko. Porównywanie samych cen bez porównania zakresów prowadzi do złych decyzji zakupowych. Poniżej znajdziesz czynniki, które realnie podbijają albo obniżają koszt testów penetracyjnych, modele rozliczeń stosowane na rynku oraz listę pytań, które warto zadać dostawcy przed podpisaniem umowy.
Testy penetracyjne – cena i najważniejsze czynniki wpływające na koszt
Na wycenę testów penetracyjnych wpływają przede wszytskim trzy czynniki: rozmiar zakresu, złożoność badanego środowiska oraz wymagany poziom szczegółowości analizy. Każdy z nich przekłada się na liczbę dni pracy zespołu, dlatego dwa środowiska o podobnej wielkości mogą zostać wycenione zupełnie inaczej. Poniżej rozkładamy te czynniki na konkretne parametry, które dostawca musi poznać, żeby przygotować wiążącą ofertę.
Zakres systemów, aplikacji i infrastruktury objętej testem
Zakres testów penetracyjnych najsilniej wpływa na cenę, ponieważ wyznacza liczbę zasobów do zbadania. W zapytaniu ofertowym warto więc podać:
- liczbę publicznych adresów IP oraz hostów wchodzących w zakres,
- liczbę domen i subdomen, łącznie z zapomnianymi środowiskami testowymi wystawionymi do internetu,
- liczbę aplikacji i ról użytkowników w każdej z nich,
- liczbę endpointów API przewidzianych do przetestowania,
- rodzaj testowanych zasobów, czyli aplikacje webowe, API, aplikacje mobilne lub infrastruktura serwerowo-sieciowa,
- perspektywę badania, ponieważ testy zewnętrzne obejmują zasoby dostępne z internetu, a testy z wnętrza sieci wymagają dostępu do infrastruktury wewnętrznej.
Każda z tych liczb mnoży pracę w sposób, którego nie widać na pierwszy rzut oka. Aplikacja z pięcioma rolami użytkowników wymaga sprawdzenia uprawnień w każdej kombinacji dostępu, dlatego kosztuje wielokrotnie więcej niż aplikacja z jednym typem konta, choć w zapytaniu obie występują jako „jedna aplikacja”. Podobnie działa liczba integracji zewnętrznych, bo zabezpieczenia systemów trzeba wtedy sprawdzić również na styku z partnerami.
Rodzaj zasobu zmienia też skład zespołu i użyte techniki testowania. Testy penetracyjne aplikacji mobilnych wymagają analizy dwóch platform i sposobu komunikacji aplikacji z backendem, co oznacza inny nakład pracy niż zbadanie tej samej funkcjonalności w wersji przeglądarkowej. Wycena rośnie więc nie tylko wraz z liczbą zasobów, ale też z ich różnorodnością technologiczną.
Stopień złożoności środowiska oraz wymagany poziom analizy
Złożoność architektury decyduje o tym, ile czasu zajmuje zrozumienie środowiska przed rozpoczęciem właściwej pracy. Monolityczna aplikacja na standardowym stosie technologicznym jest przewidywalna, natomiast środowisko rozproszone wymaga zmapowania zależności między komponentami, zanim tester zacznie szukać podatności. Na ten czas wpływają przede wszystkim:
- liczba integracji z systemami zewnętrznymi i wewnętrznymi,
- architektura mikroserwisowa zamiast pojedynczej aplikacji,
- mechanizmy uwierzytelniania, w szczególności SSO i federacja tożsamości,
- niestandardowa technologia lub autorskie rozwiązania bez publicznej dokumentacji,
- poziom udostępnionego dostępu, czyli obecność kont testowych o wszystkich rolach,
- decyzja o testowaniu na środowisku produkcyjnym, która wymaga ostrożniejszego tempa pracy.
Osobnym parametrem jest wymagany poziom szczegółowości:
- black-box ogranicza wiedzę testera do informacji zdobytych samodzielnie,
- grey-box daje wybrane dane dostępowe i kontakt z administratorami,
- white-box zakłada wgląd w kod, konfigurację i dokumentację.
Ostatni z tych wariantów jest najbardziej czasochłonny, ponieważ pozwala wykryć subtelne podatności wymagające szczegółowej wiedzy o celu, i to przekłada się bezpośrednio na wycenę.
Wymagania regulacyjne działają w tę samą stronę. RODO w art. 32 ust. 1 lit. d nakazuje regularne testowanie, mierzenie i ocenianie skuteczności zabezpieczeń, a DORA, ISO 27001, NIS2 oraz PCI-DSS dodają własne oczekiwania co do zakresu i udokumentowania badania. Organizacja podlegająca kilku regulacjom jednocześnie potrzebuje głębszej analizy podatności i obszerniejszej dokumentacji, co oznacza więcej dni pracy niż w przypadku testu zamówionego wyłącznie na potrzeby wewnętrzne.
Ile kosztuje test penetracyjny i jak wygląda jego wycena?
Wycena testów penetracyjnych powstaje na podstawie oszacowanego nakładu pracy, wyrażonego w dniach roboczych zespołu. Dostawca przelicza zakres i złożoność środowiska na czas potrzebny do zbadania każdego zasobu, dlatego wiążącą ofertę może przygotować dopiero po poznaniu szczegółów. Forma rozliczenia bywa natomiast różna i to ona rozstrzyga, kto ponosi ryzyko przekroczenia zaplanowanego czasu.
Modele rozliczeń stosowane przy wycenie testów penetracyjnych
Model rozliczenia określa sposób zapłaty za czas pracy zespołu, nie zaś zakres samego badania. Na rynku usług bezpieczeństwa spotyka się trzy podstawowe warianty:
- stała cena za projekt (fixed price) – kwota ustalona z góry dla zdefiniowanego zakresu, wymaga dokładnego scopingu przed podpisaniem umowy,
- rozliczenie za czas pracy (time & material) – płatność za faktycznie przepracowane dni, stosowana wtedy, gdy zakresu nie da się zamknąć na starcie,
- pakiet dni w cyklu (retainer) – z góry zarezerwowana dostępność zespołu, wykorzystywana przy badaniach powtarzanych regularnie.
Stała cena daje przewidywalny budżet i przenosi ryzyko niedoszacowania na dostawcę, dlatego wybierają ją organizacje rozliczające bezpieczeństwo w ramach zamkniętego budżetu projektowego. Rozliczenie za czas pracy bywa korzystniejsze przy środowiskach słabo udokumentowanych, gdzie żadna ze stron nie potrafi z góry przewidzieć pracochłonności. Trzeci wariant sprawdza się przy cyklicznym harmonogramie testów, bo skraca czas oczekiwania na dostępność zespołu.
Budżet na testy warto planować razem z pozostałymi wydatkami na bezpieczeństwo. Organizacje, które rozkładają badania na cały rok, częściej powierzają priorytetyzację takich wydatków modelowi CISO as a Service, ponieważ kolejność testowania systemów wynika wtedy z oceny ryzyka, a nie z przypadkowej dostępności środków.
Dlaczego cena pentestu jest ustalana indywidualnie dla każdego projektu?
Cena pentestu jest ustalana indywidualnie, bo nie ma dwóch identycznych środowisk IT. Ta sama liczba aplikacji może oznaczać kilka dni pracy albo kilka tygodni, w zależności od technologii, liczby ról i wymaganej głębokości analizy. Sztywny cennik prowadziłby więc do jednego z dwóch skutków: przepłacania przy prostych zakresach albo powierzchownego badania przy złożonych.
Na indywidualny charakter wyceny wpływa kilka czynników po stronie dostawcy:
- skład zespołu dobierany do technologii, ponieważ inne kompetencje wymaga badanie API, a inne aplikacji mobilnej,
- kwalifikacje testerów, czyli certyfikowani specjaliści z uprawnieniami OSCP, OSWE, OSED, OSWP czy GXPN,
- przyjęte standardy pracy – OWASP, PTES, OSSTMM i NIST, wyznaczające minimalny zakres kontroli do wykonania,
- ocena ryzyka uzgodniona z klientem, wskazująca systemy krytyczne wymagające najdokładniejszego zbadania,
- termin realizacji, bo harmonogram zespołu planowany jest z wyprzedzeniem, a pilne zlecenia trudniej wpasować w kalendarz.
Aby rzetlenie porównać oferty, warto zapytać o liczbę dni roboczych przewidzianych na badanie, wariant testu, udział pracy manualnej w stosunku do skanów automatycznych, język i strukturę raportu oraz o to, czy retest wchodzi w cenę podstawową.
Cennik testów penetracyjnych – co obejmuje koszt usługi?
Koszt usługi obejmuje trzy bloki pracy: przygotowanie badania, testy właściwe oraz opracowanie raportu. Pozycje takie jak retest, prezentacja wyników czy warsztaty wyceniane są osobno, dlatego przy porównywaniu ofert trzeba sprawdzić, co mieści się w cenie podstawowej. Ta różnica potrafi zdecydować o tym, która oferta okaże się tańsza po zamknięciu projektu.
Prace przygotowawcze, testy bezpieczeństwa i raport końcowy
Prace przygotowawcze pochłaniają czas jeszcze przed pierwszym testem. Ustalenie zakresu, uzgodnienie zasad, konfiguracja dostępów i weryfikacja kont testowych wymagają udziału obu stron, a im mniej dokumentacji dostarczy zamawiający, tym więcej godzin zespół poświęci na samodzielne rozpoznanie środowiska. Ten blok bywa niewidoczny w ofercie, choć wpływa na jej wysokość.
Testy właściwe to największa pozycja w wycenie, ponieważ obejmują pracę manualną. Analiza podatności oparta wyłącznie na skanerach automatycznych kosztuje niewiele i daje listę hipotez zamiast potwierdzonych błędów, natomiast ręczna weryfikacja każdego zgłoszenia i testowanie scenariuszy specyficznych dla danej aplikacji zajmuje dni pracy. Proporcja między jednym a drugim to najważniejsza informacja przy ocenie, czy oferta jest tania, czy tylko pozornie korzystna. Jeśli chcesz zobaczyć, jaka praca stoi za każdym z tych bloków, opisaliśmy osobno, jak krok po kroku przebiega test penetracyjny.
Raport końcowy odpowiada za spory udział w końcowej cenie, choć zamawiający rzadko to zakładają. Opracowanie podsumowania managerskiego i szczegółowej części technicznej z planem naprawczym wymaga osobnych dni pracy, a wycena rośnie wraz z wymaganiami dotyczącymi jego formy. Na koszt wpływają tu:
- język raportu, w wersji polskiej albo angielskiej, lub w obu,
- liczba odbiorców dokumentu, ponieważ część zarządcza i część techniczna pisane są innym językiem,
- poziom szczegółowości rekomendacji, od ogólnych wskazań po konkretne zmiany w konfiguracji i kodzie,
- wymagania audytora, jeśli raport ma stanowić dowód zgodności w procesie certyfikacji.
Retest podatności oraz dodatkowe usługi wpływające na końcową cenę
Retest podnosi końcową cenę, bo stanowi opcjonalny dodatek do pakietu podstawowego. Warto zdecydować o nim już przy ustalaniu zakresu, ponieważ dopisanie tej pozycji po zakończeniu projektu oznacza ponowne planowanie dostępności zespołu. Brak retestu obniża fakturę, ale zostawia organizację bez potwierdzenia, że wdrożone poprawki faktycznie usunęły podatności.
Poza retestem wycenę zwiększają pozycje zamawiane najczęściej przez organizacje raportujące wyniki poza działem IT:
- prezentacja wyników dla zarządu lub komitetu ryzyka,
- warsztaty z zespołem deweloperskim omawiające znalezione błędy,
- code review i testy w wariancie white-box tam, gdzie zwiększają wartość badania,
- cykliczne powtarzanie testów w ustalonym harmonogramie rocznym.
Koszt naprawy podatności rośnie wraz z etapem, na którym zostaje wykryta. Błąd znaleziony w gotowej, wdrożonej aplikacji wymaga zmiany kodu, testów regresyjnych i ponownego wdrożenia, dlatego organizacje wytwarzające oprogramowanie własnymi zespołami ograniczają te wydatki, wbudowując kontrole bezpieczeństwa w cykl developmentu w ramach Konsultacji SSDLC.
Część wydatków warto skierować poza warstwę techniczną. Testy penetracyjne sprawdzają zabezpieczenia systemów, natomiast nie zmieniają zachowań pracowników, którzy pozostają najczęstszym punktem wejścia do organizacji, dlatego naturalnym uzupełnieniem budżetu jest Praktyczny Trening Antyphishingowy Secawa, przez którego platformę przeszło już ponad 150 000 pracowników.
Uzyskaj wycenę testów penetracyjnych dla Twoich systemów
