Jak porównać oferty na testy penetracyjne - zapytanie ofertowe i pytania do dostawcy

Oferta na test penetracyjny to nie produkt z półki, tylko opis pracy, którą ktoś wykona na Twoim systemie. Dwie oferty z tym samym nagłówkiem "test penetracyjny aplikacji" mogą opisywać zupełnie różne usługi: jedna - automatyczny skan z raportem z narzędzia, druga - kilka dni ręcznych testów z kontami dla każdej roli i retestem po naprawach. Przy takich różnicach porównywanie samych kwot nie ma sensu.

Poniżej znajdziesz checklistę zapytania ofertowego, tabelę do porównania ofert, pytania, które warto zadać dostawcy, i sygnały ostrzegawcze. Czynniki, od których zależy cena, opisujemy osobno w czynnikach wyceny testów penetracyjnych. Tutaj skupiamy się na tym, jak sprawdzić, czy oferty w ogóle opisują to samo.

Dlaczego oferty na testy penetracyjne trudno porównać

Test penetracyjny nie ma jednego, standardowego zakresu. Każdy dostawca wycenia to, co zrozumiał z zapytania, i dopisuje założenia, których zamawiający często nie zauważa. Najczęstsze źródła różnic:

• Zakres celów. Jedna oferta obejmuje aplikację webową, druga także API, z którego korzysta aplikacja mobilna, a trzecia tylko adresy widoczne z internetu.
• Podejście. Test black box sprawdza to, co widać bez logowania. Test grey box obejmuje funkcje dostępne po zalogowaniu, a white box dodaje dostęp do kodu i dokumentacji. To trzy różne usługi, a nie trzy warianty tej samej.
• Liczba ról. Każdą funkcję trzeba sprawdzić z perspektywy każdej roli - klienta, pracownika, administratora, partnera. Oferta, która zakłada jedną rolę, będzie krótsza, ale nie sprawdzi, czy klient nie widzi danych innego klienta.
• Proporcja pracy ręcznej i automatycznej. Skan podatności jest szybki i powtarzalny, ale nie wykrywa błędów logiki biznesowej i uprawnień.
• Retest. Bywa w cenie, bywa płatny osobno, a bywa, że nie ma go wcale.
• Raport. Od eksportu wyników z narzędzia po dokument z dowodami, krokami odtworzenia, oceną ryzyka i częścią dla zarządu.

Przykład demonstracyjny: trzy oferty na ten sam portal

Załóżmy, że firma prosi trzech dostawców o "test penetracyjny portalu klienta" i nie podaje nic więcej. Przykład jest demonstracyjny - nie opisuje żadnego konkretnego projektu ani dostawcy.

Wszystkie trzy to "test penetracyjny portalu", ale tylko oferta B sprawdzi, czy zalogowany klient może odczytać cudze dane. Taki błąd to IDOR, a kategoria błędów kontroli dostępu, do której należy, zajmuje pierwsze miejsce na liście OWASP Top 10:2025.

Jak przygotować zapytanie ofertowe na test penetracyjny

Najprostszy sposób na porównywalne oferty to jedno zapytanie, wysłane do wszystkich dostawców w tej samej treści. Podstawowe dane, o które i tak zapyta każdy dostawca, wymieniamy w checkliście zapytania w cenniku. Poniższa lista idzie dalej: opisuje też oczekiwania co do metodyki, raportu, zasad testów i formy odpowiedzi.

Checklista zapytania ofertowego (do wydruku)

Skopiuj listę do zapytania albo wydrukuj tę stronę i odhaczaj kolejne punkty:

1. Cel testu - np. odbiór nowego systemu, wymóg klienta, przygotowanie do audytu, test po dużej zmianie.
2. Lista celów - adresy, domeny, zakresy IP, aplikacje mobilne, repozytoria; osobno to, czego testować nie wolno.
3. Role użytkowników - lista ról i przybliżona liczba funkcji, ekranów lub procesów w każdej z nich.
4. API - specyfikacja OpenAPI lub schemat GraphQL, a przynajmniej liczba endpointów i wersji interfejsu.
5. Oczekiwane podejście - black box, grey box, white box albo prośba, by dostawca je zaproponował i uzasadnił.
6. Środowisko - testowe czy produkcyjne, okna czasowe, WAF i inne zabezpieczenia, systemy utrzymywane przez zewnętrznego dostawcę (hosting, chmura).
7. Metodyka - prośba o wskazanie standardów i ich wersji.
8. Raport - język (PL, EN), część dla zarządu, dowody techniczne, ocena powagi z podaną wersją skali, rekomendacje naprawy.
9. Retest - czy jest w ofercie, w jakim czasie po raporcie można z niego skorzystać i czy obejmuje każdą podatność.
10. Zasady testów - kto po Twojej stronie podpisuje zgodę na test, kontakt awaryjny, ograniczenia (np. bez testów obciążeniowych).
11. Poufność i dane - NDA, sposób przekazania raportu, przechowywanie i usunięcie danych z testu.
12. Formalności - ubezpieczenie OC, wymagane umowy, informacja o podwykonawcach.
13. Wymagania regulacyjne - DORA, NIS2/KSC, wymagania klienta lub audytora, które raport ma wspierać.
14. Termin - kiedy test może się zacząć i kiedy potrzebujesz raportu.
15. Struktura odpowiedzi - prośba, by oferta opisała w tej kolejności: zakres, podejście, metodykę, szacowany nakład pracy, harmonogram, raport, retest i wyłączenia.

Ostatni punkt oszczędza najwięcej czasu, bo oferty w tej samej strukturze przepiszesz do jednej tabeli. Jeśli kupujesz w trybie zamówień publicznych, ta sama lista dobrze sprawdza się jako szkielet opisu przedmiotu zamówienia (OPZ).

Tabela porównania ofert testów penetracyjnych

Gdy oferty wrócą, przepisz je do jednej tabeli. Dla każdego kryterium sprawdź, czy oferta odpowiada wprost, i zanotuj, czego w niej brakuje.

Tabela pokaże, które różnice wynikają z zakresu, a które z jakości usługi.

Pytania do dostawcy testów penetracyjnych

Tabela mówi, co porównać. Poniższe pytania pomagają sprawdzić, czy za odpowiedziami w ofercie stoi praktyka.

Metodyka i wersje standardów

Zapytaj, według jakich standardów dostawca testuje i w jakich wersjach. Dla aplikacji webowych podstawą jest zwykle OWASP Web Security Testing Guide (WSTG v4.2), ramy procesu opisuje PTES, a testy infrastruktury - NIST SP 800-115. Klasyfikację ryzyk dają OWASP Top 10:2025, OWASP API Security Top 10 2023 i, dla aplikacji mobilnych, OWASP MASVS 2.1, a wymagania weryfikacyjne - OWASP ASVS 5.0.

Konkretne wersje to dobry test aktualności. Oferta, która w 2026 roku powołuje się na edycję 2021 listy OWASP Top 10 jako aktualną, najpewniej powstała z dawno nieaktualizowanego szablonu.

Raport i przykładowy raport

Poproś o przykładowy, zanonimizowany raport albo jego fragment. Sprawdź w nim:

• czy każde ustalenie ma dowód techniczny i kroki odtworzenia,
• czy ocena CVSS ma podaną wersję i wektor, a nie tylko liczbę,
• czy rekomendacje dotyczą konkretnej podatności, a nie są skopiowane z ogólnego opisu,
• czy jest część dla zarządu, która językiem biznesowym wskazuje priorytety,
• w jakim języku dostaniesz raport.

Jak może wyglądać opis jednej podatności, pokazujemy na przykładzie demonstracyjnym na stronie testów penetracyjnych aplikacji webowych, a z jakich części składa się nasz raport - w opisie raportu z testu penetracyjnego.

Retest

Zapytaj, czy retest obejmuje każdą zgłoszoną podatność, w jakim czasie po raporcie można z niego skorzystać i czy po nim dostaniesz zaktualizowany raport. Bez retestu raport opisuje stan sprzed napraw - a to właśnie ten dokument zobaczy później Twój klient lub audytor.

Zasady testów na piśmie

Przed startem obie strony powinny podpisać zgodę na test z zakresem, oknami czasowymi, adresami, z których testują testerzy, i kontaktem awaryjnym. To nie formalność: dostęp do systemu bez uprawnienia czy zakłócanie jego pracy mogą być przestępstwami z art. 267-269b Kodeksu karnego, a pisemne zlecenie dysponenta systemu odróżnia test od ataku.

Zapytaj też, czego dostawca nie robi na produkcji - np. testów obciążeniowych czy modyfikacji danych. Nasze zasady opisujemy w części o gwarancji nieinwazyjności testów. Gdy system działa u zewnętrznego dostawcy, np. w chmurze lub na hostingu, sprawdź, czy jego zasady pozwalają na testy i czy trzeba je wcześniej zgłosić.

Ubezpieczenie OC i odpowiedzialność

Zapytaj, czy dostawca ma ubezpieczenie odpowiedzialności cywilnej obejmujące usługi testów i jak umowa ogranicza odpowiedzialność stron. Umowa powinna jasno mówić, kto odpowiada, jeśli coś pójdzie nie tak.

NDA i ochrona danych z testu

Raport z pentestu to mapa słabych punktów Twojego systemu. Zapytaj:

• czy dostawca podpisze NDA przed rozmową o szczegółach systemu,
• jak przekazuje raport i czy go szyfruje,
• gdzie przechowuje dowody, zrzuty ekranu i dane dostępowe do kont testowych,
• kiedy i jak usuwa dane z testu po zakończeniu projektu.

Jeśli tester może w trakcie testu zetknąć się z danymi osobowymi, ustal z dostawcą, czy potrzebna jest umowa powierzenia przetwarzania danych. Najprościej jednak testować na środowisku z danymi przykładowymi.

Kto wykonuje test

Zapytaj, czy test wykonują pracownicy dostawcy czy podwykonawcy, jakie doświadczenie ma zespół w systemach podobnych do Twojego - pod względem technologii, branży i rodzaju aplikacji - i czy retest wykona ta sama osoba. Poproś też o kontakt do osoby technicznej, która w trakcie testu odpowie na pytania Twojego zespołu i wstrzyma prace, jeśli system zachowa się nieoczekiwanie.

Czerwone flagi w ofertach na testy penetracyjne

Część sygnałów ostrzegawczych widać już w ofercie, inne dopiero w rozmowie. Te pięć powinno wstrzymać decyzję do czasu wyjaśnienia:

1. Skan sprzedawany jako pentest. Oferta wymienia narzędzia, ale nie opisuje testów ręcznych ani scenariuszy logiki biznesowej. Raport z samego skanera zawiera fałszywe alarmy i pomija błędy uprawnień.
2. Brak dowodów w raporcie. Ustalenie bez dowodu i kroków odtworzenia trudno naprawić, a jeszcze trudniej obronić przed audytorem.
3. Sama punktacja CVSS bez kontekstu. Wynik bazowy opisuje powagę podatności w oderwaniu od Twojego systemu. Ta sama luka znaczy co innego w systemie płatności, a co innego w narzędziu wewnętrznym bez danych osobowych.
4. Brak pisemnych zasad testu. Dostawca gotowy zacząć bez zgody dysponenta systemu, zakresu i kontaktu awaryjnego naraża obie strony na ryzyko prawne i operacyjne.
5. Brak części dla zarządu. Bez podsumowania językiem biznesowym zarząd nie zobaczy priorytetów i trudniej mu będzie zdecydować o budżecie napraw.

Ostrożności wymagają też obietnice wyniku ("po teście nie będzie żadnych podatności") i zakres bez granic ("testujemy wszystko"). Zestawienie sygnałów z pytaniami kontrolnymi znajdziesz w części cennika o wyborze najtańszej oferty.

Jak ocenić wycenę bez porównywania samej kwoty

Cena ma sens dopiero w odniesieniu do zakresu. Zanim porównasz kwoty, sprowadź oferty do wspólnego mianownika:

1. Wyrównaj zakres. Jeśli jedna oferta nie obejmuje API albo części ról, poproś o uzupełnienie albo porównuj pozostałe oferty bez tych elementów. Wtedy zestawiasz ten sam test.
2. Porównaj nakład pracy i harmonogram. Poproś o szacowany czas testów w podziale na części, np. aplikacja, API, retest. Różnice w nakładzie przy tym samym zakresie dostawca powinien umieć wyjaśnić.
3. Sprawdź wyłączenia. Retest, raport w drugim języku, prezentacja wyników czy testy poza godzinami pracy mogą być dopisane drobnym drukiem jako płatne osobno.
4. Policz koszt całego cyklu. Do ceny testu dolicz retest i czas Twojego zespołu na przygotowanie środowiska, kont i dokumentacji. Raport, który trzeba uzupełniać albo powtarzać, kosztuje więcej, niż wynikało z oferty.
5. Ustal wagi kryteriów przed otwarciem ofert. Zdecyduj, ile znaczą dla Ciebie zakres, jakość raportu, retest i termin, zanim zobaczysz kwoty - wtedy cena nie przesłoni reszty.

Skąd biorą się różnice w wycenach - z liczby ról i endpointów, podejścia, środowiska czy retestu - wyjaśniamy w części cennika o czynnikach wyceny. Jeśli oferty po wyrównaniu zakresu nadal wyraźnie się różnią, zapytaj dostawców wprost o powód - dobra odpowiedź jest konkretna.

Jak możemy pomóc

Na zapytanie o test penetracyjny odpowiadamy w ciągu 24 godzin w dni robocze, a ofertę przygotowujemy po krótkiej rozmowie zakresowej - z zakresem, podejściem, metodyką, raportem i retestem rozpisanymi tak, żeby dało się ją porównać z innymi. Na życzenie najpierw podpisujemy NDA. Testujemy aplikacje webowe i mobilne, API, infrastrukturę, chmurę i kod źródłowy - zakres opisujemy na stronie testów penetracyjnych. Zanim wyślesz zapytanie, zobacz cennik i czynniki wyceny testów penetracyjnych.