Zakres testu penetracyjnego — siedem decyzji, które trzeba podjąć przed startem

Zakres testu penetracyjnego to pisemne ustalenie, co jest testowane, po co, w jaki sposób i na jakich zasadach, zanim tester wyśle pierwszy pakiet. Musi określać cel, listę systemów, model wiedzy, środowisko, okna czasowe, zgody stron trzecich oraz tryb komunikacji. Poniżej siedem decyzji, które można podjąć samodzielnie przed rozmową z dostawcą.

Co obejmuje zakres testu penetracyjnego?

Zakres testu penetracyjnego obejmuje cel testu, listę systemów z wyłączeniami, metodę oraz zasady prowadzenia testu (rules of engagement). Jeśli potrzebne jest przypomnienie podstaw, warto zacząć od tekstu co to jest pentest.

Dobrym punktem odniesienia jest NIST SP 800-115 z września 2008 roku. W sekcji 6.5 wskazuje, że plan testu ma określać systemy, segmenty sieci lub aplikacje, termin i czas trwania oraz stosowane techniki.

Załącznik B tego dokumentu to szablon zasad zaangażowania (Rules of Engagement Template). Zawiera sekcje: zakres, logistyka, strategia komunikacji, harmonogram, miejsce testu, sprzęt testowy, obsługa incydentów, raportowanie i strona z podpisami. Siedem decyzji opisanych niżej obejmuje większość tych sekcji; miejsce testu i adresy, z których pracuje tester, ujęto w punkcie 5.

Jak zdefiniować zakres testu penetracyjnego krok po kroku?

Zakres definiuje się w siedmiu decyzjach, podejmowanych w podanej kolejności, bo każda zawęża następną. Gotową strukturę dokumentu daje wzór dokumentu zakresu w PDF.

1. Cel testu i pytanie dla raportu. Zacznij od pytania, na które raport ma odpowiedzieć. Inaczej wygląda test wynikający z wymogu regulacyjnego, inaczej test nowej aplikacji przed wdrożeniem, a jeszcze inaczej weryfikacja po incydencie czy ocena segmentacji sieci. Cel decyduje o reszcie zakresu: test segmentacji wymaga innych punktów startowych niż test aplikacji. Standard PTES (Penetration Testing Execution Standard) w części pre-engagement wymienia cele (Goals) jako osobny element uzgodnień. Zapisz jedno zdanie celu i jedno zdanie o tym, kto przeczyta raport: zespół techniczny, zarząd czy regulator.
2. Obiekty testu i wyłączenia. Wypisz konkretne adresy IP i zakresy, domeny, aplikacje webowe, API oraz aplikacje mobilne z wersjami. W PTES odpowiada temu punkt „Specify IP Ranges and Domains”, czyli wskazanie zakresów adresów i domen wprost, a nie opisowo. Dla aplikacji podaj adresy środowisk i wersje API, a dla sieci rozróżnij adresy zewnętrzne i wewnętrzne. Równie ważna jest lista wyłączeń (out of scope): system poza testem wpisz z nazwy i adresu, bo brak wpisu rodzi pytanie, czy tester może go dotknąć. Przy danych kart płatniczych wytyczne PCI SSC Penetration Testing Guidance v1.1 omawiają zakres w odniesieniu do środowiska danych posiadaczy kart (CDE) oraz testy segmentacji.
3. Model wiedzy i dostępy testera. Model wiedzy określa, co tester dostaje na start: nic (black box), konta i część dokumentacji (grey box) czy pełną dokumentację i kod (white box). Przy ograniczonym czasie testu grey box pozwala poświęcić go na podatności zamiast na rozpoznanie tego, co klient i tak może przekazać. Do sprawdzenia kontroli dostępu potrzebne są konta w co najmniej dwóch rolach. W aplikacjach zakres weryfikacji warto opisać poziomem ze standardu OWASP ASVS 5.0, wydanego 30 maja 2025 roku. Według ASVS poziom L1 da się w pełni zweryfikować testem penetracyjnym, L2 dotyczy aplikacji z danymi wrażliwymi i jest zalecany dla większości, a L3 przeznaczono dla aplikacji najbardziej krytycznych. Metodykę testu aplikacji webowej można odnieść do OWASP Web Security Testing Guide v4.2.
4. Środowisko testu. Zdecyduj, czy test odbywa się na produkcji, czy na kopii testowej lub stagingu. Staging zmniejsza ryzyko, ale ma sens tylko wtedy, gdy odpowiada produkcji konfiguracją i wersjami. Przy produkcji potwierdź aktualne kopie zapasowe i przygotuj dane testowe. Według PTES zgoda na test powinna potwierdzać, że testowanie może prowadzić do niestabilności systemu, więc to zdanie powinno znaleźć się w zakresie.
5. Okna czasowe i ograniczenia techniczne. Wpisz daty startu i końca (w PTES: „Specify Start and End Dates”), dopuszczalne godziny oraz limity ruchu. Testy odmowy usługi (DoS) standard traktuje jako osobny punkt uzgodnień, więc zapisz wprost, czy są dozwolone. Rozstrzygnij też socjotechnikę: tak czy nie, a jeśli tak, to jakie preteksty są dopuszczalne („Define Acceptable Social Engineering Pretexts”). Wytyczne PCI SSC z września 2017 roku dodają, że zasady zaangażowania powinny określać stopień dopuszczalnego wykorzystania podatności (eksploitacji). Zapisz też, czy test jest zdalny, czy na miejscu, i z jakich adresów IP wychodzi ruch testera, aby zespół utrzymania odróżnił go od ataku.
6. Strony trzecie i zgody. Sprawdź, kto poza firmą jest właścicielem lub operatorem testowanych zasobów: hosting, chmura, dostawcy SaaS, dostawca usług zarządzanych (MSP). Tej kwestii dotyczy punkt PTES „Dealing with Third Parties”. Umowa z dostawcą może zakazywać testów albo wymagać powiadomienia, więc sprawdź ją przed podpisaniem zakresu. Polityki wybranych dostawców chmury zebrano w liście pod krokami. Zbierz też pisemną zgodę właściciela systemu: bez niej działania testera mogą być nieuprawnionym dostępem do systemu.
7. Komunikacja, eskalacja i raport. Wskaż kontakt awaryjny dostępny całą dobę; PTES zaleca ustalenie dwóch form natychmiastowego, całodobowego kontaktu. Ustal też, co tester robi po znalezieniu podatności krytycznej w trakcie testu: czy zgłasza ją od razu i czy wstrzymuje prace. Na koniec określ format raportu (techniczny, zarządczy, dla regulatora) i to, czy zlecenie obejmuje retest po poprawkach. Uzgodnij również szyfrowany kanał przekazywania wyników i danych uwierzytelniających.

Polityki AWS, Microsoftu i Google Cloud wyglądają tak (stan na 30 września 2026 roku):

• AWS – nie wymaga wcześniejszej zgody dla usług z listy „Permitted Services”, ale zakazuje m.in. DoS i DDoS, symulowanego DoS, zalewania portów, protokołów i żądań (flooding) oraz przejęcia subdomeny.
• Microsoft – dopuszcza testy tylko we własnej dzierżawie (tenant) lub na zasobach z wyraźną autoryzacją, a ataków DDoS zakazuje w każdych okolicznościach.
• Google Cloud – nie wymaga kontaktu z Google, ale testy muszą być zgodne z Acceptable Use Policy i warunkami usługi oraz dotyczyć wyłącznie własnych projektów.

Kto w firmie podejmuje które decyzje o zakresie?

Każdą decyzję o zakresie podejmuje zwykle inna osoba, dlatego warto przypisać właściciela, zanim zacznie się wypełniać dokument. Kolumna „Co wpisać do zakresu” opiera się na NIST SP 800-115, PTES, wytycznych PCI SSC i politykach dostawców chmury. Przypisanie decyzji do ról to propozycja redakcji, którą trzeba dopasować do struktury firmy.

Decyzja	Kto decyduje po stronie klienta	Co wpisać do zakresu	Typowy błąd
Cel testu	Właściciel ryzyka, CISO lub dział compliance	Pytanie, na które odpowiada raport, i odbiorca raportu	Cel typu „sprawdzić bezpieczeństwo” bez konkretu
Obiekty testu	Administratorzy i architekt IT	Adresy IP, domeny, aplikacje, API i jawne wyłączenia	Brak listy out of scope
Model wiedzy	Właściciel aplikacji i zespół deweloperski	Model black, grey lub white box, konta w rolach, poziom ASVS	Jedno konto testowe zamiast kilku ról
Środowisko	Kierownik IT lub zespół utrzymania	Produkcja lub staging, kopie zapasowe, dane testowe	Staging niezgodny z produkcją
Okna i ograniczenia	Kierownik IT i biznesowy właściciel usługi	Daty, godziny, decyzja o DoS, preteksty socjotechniki, stopień eksploitacji, adresy IP testera	Brak decyzji o dopuszczalnej eksploitacji
Strony trzecie	Osoba odpowiedzialna za umowy z dostawcami	Zgody hostingu i SaaS, zgodność z polityką chmury, autoryzacja właściciela	Test zasobów, które należą do kogoś innego
Komunikacja i raport	CISO lub kierownik projektu	Kontakt awaryjny 24/7 w dwóch formach, eskalacja podatności krytycznych, format raportu, retest	Kontakt awaryjny dostępny tylko w godzinach pracy

Jakie błędy w zakresie najczęściej psują test?

Test psują najczęściej braki w dostępach, nieuzgodnione zabezpieczenia i zakres zmieniany w trakcie prac. W projektach, które prowadzimy, najczęściej powtarzają się cztery sytuacje.

• Brak kont w drugiej roli. Z jednym kontem nie da się sprawdzić, czy użytkownik widzi dane innego użytkownika lub funkcje administratora, więc test kontroli dostępu zostaje niepełny.
• Nieuzgodniony WAF lub ochrona hostingu. Filtr blokuje ruch testera pierwszego dnia, a czas idzie na odblokowanie adresów zamiast na testy.
• Zakres rozszerzany w trakcie. PTES pisze wprost: „Scope creep is one of the most efficient ways to put a penetration testing firm out of business.” W wolnym tłumaczeniu: niekontrolowane rozrastanie się zakresu to jeden z najskuteczniejszych sposobów na upadek firmy testującej. Dla klienta oznacza to mniej czasu na pierwotne cele, dlatego zmiana wymaga pisemnego aneksu.
• Staging różny od produkcji. Inne wersje lub konfiguracja sprawiają, że wyniki nie opisują systemu, z którego korzystają użytkownicy.

Jak zakres wpływa na czas i koszt testu?

Czas i koszt testu wynikają bezpośrednio z zakresu, dlatego rzetelnej liczby nie da się podać przed jego ustaleniem. Na pracochłonność wpływa siedem czynników:

• liczba obiektów testu: adresów, domen, aplikacji i API;
• liczba ról i funkcji aplikacji do sprawdzenia;
• model wiedzy, bo white box wymaga analizy dokumentacji i kodu;
• środowisko i związane z nim środki ostrożności;
• okna czasowe, np. praca wyłącznie nocą lub w weekendy;
• retest po poprawkach;
• raport dla zarządu lub regulatora obok raportu technicznego.

Kwot tu nie podajemy, bo bez znajomości tych czynników każda byłaby zgadywaniem. Czynniki można opisać w konfiguratorze zakresu, do którego odsyła sekcja „Jak Pentestica może pomóc”. Jeśli zakres ma trafić do przetargu, przyda się tekst o tym, jak przygotować zapytanie ofertowe na testy penetracyjne.

Najczęstsze pytania o zakres testu penetracyjnego

Czy zakres testu penetracyjnego musi być podpisany przez obie strony?

W praktyce tak. Podpisany zakres dokumentuje zgodę właściciela systemu na testy i granice tej zgody. Bez zgody osoby uprawnionej do dysponowania systemem działania testera mogą być nieuprawnionym dostępem. NIST SP 800-115 przewiduje w szablonie zasad zaangażowania osobną stronę z podpisami. Jeśli część systemów należy do dostawcy zewnętrznego, potrzebna jest także jego zgoda lub zgodność z jego polityką testów.

Czy można rozszerzyć zakres w trakcie testu?

Można, ale tylko formalnie, przez pisemną zmianę zakresu zaakceptowaną przez obie strony. Dopisywanie nowych systemów w rozmowie lub mailu bez korekty harmonogramu prowadzi do zjawiska, które PTES nazywa scope creep. Skutkiem jest rozmyta odpowiedzialność i mniej czasu na systemy z pierwotnej listy. Nowy system w zakresie zwykle wymaga też aktualizacji zgód stron trzecich i okien czasowych.

Czy trzeba informować dostawcę chmury o teście?

To zależy od dostawcy. AWS nie wymaga wcześniejszej zgody dla usług z listy Permitted Services, ale zakazuje m.in. DoS i przejęcia subdomeny. Microsoft dopuszcza testy tylko we własnej dzierżawie (tenant) lub na zasobach z wyraźną autoryzacją. Google Cloud nie wymaga kontaktu, lecz testy muszą być zgodne z Acceptable Use Policy i dotyczyć własnych projektów. Przed startem sprawdź aktualną wersję polityki.

Czy test penetracyjny wykonuje się na produkcji?

Bywa to konieczne, bo tylko produkcja pokazuje rzeczywistą konfigurację. Wymaga to jednak aktualnych kopii zapasowych, danych testowych, uzgodnionych okien czasowych i wyraźnej decyzji o testach DoS. PTES zaznacza, że zgoda na test powinna potwierdzać ryzyko niestabilności systemu. Staging jest bezpieczniejszy, ale daje wiarygodne wyniki tylko wtedy, gdy odpowiada produkcji wersjami i konfiguracją.

Czym różni się zakres testu od zapytania ofertowego?

Zapytanie ofertowe służy do wyboru wykonawcy i porównania ofert. Zakres testu jest dokumentem wykonawczym: opisuje cel, obiekty testu, wyłączenia, model wiedzy, środowisko, okna czasowe, zgody i komunikację. Zapytanie powinno zawierać wstępny zakres, aby oferty były porównywalne. Ostateczny zakres uzgadnia się z wybranym wykonawcą i podpisuje przed rozpoczęciem testu.

Jak Pentestica może pomóc

Pentestica realizuje testy penetracyjne od ponad 10 lat i ma za sobą setki zrealizowanych projektów. Każda wycena zaczyna się u nas od zakresu, dlatego siedem opisanych decyzji to te same pytania, które zadajemy na pierwszej rozmowie. Zakres można opisać samodzielnie w konfiguratorze zakresu testu, a otwarte kwestie omówić z nami przed podpisaniem dokumentu.

Źródła

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment – wytyczne z 2008 roku, sekcja 6.5 o planowaniu testu i Załącznik B z szablonem zasad zaangażowania.
• Penetration Testing Execution Standard (PTES): Pre-engagement Interactions – ustalenia przed testem: cele, zakresy IP i domen, daty, strony trzecie, socjotechnika, DoS, kontakty awaryjne.
• PCI SSC Information Supplement: Penetration Testing Guidance v1.1 – wytyczne z 2017 roku o zakresie CDE, testach segmentacji i zasadach zaangażowania.
• AWS Penetration Testing – polityka testów w AWS, lista usług dopuszczonych bez wcześniejszej zgody i działań zakazanych.
• Microsoft Security Testing Rules of Engagement – zasady testów bezpieczeństwa w usługach chmurowych Microsoft.
• Google Cloud Security FAQ – informacje o testach penetracyjnych własnych projektów w Google Cloud.
• OWASP Application Security Verification Standard 5.0 – standard weryfikacji bezpieczeństwa aplikacji z poziomami L1, L2 i L3.
• OWASP Web Security Testing Guide v4.2 – metodyka testów bezpieczeństwa aplikacji webowych.