Ile kosztuje test penetracyjny i od czego zależy cena

Na pytanie „ile kosztuje test penetracyjny” większość dostawców odpowiada „to zależy”. To prawda, która nie pomaga zaplanować budżetu. Poniżej rozkładamy tę odpowiedź na części: w czym mierzy się pracochłonność, co konkretnie ją podnosi, ile trwa projekt i dlaczego dwie oferty na ten sam system potrafią różnić się dwukrotnie.

Cennika za sztukę nie publikujemy i nie jest to unik. Dwa sklepy internetowe, opisane w zapytaniu tym samym zdaniem, potrafią różnić się pracochłonnością kilkukrotnie. Publikujemy za to jednostkę, w której ta praca jest naprawdę mierzona, i listę rzeczy, które nią poruszają. Z tym da się policzyć własny zakres i uczciwie porównać cudzą ofertę.

Dlaczego „cena za aplikację” to złe pytanie

„Aplikacja” nie jest jednostką pracy. Pod tym samym słowem kryje się strona z formularzem kontaktowym i portal z trzema typami kont, płatnościami, wgrywaniem plików i czterdziestoma endpointami API. Test pierwszej zamyka się w dwóch dniach. Test drugiej to kilkanaście osobodni i nadal trzeba zdecydować, czego nie sprawdzamy.

Dostawca, który podaje cenę za aplikację przed poznaniem zakresu, robi jedną z dwóch rzeczy: doliczył margines na najgorszy scenariusz albo policzył najlepszy i zetnie zakres w trakcie prac. Obie kończą się tak samo – rozmową o aneksie w połowie projektu.

Pytanie, które daje porównywalne odpowiedzi, brzmi inaczej: ile osobodni potrzeba na mój zakres i co dokładnie ten zakres obejmuje. Reszta artykułu jest o tym, jak to policzyć.

Jednostka wyceny to osobodzień

Osobodzień to jeden dzień pracy jednego pentestera. W tej jednostce planuje się prace, w niej rozlicza się zespół i tylko ona pozwala zestawić dwie oferty obok siebie. Poniżej orientacyjna pracochłonność i czas realizacji dla typowych zakresów.

Dwie kolumny mierzą różne rzeczy i warto ich nie mylić. Pracochłonność to sama praca pentesterów. Czas realizacji obejmuje też ustalenia przed testem, uzgodnienia dostępów po Twojej stronie i napisanie raportu. Typowy projekt mieści się w 5–15 osobodniach – co za te dni dostajesz, opisujemy na stronie testów penetracyjnych.

Co naprawdę porusza wycenę

Liczba ról i uprawnień

Największa pojedyncza pozycja w wycenie aplikacji. Trzy typy kont to nie jest ta sama aplikacja co jedno konto: testy autoryzacji trzeba przejść osobno dla każdej roli, a potem jeszcze krzyżowo. Przy trzech rolach daje to sześć kierunków dostępu do sprawdzenia – czy użytkownik sięgnie po dane innego użytkownika, czy zwykłe konto dojdzie do funkcji administratora, czy konto po wylogowaniu nadal coś widzi.

Dlatego w zapytaniu liczba ról waży więcej niż liczba ekranów. Podaj ją od razu i przygotuj konta testowe dla każdej z nich.

Liczba endpointów API i funkcji

Dziesięć formularzy to nie dziesięciokrotność jednego, ale też nie to samo. W API jednostką nie jest ekran, tylko endpoint – każdy z własnymi metodami, parametrami i regułami autoryzacji.

Tu można obniżyć wycenę bez cięcia zakresu: przekaż dokumentację. Kolekcja Postman albo specyfikacja OpenAPI skraca rekonesans o godziny, które inaczej idą na odgadywanie, jakie endpointy w ogóle istnieją. Ten sam czas wraca do testów logiki biznesowej, czyli do miejsca, gdzie znajdują się najpoważniejsze podatności.

Liczba adresów IP i hostów

W testach infrastruktury liczy się liczba żywych hostów i wystawionych usług, a nie rozmiar puli adresowej. Sieć /24 z dwunastoma działającymi serwerami to mniej pracy niż sześćdziesiąt hostów rozrzuconych po trzech lokalizacjach.

W zapytaniu podaj listę adresów IP i zakresów, a osobno – co na nich stoi. Kontroler domeny, serwer pocztowy i systemy przemysłowe to trzy różne poziomy ostrożności i trzy różne nakłady pracy.

Model testu i dostęp do kodu

Tu intuicja myli się najczęściej: im mniej wiemy o systemie na starcie, tym drożej.

• Black box jest najdroższy. Pentester zaczyna z zerową wiedzą, więc rekonesans zjada część budżetu, zanim ktokolwiek dotknie właściwych testów.
• Grey box to najczęstszy wybór. Konta użytkowników i podstawowy opis systemu wystarczą, żeby przejść od razu do rzeczy.
• White box daje najwięcej znalezisk na osobodzień. Kod źródłowy, schematy i konta administracyjne pozwalają dojść do błędów, do których atak z zewnątrz dokopałby się po tygodniu albo wcale.

Model dobiera się do tego, czego organizacja się obawia, a nie do budżetu – rozpisaliśmy to w artykule co to jest test penetracyjny.

Środowisko produkcyjne czy testowe

Test na produkcji wymaga ostrożności i to kosztuje czas: okno poza godzinami szczytu, uzgodnienia z zespołem utrzymania, wyłączenie części technik, plan wycofania zmian. Środowisko testowe zdejmuje większość tych ograniczeń – pod jednym warunkiem: musi być kopią produkcji, a nie wersją sprzed pół roku z wyłączoną integracją płatności. Test środowiska, które nie odpowiada produkcji, jest tańszy i bezwartościowy.

Udział pracy manualnej

Tutaj dwie oferty rozjeżdżają się najmocniej i tutaj porównanie jest najtrudniejsze.

Skaner przechodzi przez system automatycznie i wypisuje to, co ma w bazie. Jest tani, szybki i wyłapuje znane podatności. Nie zrozumie natomiast logiki aplikacji – nie zauważy, że konto A widzi zamówienia konta B, bo nie wie, że nie powinno.

Test manualny prowadzi człowiek, który tę logikę rozumie i celowo próbuje ją obejść. Znajduje błędy autoryzacji i reguł biznesowych, a pojedyncze drobiazgi łączy w jeden poważny scenariusz. Kosztuje wielokrotnie więcej, bo jest wielokrotnie większą pracą. Różnicę między obiema metodami rozkładamy w artykule skanowanie podatności a testy penetracyjne.

Jeśli jedna oferta jest wyraźnie tańsza od pozostałych, pierwsze pytanie brzmi: ile z tego jest pracą manualną?

Forma raportu i wymagania regulacyjne

Raport jest produktem, a nie efektem ubocznym. Między eksportem ze skanera a materiałem, z którego da się zrobić plan naprawczy, leży kilka osobodni pracy – i to ta różnica decyduje, czy Twój audytor uzna wynik za dowód.

Pracochłonność podnosi też przypisanie podatności do konkretnych wymagań: załącznika A normy ISO/IEC 27001 (zarządzanie podatnościami technicznymi, A.8.8), wymagań PCI DSS albo art. 8 ust. 1 pkt 2 lit. b ustawy o krajowym systemie cyberbezpieczeństwa, który każe objąć systemem zarządzania bezpieczeństwem informacji także „testowanie systemu informacyjnego”.

Retest i powtarzalność

Po wdrożeniu poprawek trzeba sprawdzić, czy działają. Retest nie jest powtórzeniem całego testu – sprawdza wyłącznie zgłoszone miejsca. U nas jest w cenie i to samo warto ustalić u każdego innego dostawcy, bo bywa osobną pozycją.

Powtarzalność działa w drugą stronę niż większość kosztów: obniża je. Przy drugim i trzecim teście tego samego środowiska rekonesans jest krótszy, a zespół zna architekturę i historię poprzednich znalezisk. Umowa na cykl testów wychodzi taniej niż trzy jednorazowe zamówienia rozłożone na te same trzy lata.

Co nie zmienia ceny

Wielkość firmy. Testujemy system, a nie sprawozdanie finansowe. Mała firma ze złożonym portalem zapłaci więcej niż duża ze zwykłą stroną.

Liczba znalezionych podatności. Płacisz za pracę, nie za wynik. Dostawca rozliczany od znaleziska ma interes w zawyżaniu poziomu ryzyka.

To, czy jesteś „atrakcyjnym celem”. Argument z prezentacji handlowej, nie z planowania budżetu. Atakujący dobierają cele według najmniejszego oporu, a nie według wielkości.

Ile trwa test penetracyjny

Projekt składa się z trzech etapów i tylko środkowy to testy.

1. Ustalenia przed testem – spisanie zakresu, zasad prowadzenia testu i wyłączeń, przekazanie kont i dostępów. Kilka dni, zwykle po stronie klienta.
2. Testy – 3–15 osobodni zależnie od zakresu.
3. Raport – mniej więcej jedna piąta czasu projektu. Powstaje po testach, a nie w ich trakcie.

W sumie od startu do raportu projekt trwa zwykle 1–3 tygodnie. Retest dochodzi później, po wdrożeniu poprawek, i zajmuje ułamek pierwotnej pracochłonności.

W praktyce najdłuższy bywa nie sam test, tylko termin startu. Zespoły z obłożonym kalendarzem podają terminy kilka tygodni do przodu, więc jeśli raport ma być gotowy na audyt albo na przetarg, rozmowę o zakresie zaczyna się z zapasem.

Zapytanie ofertowe, które da się wycenić

Wycena bez zakresu to zgadywanka, a porównanie dwóch takich zgadywanek nie mówi nic. Zapytanie, na które dostawcy odpowiedzą porównywalnie, zawiera:

• listę celów: domeny, adresy IP i zakresy, nazwy aplikacji, wersje mobilne;
• liczbę ról i zapewnienie kont testowych dla każdej z nich;
• liczbę endpointów API wraz z dokumentacją (OpenAPI, kolekcja Postman);
• model testu: black box, grey box lub white box, z informacją o dostępie do kodu;
• środowisko: produkcja czy kopia testowa, okna czasowe, techniki wyłączone z testu;
• metodykę i oczekiwane pokrycie – OWASP WSTG, ASVS i pozostałe standardy opisują głębokość testów konkretnie i sprawdzalnie;
• wymaganą formę i język raportu;
• retest: czy wchodzi w zakres i w jakim terminie po przekazaniu poprawek;
• termin realizacji i tryb kontaktu w trakcie prac.

Zapytanie z tą listą dostaje wyceny, które da się zestawić. Zapytanie bez niej dostaje wyceny różniące się dwukrotnie – i żadna z nich nie jest błędna.

Jak porównać dwie wyceny

Kiedy na stole leżą dwie wyceny, a jedna jest dwa razy wyższa od drugiej, prawie na pewno nie kupujesz tego samego. Pięć pytań, które to rozstrzygają:

1. Ile osobodni? Jeśli oferta nie podaje tej liczby, nie ma czego porównywać.
2. Jaki jest udział pracy manualnej? Pytaj wprost, to standardowe pytanie w tej branży.
3. Zgodnie z jaką metodyką i na jakim poziomie? Sam OWASP Top 10 to inne pokrycie niż OWASP ASVS na poziomie 2.
4. Kto konkretnie testuje i jakie ma certyfikaty? W pracy technicznej różnica między seniorem a juniorem polega na tym, co znajdą, a nie na tym, ile im to zajmie. Na co jeszcze patrzeć przy wyborze, piszemy w artykule etyczny haker.
5. Czy retest jest w cenie i do kiedy można go wykorzystać? Jeśli nie – doliczaj.

Oferta na 2 osobodni dla aplikacji z pięcioma rolami nie jest oszczędnością. To inny zakres, opisany tym samym zdaniem.

Kiedy tańsza usługa jest lepszym wyborem

Uczciwa odpowiedź brzmi: czasem test penetracyjny nie jest tym, czego potrzebujesz.

• Jeśli chodzi o bieżące pilnowanie znanych podatności w wielu systemach naraz, lepiej sprawdzi się powtarzana cyklicznie analiza podatności.
• Jeśli pytanie brzmi, czy pracownicy rozpoznają phishing, potrzebne są testy socjotechniczne, a nie test aplikacji.
• Jeśli chodzi o to, czy realny atakujący przeszedłby całą drogę do danych i czy ktokolwiek by to zauważył, rozmawiamy o red teamingu. Inna dyscyplina, inny budżet i sens dopiero wtedy, gdy oczywiste podatności są już usunięte.

Najdroższy test to ten zamówiony na niewłaściwy cel.

Czy test na potrzeby zgodności kosztuje więcej

Sam test nie. Cenę wyznacza zakres, a nie powód, dla którego test się odbywa. Zmienia się forma dowodu – układ raportu, przypisanie podatności do wymagań i potwierdzenie z retestu, które zamyka wątek. Mamy to w zakresie usługi.

Warto przy tym wiedzieć, jak testy penetracyjne wpisują się w audyt wymagany ustawą. Nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa (Dz.U. 2026 poz. 252, obowiązuje od 3 kwietnia 2026 r.) nakłada w art. 15 ust. 1 na podmioty kluczowe obowiązek audytu bezpieczeństwa systemu informacyjnego, na własny koszt, co najmniej raz na trzy lata. Sam audyt przeprowadza akredytowana jednostka oceniająca zgodność, sektorowy zespół CSIRT albo co najmniej dwóch audytorów z certyfikatami z listy Ministra Cyfryzacji. Do takiego audytu dostarczamy część techniczną: testy, opis podatności z dowodami, ocenę ryzyka, konkretne działania naprawcze i pisemne potwierdzenie z retestu – w formie, którą audytor przyjmuje bez dopytywania. Ten sam materiał zamyka wymóg z art. 8 ust. 1 pkt 2 lit. b, czyli testowanie systemu informacyjnego w ramach systemu zarządzania bezpieczeństwem informacji. Co to oznacza dla harmonogramu i budżetu, opisujemy na stronie testów penetracyjnych zgodnych z NIS2 i ustawą o KSC, a wątek certyfikacyjny na stronie testów penetracyjnych dla normy ISO 27001.

Po drugiej stronie rachunku stoi koszt braku testów i on też bywa policzalny. Prezes UODO nakładał kary, wskazując w uzasadnieniu brak regularnego testowania skuteczności zabezpieczeń – tak było w decyzji dotyczącej Morele.net (DKN.5130.2484.2019), wydanej na podstawie art. 32 ust. 1 lit. d RODO.

Co mamy w cenie

• Rozmowa o zakresie i spisane zasady prowadzenia testu.
• Testy manualne zgodnie z uznanymi metodykami, a nie sam skan.
• Raport z podsumowaniem dla kadry zarządzającej i częścią techniczną z dowodami.
• Konkretne zalecenia naprawcze zamiast odsyłaczy do dokumentacji producenta.
• Retest po wdrożeniu poprawek.
• Omówienie wyników z pentesterem, który prowadził test.

Stałą i niezobowiązującą wycenę przygotowujemy po krótkiej rozmowie o zakresie – umów ją tutaj.

Cena testu penetracyjnego – najczęstsze pytania

Powiązane usługi Haxoris: testy penetracyjne aplikacji i infrastruktury · analiza podatności systemów i aplikacji · Red Teaming – symulacja realnego ataku na organizację