Testy penetracyjne
Testy penetracyjne (pentesty) to symulacja ataku hakerskiego na sieci, aplikacje webowe, mobilne i desktopowe, API oraz infrastrukturę, prowadzona za zgodą firmy, żeby znaleźć i potwierdzić luki w zabezpieczeniach, zanim zrobi to napastnik. Pentestica wykonuje profesjonalne testy penetracyjne, według OWASP WSTG i PTES, od ponad 10 lat i w setkach projektów — każdy kończy się raportem z dowodem wykorzystania (PoC) i retestem.
Metodyka
Metodyki i standardy, według których testujemy
Definicję testu penetracyjnego i jego siedem etapów krok po kroku opisujemy we wpisie co to jest test penetracyjny (pentest). Na tej stronie skupiamy się na usłudze: co testujemy, jak pracujemy, ile to kosztuje i co dostajesz po teście.
Na tej stronie: rodzaje testów · przebieg krok po kroku · cennik · kto musi testować · przykłady z praktyki · opinie klientów · jak wybrać firmę · pytania i odpowiedzi.
Na jakich metodykach i standardach pracujemy
- OWASP Web Security Testing Guide (WSTG) — zakres i technika testów aplikacji webowych i API.
- OWASP ASVS — poziomy weryfikacji, według których raportujemy pokrycie testu.
- OWASP MASVS / MASTG — aplikacje mobilne na iOS i Androida.
- PTES (Penetration Testing Execution Standard) — przebieg całego zlecenia: od ustalenia zakresu po raport.
- NIST SP 800-115 — testy infrastruktury i sieci.
Ostatnia aktualizacja treści: 27 września 2026.
Zakres
Jakie są rodzaje testów penetracyjnych? Siedem obszarów
Siedem głównych rodzajów testów penetracyjnych to testy sieci i infrastruktury, aplikacji webowych, aplikacji mobilnych, interfejsów API, systemów IT i serwerów, urządzeń IoT/OT oraz testy socjotechniczne. Różnią się sposobem pracy, wymaganym dostępem i typowymi podatnościami. Poniżej, co sprawdzamy w każdym obszarze.
Sieci i infrastruktura
Badamy drogę i zasięg ruchu bocznego między systemami — nie bezpieczeństwo pojedynczej aplikacji. Scenariusz prowadzimy dwutorowo: z zewnątrz, z perspektywy intruza z internetu, i z wewnątrz, z perspektywy przejętej stacji roboczej.
- Konfiguracja routerów, firewalli i przełączników
- Skuteczność segmentacji na strefy zaufania
- Bezpieczeństwo sieci bezprzewodowych
- Polityki uwierzytelniania i dostępu do urządzeń
- Płaska sieć bez działającej segmentacji — jedna przejęta stacja otwiera drogę do serwerów
- Interfejsy zarządzania wystawione poza siecią administracyjną
- Domyślne i współdzielone hasła na sprzęcie sieciowym
- Przestarzałe oprogramowanie układowe z publicznie opisanymi podatnościami
Aplikacje webowe
Wszystko, co użytkownik otwiera w przeglądarce: sklepy i platformy e-commerce, portale klienckie, panele SaaS oraz webowe interfejsy ERP i CRM, razem z serwerem WWW, na którym stoją.
- Uwierzytelnianie i zarządzanie sesją
- Kontrola dostępu i walidacja danych wejściowych
- Logika biznesowa procesów i obsługa błędów
- Certyfikaty TLS i nagłówki bezpieczeństwa
- Błędy kontroli dostępu — cudze dane po podmianie identyfikatora w adresie
- Wstrzyknięcia SQL i inne ataki typu injection
- Cross-Site Scripting, przejmowanie i utrwalanie sesji
- Niebezpieczna deserializacja, przestarzałe komponenty
Pracujemy na działającej aplikacji przez interfejs użytkownika, zwykle w trybie black box lub grey box, z kontami o różnych rolach.
Aplikacje mobilne (iOS, Android)
Kod mobilny działa na urządzeniu użytkownika, poza kontrolą organizacji — zakładamy więc, że napastnik ma pełny dostęp do pliku aplikacji i do systemu, na którym ją uruchamia.
- Przechowywanie danych na urządzeniu
- Mechanizmy logowania i autoryzacji
- Biblioteki i SDK dostawców zewnętrznych
- Odporność na dekompilację i modyfikację kodu
- Wrażliwe dane w pamięci urządzenia bez szyfrowania
- Klucze i dane uwierzytelniające zaszyte w kodzie aplikacji
- Brak przypinania certyfikatu — droga do ataku Man-in-the-Middle
- Wycieki przez kopie zapasowe, logi systemowe i zrzuty ekranu w tle
Interfejsy API (REST, GraphQL)
API nie ma warstwy graficznej — nie ma formularza, który cokolwiek ogranicza. Każdy parametr i każde pole odpowiedzi trzeba sprawdzić osobno. Zaczynamy od inwentaryzacji endpointów, także tych nieudokumentowanych i pozostawionych po starszych wersjach.
- Wywołania REST, GraphQL i SOAP
- Bramki API, tokeny dostępu i zarządzanie kluczami
- Uprawnienia na poziomie obiektu i funkcji
- Limitowanie zapytań i kosztownych operacji
- Brak kontroli uprawnień na poziomie obiektu — cudzy rekord po zmianie identyfikatora
- Nadmiarowa ekspozycja danych: odpowiedź z polami filtrowanymi dopiero w interfejsie
- Brak limitowania zapytań i kosztownych operacji
- Server Side Request Forgery
Testy wymagają dokumentacji i kompletu kont testowych — bez nich część endpointów pozostaje niewidoczna.
Systemy IT, serwery i bazy danych
Test sieci pokazuje trasę. Test systemów IT odpowiada na pytanie, co napastnik zrobi po wejściu na hosta: jak zdobędzie uprawnienia administracyjne i jak dotrze do danych.
- Serwery i stacje robocze: Windows, Linux
- Bazy danych: SQL Server, MySQL, PostgreSQL
- Usługi katalogowe i uprawnienia kont
- Poczta, DNS i serwery plików
- Systemy bez wgranych poprawek mimo dostępnych aktualizacji
- Konta serwisowe z uprawnieniami administratora domeny i nigdy niezmienianym hasłem
- Ścieżki eskalacji uprawnień w Active Directory
- Bazy dostępne z całej sieci zamiast z serwera aplikacji, połączenia bez szyfrowania
Szersza ocena polityk i procedur należy do audytu bezpieczeństwa IT, nie do testu penetracyjnego.
Urządzenia IoT i OT
Część technik jest inwazyjna lub niszcząca, a urządzeń w ruchu produkcyjnym zwykle nie wolno zatrzymać. Testujemy na egzemplarzu laboratoryjnym albo w oknie serwisowym uzgodnionym z utrzymaniem ruchu.
- Analiza oprogramowania układowego
- Protokoły: Wi-Fi, Bluetooth, Zigbee, LoRaWAN, Ethernet, Modbus
- Platforma chmurowa zarządzająca urządzeniami
- Komponenty od dostawców zewnętrznych
- Dane uwierzytelniające zaszyte w firmware
- Aktywne porty debugowania pozwalające odczytać pamięć urządzenia
- Brak podpisu i weryfikacji aktualizacji
- Ten sam klucz kryptograficzny w całej serii produkcyjnej
Testy socjotechniczne
Sprawdzamy odporność pracowników i procedur na manipulację, a nie odporność systemów. Wymagają pisemnej zgody zarządu, ustalonych zasad przetwarzania danych pracowników i raportowania zbiorczego, bez wskazywania konkretnych osób.
- Phishing mailowy, vishing telefoniczny, smishing SMS
- Pretekstowanie z podszyciem się pod zaufaną osobę
- Podrzucanie nośników danych
- Podglądanie ekranów i dokumentów w biurze
- Podanie danych logowania na fałszywej stronie
- Brak zgłoszenia podejrzanej wiadomości do zespołu bezpieczeństwa
- Reset hasła przez helpdesk bez weryfikacji tożsamości
- Zmiana numeru konta na fakturze zatwierdzona wyłącznie na podstawie maila
Certyfikaty naszych pentesterów
Certyfikaty w zespole Pentestica, pogrupowane według tego, co potwierdzają. Wszystkie są nadawane przez niezależne organizacje i wymagają egzaminu, a większość — okresowego odnawiania.
| Certyfikat | Pełna nazwa | Co potwierdza |
|---|---|---|
| OSCP | Offensive Security Certified Professional | Praktyczne umiejętności ofensywne — egzamin polega na realnym przełamaniu zabezpieczeń w ciągu 24 godzin. |
| OSCE | Offensive Security Certified Expert | Zaawansowana eksploatacja, w tym pisanie własnych exploitów i omijanie zabezpieczeń. |
| CEH | Certified Ethical Hacker | Metodyka testów penetracyjnych i znajomość technik atakujących. |
| CISA | Certified Information Systems Auditor | Audyt systemów informatycznych — standard w audycie IT i zgodności. |
| CISM | Certified Information Security Manager | Zarządzanie bezpieczeństwem informacji na poziomie organizacji. |
| CRISC | Certified in Risk and Information Systems Control | Zarządzanie ryzykiem IT — bezpośrednio przydatne przy NIS2 i DORA. |
| ISO/IEC 27001 Lead Auditor | Information Security Management System Lead Auditor | Prowadzenie audytów systemu zarządzania bezpieczeństwem informacji wg normy PN-EN ISO/IEC 27001. |
| BCCLA | Business Continuity Certified Lead Auditor | Audyt ciągłości działania — element wymagany zarówno przez NIS2, jak i DORA. |
| CCNA · CCNP | Cisco Certified Network Associate / Professional | Projektowanie i bezpieczeństwo sieci — podstawa testów infrastruktury. |
| CSC | Certified Security Consultant | Doradztwo w zakresie bezpieczeństwa organizacji. |
| (ISC)² Ransomware | Ransomware: Identify, Protect, Detect, Recover | Reagowanie na ransomware według funkcji NIST Cybersecurity Framework. |
| IoT & CIP | IoT Cybersecurity & Critical Infrastructure Protection | Bezpieczeństwo urządzeń IoT i infrastruktury krytycznej. |
Na czym polegają pentesty? Test penetracyjny krok po kroku
Test penetracyjny przebiega w siedmiu etapach: 1. ustalenie zakresu i zasad współpracy (NDA), 2. rozpoznanie systemu, 3. skanowanie i identyfikacja podatności, 4. ręczna weryfikacja, 5. kontrolowana eksploatacja z dowodem (PoC), 6. raport techniczny i zarządczy, 7. retest po poprawkach. Każdy etap kończy się konkretnym ustaleniem albo dokumentem, nie „postępem prac”.
- Zakres i zasady współpracy
Ustalamy cele testu, zakres systemów i terminy prac. Spisujemy zasady bezpieczeństwa i poufności: NDA, umowę, listę sieci i aplikacji w zakresie oraz dozwolone techniki, żeby nie zakłócić pracy organizacji.
- Rozpoznanie
Zbieramy informacje o aplikacji, infrastrukturze lub usługach, które będą objęte testami. Im pełniejszy obraz systemu, tym trafniejszy wybór metody ataku na kolejnych etapach.
- Skanowanie i analiza
Identyfikujemy wersje, konfiguracje, otwarte usługi i punkty wejścia — czyli mapę tego, co w ogóle da się zaatakować.
- Manualna weryfikacja podatności
Sprawdzamy ręcznie, które ze znalezisk są realne. Skaner podaje sygnały; pentester rozstrzyga, czy da się je wykorzystać.
- Kontrolowana próba wykorzystania
Potwierdzamy wpływ podatności: brute force, wstrzyknięcia SQL, socjotechnika, w razie potrzeby osobny sprzęt — w granicach ustalonych na starcie. Po próbie przywracamy system do stanu sprzed testu i sprawdzamy, czy zespół po drugiej stronie w ogóle odnotował naszą obecność.
- Raport techniczny i zarządczy
Przekazujemy opis czynności, listę podatności z oceną ryzyka, dowody istnienia (PoC) i rekomendacje naprawy — w dwóch warstwach: dla zarządu i dla zespołu technicznego.
- Retest po poprawkach
Po wdrożeniu poprawek weryfikujemy, czy podatności zostały skutecznie usunięte. Raport końcowy uwzględnia wyniki retestu.
Ile kosztuje pentest? Cennik testów penetracyjnych 2026
Cenę testu penetracyjnego wyznacza wielkość zakresu, a nie sam rodzaj systemu: liczba aplikacji, ról użytkownika, hostów lub adresów IP. Poniżej widełki, od których zaczynamy rozmowę — te same, które wylicza nasz konfigurator zakresu.
Pojedynczy test aplikacji webowej z jedną rolą użytkownika mieści się zwykle w przedziale 6 000–11 000 zł. Test infrastruktury zewnętrznej do pięciu adresów IP to zwykle 2 500–4 500 zł. Szersze zakresy — więcej aplikacji, ról albo hostów — przesuwają wycenę proporcjonalnie do nakładu pracy zespołu.
| Rodzaj testu | Wielkość zakresu | Orientacyjne widełki |
|---|---|---|
| Aplikacja webowa | bez uwierzytelnienia | 4 500–7 500 zł |
| Aplikacja webowa | 1 rola | 6 000–11 000 zł |
| Aplikacja webowa | 2–3 role | 10 000–18 500 zł |
| Aplikacja webowa | 4 role i więcej | 17 000–39 000 zł |
| Interfejs API (REST, GraphQL) | bez uwierzytelnienia | 4 000–7 500 zł |
| Interfejs API (REST, GraphQL) | 1 rola | 5 000–10 000 zł |
| Interfejs API (REST, GraphQL) | 2–3 role | 9 000–17 000 zł |
| Interfejs API (REST, GraphQL) | 4 role i więcej | 15 500–29 500 zł |
| Aplikacja mobilna (iOS, Android) | bez uwierzytelnienia | 5 000–10 000 zł |
| Aplikacja mobilna (iOS, Android) | 1 rola | 7 000–13 500 zł |
| Aplikacja mobilna (iOS, Android) | 2–3 role | 11 000–21 500 zł |
| Aplikacja mobilna (iOS, Android) | 4 role i więcej | 14 500–29 500 zł |
| Sieć wewnętrzna | do 25 hostów | 3 000–6 000 zł |
| Sieć wewnętrzna | 25–100 hostów | 5 000–10 000 zł |
| Sieć wewnętrzna | 100–500 hostów | 9 000–18 500 zł |
| Sieć wewnętrzna | powyżej 500 hostów | 17 000–36 000 zł |
| Infrastruktura zewnętrzna | do 5 adresów IP | 2 500–4 500 zł |
| Infrastruktura zewnętrzna | 6–20 adresów IP | 4 500–8 500 zł |
| Infrastruktura zewnętrzna | 21–50 adresów IP | 7 500–13 500 zł |
| Infrastruktura zewnętrzna | powyżej 50 adresów IP | 12 000–26 500 zł |
| Środowisko chmurowe | 1 konto lub subskrypcja | 7 500–14 500 zł |
| Środowisko chmurowe | 2–3 konta | 12 000–24 500 zł |
| Środowisko chmurowe | 4 konta i więcej | 19 500–44 000 zł |
Co zmienia wycenę
- Retest po wdrożeniu poprawek — +15% wartości testu
- Środowisko Active Directory w zakresie — ×1,4
- Chmura (AWS, Azure, GCP) jako element dodatkowy — ×1,25
- Socjotechnika i phishing — +2 000–4 000 zł
- Osobny raport zarządczy — +2 500 zł
Wyceniane osobno
Red teaming24 500–54 000 zł
Symulacja realnego, wielowektorowego ataku bez uprzedzania zespołu IT. Wyceniamy indywidualnie.
Testy TLPT wg DORA172 000–345 000 zł
Testy według scenariuszy opartych na realnych zagrożeniach, nadzorowane przez KNF. Wyceniamy indywidualnie.
To widełki orientacyjne, nie oferta handlowa. Ostateczna kwota zależy od zakresu ustalonego przed startem — dlatego pierwszym krokiem jest zawsze rozmowa o tym, co dokładnie ma być testowane. Widełki dla swojego zakresu policzysz samodzielnie w konfiguratorze zakresu, bez podawania e-maila.
Warianty testu
Black box, grey box i white box — tabela porównawcza
Black box, grey box i white box różnią się jedną rzeczą: zakresem wiedzy o systemie, który zespół testujący dostaje przed startem. Ta decyzja przesądza, ile czasu pentesterzy poświęcą na rozpoznanie, a ile na faktyczne szukanie podatności.
| Wariant | Co wie zespół testujący | Co najlepiej wykrywa | Kiedy wybrać |
|---|---|---|---|
| Black box | Tylko dane publicznie dostępne, bez kont i dokumentacji | Ekspozycję systemu od strony internetu i błędy widoczne dla anonimowego atakującego | Gdy chcesz sprawdzić, co widzi napastnik bez żadnego dostępu |
| Grey box | Konta testowe, role użytkowników, ogólny opis architektury | Błędy autoryzacji, eskalację uprawnień, luki w logice biznesowej | Gdy zależy ci na największej liczbie realnych ustaleń w ustalonym czasie |
| White box | Kod źródłowy, dokumentację, konfigurację, kontakt z zespołem IT | Wady w kodzie i konfiguracji, w tym trudne do zauważenia z zewnątrz | Gdy testujesz system krytyczny albo aplikację przed wdrożeniem |
Najczęściej grey box: daje najwięcej realnych ustaleń w przewidywalnym czasie. Porównując oferty, sprawdź najpierw, który model wyceniono, bo ta sama kwota za black box i grey box oznacza dwie różne prace.
Porównanie usług
Test penetracyjny, audyt czy skanowanie podatności? Czym się różnią
Test penetracyjny, audyt bezpieczeństwa IT, skanowanie podatności i red teaming odpowiadają na cztery różne pytania i nie zastępują się nawzajem. Skan pyta, co wygląda podejrzanie. Test pyta, co da się wykorzystać. Audyt pyta, czy procesy i zabezpieczenia są zgodne z przyjętym standardem. Red teaming pyta, czy ktokolwiek zauważy atak w toku.
| Rodzaj badania | Na czym polega | Co dostajesz | Kiedy to wybrać |
|---|---|---|---|
| Skanowanie podatności | Automatyczne porównanie wersji i konfiguracji z bazą znanych luk | Listę sygnałów do weryfikacji, zwykle z częścią fałszywych alarmów | Do cyklicznej kontroli higieny infrastruktury między testami |
| Test penetracyjny | Manualne próby wykorzystania podatności w ustalonym zakresie | Raport z potwierdzonymi podatnościami i rekomendacjami naprawy | Gdy chcesz wiedzieć, co realnie da się zrobić z twoim systemem |
| Audyt bezpieczeństwa IT | Przegląd dokumentacji, konfiguracji i procesów wobec standardu | Ocenę zgodności i luk organizacyjnych wraz z planem działań | Przed certyfikacją, przeglądem regulacyjnym lub due diligence |
| Red teaming | Symulację realnego, wielowektorowego ataku bez uprzedzania zespołu IT | Ocenę zdolności wykrywania i reagowania na atak w toku | Gdy podatności są już opanowane, a sprawdzasz obronę |
Skaner nie sprawdzi, czy użytkownik jednej firmy zobaczy w twojej aplikacji dokumenty innej. Takie błędy logiki i autoryzacji znajduje człowiek. Ocenę zgodności procesów daje audyt bezpieczeństwa IT, a sprawdzenie zespołu obrony — red teaming, często łączony z testami socjotechnicznymi. Szczegółowe porównanie opisujemy we wpisie czym różni się skanowanie podatności od testu penetracyjnego.
Kto najczęściej korzysta z testów penetracyjnych?
Z testów penetracyjnych korzystają nie tylko firmy. Pentestica testuje systemy sklepów internetowych, banków i fintechów, placówek ochrony zdrowia, dostawców oprogramowania, małych i średnich przedsiębiorstw oraz instytucji publicznych. Najczęściej zgłaszają się do nas:
E-commerce i sklepy internetowe
Chronią dane klientów, płatności i bazy danych przed wyciekiem. Test obejmuje zwykle sklep, panel administracyjny, integracje płatnicze i API.
Sektor finansowy i bankowość
Banki, fintechy i ubezpieczyciele muszą spełniać surowe wymagania (DORA, wytyczne KNF) i chronić środki oraz tożsamość użytkowników.
Ochrona zdrowia
Szpitale, przychodnie i firmy IT działające w medycynie przetwarzają wrażliwe dane pacjentów (RODO; przy klientach z USA także HIPAA).
Firmy IT, SaaS i dostawcy oprogramowania
Twórcy aplikacji webowych i mobilnych sprawdzają produkt przed wdrożeniem lub w trakcie rozwoju, a raport pokazują klientom i audytorom.
Małe i średnie przedsiębiorstwa
Każda organizacja z siecią wewnętrzną, serwerami lub danymi poufnymi, dla której przestój albo kradzież danych oznacza realne straty.
Instytucje publiczne i urzędy
Podmioty przechowujące dane obywateli, zobowiązane ustawą o KSC i NIS2 do utrzymania wysokiego poziomu cyberbezpieczeństwa i dokumentowania jego weryfikacji.
Kto w Polsce musi przeprowadzać testy bezpieczeństwa?
Żaden polski przepis nie nakazuje wprost „testu penetracyjnego” wszystkim firmom. Kilka reżimów wymaga jednak regularnego testowania zabezpieczeń, co w praktyce oznacza pentest. Obowiązek jest sformułowany przez cel: masz wykazać, że sprawdzasz skuteczność zabezpieczeń, a nie tylko deklarujesz ich istnienie.
Dyrektywa NIS2
Obejmuje podmioty kluczowe i ważne we wskazanych sektorach i wymaga zarządzania ryzykiem cyberbezpieczeństwa, w tym oceny skuteczności stosowanych środków. Test penetracyjny jest naturalnym sposobem udokumentowania takiej oceny wobec zarządu i organu nadzoru (dyrektywa (UE) 2022/2555, art. 21). Pierwszy krok to ustalenie statusu firmy wobec NIS2.
Rozporządzenie DORA
Dotyczy podmiotów finansowych i ich dostawców ICT; wymaga programu testowania odporności cyfrowej prowadzonego regularnie. Dla wskazanych podmiotów przewiduje dodatkowo testy TLPT — według scenariuszy opartych na realnych zagrożeniach, nadzorowane w Polsce przez Komisję Nadzoru Finansowego (rozporządzenie (UE) 2022/2554, art. 24–26). Zakres wymagań DORA warto ustalić przed budżetowaniem.
Norma ISO/IEC 27001
Nie nakazuje pentestu jako takiego, lecz wymaga oceny podatności technicznych i weryfikacji skuteczności zabezpieczeń. Audytorzy certyfikujący pytają o dowody, a raport z testu wraz z historią napraw jest dowodem czytelnym i łatwym do przedstawienia (ISO/IEC 27001:2022).
Przetwarzanie danych osobowych
Przepisy wymagają regularnego testowania, mierzenia i oceniania skuteczności środków technicznych i organizacyjnych. Nie wskazują metody ani częstotliwości — administrator dobiera je sam (RODO, art. 32 ust. 1 lit. d). Przy danych wrażliwych lub przetwarzanych w dużej skali techniczny test aplikacji trudno zastąpić czymkolwiek innym.
Co dostajesz po teście penetracyjnym?
Produktem testu penetracyjnego jest raport, nie samo włamanie. Dobry raport ma dwie warstwy: jedną dla zarządu, drugą dla zespołu, który będzie naprawiał.
Streszczenie zarządcze
Ocena stanu bezpieczeństwa napisana bez żargonu, z wnioskiem, co to oznacza dla działania firmy.
Lista podatności z oceną istotności w skali CVSS
Każde znalezisko opisane wraz z poziomem ryzyka i miejscem występowania — adresem, endpointem lub usługą.
Dowód wykorzystania (PoC)
Kroki, które pentester wykonał, żeby wykazać, że podatność jest realna, a nie teoretyczna.
Rekomendacje wg priorytetu
Konkretne działania w kolejności, w jakiej warto je wdrażać, żeby najpierw zamknąć największe ryzyko.
Opis metody i zakresu
Jakie systemy testowano, w jakim wariancie i według jakiej metodyki — oraz co świadomie znalazło się poza zakresem.
Retest to powtórna weryfikacja tych samych podatności po wdrożeniu poprawek. Sprawdza, czy naprawa faktycznie zamknęła problem, czy tylko ukryła jego objaw, i czy przy okazji nie powstała nowa luka. Bez retestu raport pozostaje listą zamiarów.
Raport bywa też potrzebny jako dowód na zewnątrz: klient korporacyjny pyta o niego w ankiecie bezpieczeństwa przed podpisaniem umowy, ubezpieczyciel przy polisie cyber, a audytor przy przeglądzie zgodności.
Jak przygotować firmę do testu penetracyjnego?
Przygotowanie to siedem decyzji, które warto podjąć przed podpisaniem umowy. Każda domknięta wcześniej oszczędza czas testu.
Określ cel testu
Wymóg klienta, certyfikacja, nowa aplikacja czy kontrola po zmianach — wystarczy jedno zdanie.
Zinwentaryzuj to, co ma być testowane
Aplikacje, adresy IP, domeny, API i role użytkowników, razem z tym, co zostaje poza zakresem.
Wskaż osobę kontaktową
Jedna osoba z prawem decyzji skraca każde ustalenie z dni do godzin.
Ustal okno czasowe i środowisko
Środowisko testowe czy produkcyjne i w jakich godzinach wolno testować.
Przygotuj konta testowe
Po koncie na każdą rolę, a w rolach z własnymi danymi po dwa. Konta wypełnione danymi, żeby nie badać pustych ekranów.
Zbierz zgody dostawców zewnętrznych
Hosting, chmura, SaaS: jeśli zasób nie jest twój, potrzebna jest pisemna zgoda jego właściciela.
Ustal ścieżkę eskalacji
Kto i jakim kanałem dostaje informację o awarii albo o podatności krytycznej wymagającej natychmiastowej reakcji.
Dobrze przygotowany zakres skraca test i obniża koszt. Listę pól do wypełnienia znajdziesz we wzorze zakresu testu penetracyjnego, a widełki policzysz w konfiguratorze. Przygotowanie aplikacji webowej rozwija wpis o tym, co wchodzi w zakres audytu aplikacji webowej.
Z naszej praktyki
Jakie są przykłady testów penetracyjnych? Trzy przypadki z naszej praktyki
Trzy zlecenia, które opisujemy szczegółowo w case studies: branża, skala, znaleziona podatność i naprawa.
Sieć sprzedaży RTV/AGD: zakupy za grosze
Jedna z największych sieci sprzedaży elektroniki w Polsce, tysiące transakcji na godzinę. W teście grey box aplikacji mobilnej i API znaleźliśmy manipulację ceną: aplikacja przekazywała kwotę koszyka do bramki płatności, a backend jej nie przeliczał. Naprawa: przeliczanie koszyka po stronie serwera, podpisywanie krytycznych parametrów i testy regresji. Pełny opis przypadku →
Neobank z regionu CEE: cudze konta po zmianie identyfikatora
Przed ekspansją na rynki zachodnie testowaliśmy API nowej funkcji „Konta rodzinne” w architekturze mikroserwisów. Token JWT poprawnie uwierzytelniał użytkownika, ale część endpointów nie sprawdzała, czy ma on prawo do danego zasobu. To podatność BOLA, pierwsza pozycja OWASP API Security Top 10 (2023). Naprawa: kontrola uprawnień w middleware, identyfikatory UUID, testy regresji. Pełny opis przypadku →
Platforma z panelem klienta: jeden plik i przejęty serwer
Moduł przesyłania faktur i załączników sprawdzał tylko, czy nazwa pliku zawiera „.pdf”, i zapisywał pliki w katalogu wykonywanym przez serwer. Plik raport.pdf.php dał zdalne wykonanie kodu (RCE). Naprawa: weryfikacja sygnatury pliku, zapis poza katalogiem publicznym, zakaz wykonywania skryptów. Retest potwierdził zamknięcie luki. Pełny opis przypadku →
Zdarza się, że znajdujemy luki, o których nie wiedzieli sami twórcy systemu, dlatego test warto traktować jak niezależną drugą opinię. Wszystkie opisane zlecenia są na stronie case studies z testów penetracyjnych.
Opinie klientów
Opinie klientów Pentestica w Google
Poniżej trzy opinie klientów, którzy zlecili nam testy i dalszą opiekę nad bezpieczeństwem. Cytujemy je bez zmian z wizytówki Pentestica w Google.
„Współpraca z Pentestica była na bardzo wysokim poziomie. Raport z testów penetracyjnych naszej nowej aplikacji był szczegółowy i co najważniejsze dla moich programistów, zawierał jasne instrukcje, jak załatać luki. Nie było to zwykłe puszczenie skanera, ale rzetelna, ręczna weryfikacja. Polecam.”
„Współpracujemy już trzeci rok. Zaczynaliśmy od prostego pentestu strony www, teraz Pentestica dba o bezpieczeństwo całej naszej sieci. Cenię ich za to, że są proaktywni i sami dają znać, gdy pojawiają się nowe zagrożenia, na które powinniśmy uważać.”
„Długo szukaliśmy firmy, która nie potraktuje nas taśmowo. W Pentestica doceniam przede wszystkim komunikację. Od pierwszej bezpłatnej wyceny, przez realizację, aż po omówienie wyników czuliśmy się zaopiekowani.”
Ocena 5,0 / 5 na podstawie 12 opinii w Google (stan na 26.09.2026). Zobacz wszystkie opinie w Google →
Podstawy formalne
Kto wykonuje testy penetracyjne, co robi pentester i czy pentesty są legalne?
Testy wykonują pentesterzy. Wbrew filmowemu wyobrażeniu ich codzienność to nie efektowne „hakowanie”, lecz rekonesans, analiza architektury i — co najważniejsze — raportowanie. Produktem końcowym nie jest samo włamanie, ale dokument pozwalający zrozumieć ryzyko biznesowe i usunąć jego przyczynę.
Testy penetracyjne są w pełni legalne, o ile są przeprowadzane na zlecenie i za zgodą właściciela testowanego systemu. Działanie bez umowy i pisemnej zgody jest w Polsce przestępstwem z art. 267 Kodeksu karnego.
Dlatego profesjonalna usługa zaczyna się od ustalenia zakresu, umowy o poufności (NDA) i zasad współpracy (Rules of Engagement). Zasady określają, co wolno testować, jakimi technikami, w jakich godzinach i kogo powiadomić, jeśli coś pójdzie nie po planie. To dokument, który chroni prawnie obie strony.
Wybór wykonawcy
Jak wybrać firmę do testów penetracyjnych? Siedem kryteriów
Dobrą firmę do testów penetracyjnych poznasz po tym, że przed podpisaniem umowy pokazuje, kto będzie testował, jaką metodyką, co znajdzie się w raporcie i ile kosztuje retest. Oto siedem kryteriów, którymi sami oceniamy cudze oferty, gdy klient o to prosi.
1. Ludzie, nie logo
Zapytaj, kto personalnie wykona test, jakie ma certyfikaty (OSCP, OSWE, CRTO, eWPTX, CEH) i ile podobnych systemów testował.
2. Metodyka z nazwy, nie z opisu
Wykonawca powinien wskazać metodykę: OWASP WSTG i ASVS dla aplikacji, OWASP MASVS dla aplikacji mobilnych, PTES dla całego procesu. Bez niej nie porównasz dwóch ofert.
3. Test manualny, nie skan z logo
Poproś o zanonimizowany raport i sprawdź, czy zawiera dowody wykorzystania podatności (PoC) i łańcuchy ataku, a nie tylko wyniki skanera z opisem z bazy CVE.
4. Wycena z zakresu, który rozumiesz
Oferta powinna określać liczbę aplikacji, ról użytkownika, hostów i endpointów API. Wycena „za całość” nie mówi, co wypadnie, gdy zabraknie czasu.
5. Retest w cenie albo z jasną stawką
Bez retestu zostaje lista problemów zamiast potwierdzenia, że zniknęły. Sprawdź, czy retest jest w ofercie, w jakim terminie i za ile.
6. Raport dla dwóch odbiorców
Streszczenie dla zarządu (ryzyko, priorytety, nakład) i część techniczna dla zespołu (kroki odtworzenia, CVSS, rekomendacje).
7. Formalności: umowa, NDA, zasady współpracy
Umowa, NDA i zasady współpracy (Rules of Engagement) z oknem czasowym, kontaktem awaryjnym i ścieżką eskalacji. Przy testach na produkcji sprawdź też ubezpieczenie OC wykonawcy.
Pentestica spełnia te siedem kryteriów: pytania przed testem i w jego trakcie trafiają do certyfikowanego specjalisty ds. cyberbezpieczeństwa (w zespole m.in. OSCP, OSCE, CEH). Pracujemy według OWASP WSTG, ASVS i PTES. Raport zawiera dowody wykorzystania podatności i osobne streszczenie dla zarządu, retest jest częścią procesu, a przed startem podpisujemy umowę, NDA i zasady współpracy. Test penetracyjny to jedna z naszych usług — pełną ofertę usług cyberbezpieczeństwa (audyty IT, red teaming, NIS2, DORA, vCISO) opisujemy na stronie głównej.
Jeśli chcesz porównać oferty bez zgadywania, policz orientacyjne widełki w konfiguratorze — dostaniesz zakres i szacunek, które możesz wysłać do innych wykonawców jako wspólny punkt odniesienia.
Jak pracujemy
Dlaczego warto zlecić test nam
Odpowiada specjalista, nie handlowiec
Na pierwszą wiadomość odpowiada osoba, która będzie prowadzić test. Zakres ustalamy technicznie, a nie przez formularz kwalifikacyjny.
Widełki znasz przed rozmową
Orientacyjny koszt wyliczysz w konfiguratorze zakresu, bez zostawiania danych i bez oczekiwania na ofertę.
Retest jest częścią procesu
Po wdrożeniu poprawek sprawdzamy, czy podatności faktycznie zniknęły. Raport bez weryfikacji naprawy jest niedokończoną robotą.
Pracujemy na uznanych metodykach
Testy prowadzimy według OWASP WSTG, OWASP MASVS i PTES, dobierając standard do testowanego obszaru, a nie odwrotnie.
Pytania, które dostajemy najczęściej
Najczęstsze pytania o testy penetracyjne
Czym są testy penetracyjne (pentesty)?
Testy penetracyjne, czyli pentesty, to kontrolowane ataki na systemy IT, aplikacje lub infrastrukturę, prowadzone na zlecenie i za pisemną zgodą właściciela systemu przez wykwalifikowanych pentesterów. Pentesterzy szukają błędów konfiguracji, luk w oprogramowaniu i słabości procesów, a następnie potwierdzają je dowodem wykorzystania podatności. Efektem nie jest samo włamanie, lecz raport opisujący znalezione podatności, poziom ryzyka i sposób naprawy. Pojedynczy test i jego etapy opisujemy we wpisie co to jest test penetracyjny.
Co to jest pen test i co robi pentester?
Pen test to inny zapis słowa pentest, czyli testu penetracyjnego. Pentester szuka luk w zabezpieczeniach, zawsze za pisemną zgodą właściciela systemu. Ręcznie sprawdza, które z nich da się naprawdę wykorzystać. Potem opisuje je w raporcie z oceną ryzyka i sposobem naprawy. Skaner zgłosi ci listę możliwych problemów. Pentester powie, które są groźne, a które to fałszywe alarmy, i pokaże, jak daleko zajdzie atakujący. Kto może wykonywać pentesty i na jakich zasadach, opisujemy w sekcji o legalności testów.
Jakie są rodzaje testów penetracyjnych?
Najczęściej wyróżnia się siedem rodzajów: testy sieci i infrastruktury, aplikacji webowych, aplikacji mobilnych, interfejsów API, systemów IT i serwerów, urządzeń IoT/OT oraz testy socjotechniczne. Każdy można prowadzić jako black box, grey box lub white box. Co sprawdzamy w każdym obszarze, opisujemy w sekcji rodzaje testów penetracyjnych.
Ile kosztują testy penetracyjne?
Cena testu penetracyjnego zależy przede wszystkim od wielkości zakresu. Test aplikacji webowej z jedną rolą użytkownika kosztuje orientacyjnie 6 000–11 000 zł. Test infrastruktury zewnętrznej do pięciu publicznych adresów IP to 2 500–4 500 zł, a sieci wewnętrznej do 25 hostów 3 000–6 000 zł. Szersze zakresy — więcej aplikacji, ról albo hostów — przesuwają wycenę proporcjonalnie do nakładu pracy zespołu. Najbardziej zmienia wycenę liczba ról użytkownika: przy aplikacji webowej przejście z jednej roli na cztery i więcej zwiększa widełki mniej więcej trzykrotnie (zob. tabela cennika). Retest po wdrożeniu poprawek to około 15% wartości testu. Podane kwoty są widełkami orientacyjnymi, nie ofertą handlową: ostateczna wycena powstaje po ustaleniu zakresu.
Jakie są przykłady testów penetracyjnych?
Przykładem jest test aplikacji mobilnej i API sklepu, w którym kwotę zamówienia dało się zmienić przed płatnością. Inny to test API neobanku, w którym po podmianie identyfikatora widać było cudze konta. Trzeci to test modułu przesyłania plików, zakończony przejęciem serwera. Te trzy zlecenia opisujemy w sekcji przykłady z naszej praktyki.
Co to są testy penetracyjne aplikacji webowych i jak działają?
Test penetracyjny aplikacji webowej to kontrolowany atak na działającą aplikację: sklep, portal klienta, panel SaaS albo webowy interfejs ERP lub CRM. Pentester pracuje przez interfejs użytkownika, zwykle w trybie grey box, z kontami o różnych rolach. Sprawdza uwierzytelnianie i sesję, kontrolę dostępu, walidację danych, logikę biznesową oraz konfigurację TLS według metodyki OWASP WSTG. Każdą potwierdzoną podatność opisujemy w raporcie z dowodem wykorzystania (PoC) i rekomendacją naprawy. Typowe znaleziska wymieniamy w sekcji rodzaje testów penetracyjnych.
Ile trwa test penetracyjny?
Czas trwania testu penetracyjnego zależy od zakresu: liczby aplikacji i adresów IP, liczby ról użytkowników, typu testu oraz głębokości analizy. Węższy, precyzyjnie opisany zakres zamyka się zwykle szybciej, a rozbudowana infrastruktura lub aplikacja z wieloma rolami wymaga proporcjonalnie więcej czasu. Do samych testów trzeba doliczyć opracowanie raportu, a jeśli jest przewidziany, także retest po wdrożeniu poprawek. Konkretny harmonogram ustala się przed startem prac.
Czy test penetracyjny może uszkodzić system albo zakłócić pracę firmy?
Ryzyko zakłóceń istnieje, ale ogranicza się je zasadami współpracy ustalonymi przed startem testu. W dokumencie Rules of Engagement zapisuje się dozwolone techniki, godziny testów i systemy wyłączone z zakresu. Jest w nim też osoba do powiadomienia, jeśli coś pójdzie nie po planie. Działania o wyższym ryzyku, takie jak ataki wolumetryczne, wymagają osobnej zgody. Testy na środowisku produkcyjnym prowadzi się ostrożniej i w uzgodnionych oknach czasowych.
Jak często trzeba powtarzać testy penetracyjne?
Testy penetracyjne powtarza się zwykle co najmniej raz w roku, a częściej, jeśli system często się zmienia lub przetwarza dane wrażliwe. Na częstotliwość wpływają wymogi regulacyjne i branżowe, wewnętrzna polityka bezpieczeństwa, wielkość i złożoność infrastruktury, profil ryzyka oraz oczekiwania kontrahentów. Niezależnie od cyklu warto testować po każdej istotnej zmianie architektury, po wdrożeniu nowej aplikacji i po incydencie bezpieczeństwa.
Czy po teście system jest już bezpieczny?
Test penetracyjny nie czyni systemu bezpiecznym na stałe, ponieważ pokazuje stan zabezpieczeń w konkretnym momencie i w konkretnym zakresie. Bezpieczeństwo rośnie dopiero wtedy, gdy zespół wdroży rekomendacje z raportu, a retest potwierdzi skuteczność poprawek. Każde nowe wdrożenie, zmiana konfiguracji lub nowo ujawniona podatność w używanej bibliotece może otworzyć kolejną drogę ataku. Dojrzalsze organizacje uzupełniają cykliczne pentesty o red teaming i monitorowanie zmian.
Czym jest retest i czy jest dodatkowo płatny?
Retest to ponowne sprawdzenie wcześniej wykrytych podatności po wdrożeniu poprawek, które potwierdza, że zostały skutecznie usunięte i że naprawa nie otworzyła nowych luk. Wynikiem retestu jest zaktualizowany raport ze statusem każdego znaleziska. Rozliczenie zależy od ustaleń: retest bywa wliczony w zakres zlecenia albo wyceniany osobno, zwłaszcza gdy odbywa się długo po testach lub obejmuje zmieniony zakres. Warto ustalić to na etapie wyceny.
Czy testujecie środowisko produkcyjne, czy testowe?
Testy prowadzimy w obu środowiskach, ale bezpieczniejszym wyborem jest środowisko testowe odzwierciedlające produkcję. Środowisko testowe pozwala prowadzić agresywniejsze próby bez ryzyka dla ciągłości działania, pod warunkiem że ma tę samą konfigurację, wersje komponentów i dane testowe. Testy na produkcji są możliwe i czasem konieczne, na przykład przy testach wymaganych przez regulatora; wtedy ustala się okna czasowe, limity i listę działań wykluczonych. Wybór środowiska zapisuje się w uzgodnionym zakresie testu.
Bezpłatna wycena
Sprawdźmy, co da się wykorzystać w twojej infrastrukturze
Napisz, co chcesz przetestować — aplikację, sieć, chmurę. Odpowiemy widełkami i propozycją zakresu.
- ✓Odpowiadamy w ciągu jednego dnia roboczego
- ✓Na pierwszą wiadomość odpisuje specjalista ds. cyberbezpieczeństwa, nie handlowiec
- ✓Rozmowy o zakresie prowadzimy pod NDA
- ✓Wycena bez zobowiązań — nie zapisujemy nikogo do newslettera
Wolisz mailem? hello@pentestica.pl · odpowiadamy w 1 dzień roboczy